Mail Server recommendation

[Christian Damm]

Jim Durham schrieb:
> On Thursday 28 April 2005 04:50 pm, Christian Damm wrote:
> 
>>Jim Durham schrieb:
>>
>>>Hi,

hi jim,

>>>
>>>We currently have a dual-1.8 Xeon box with 2gb ram and
>>>Raid-1 160mhz SCSI's running sendmail/procmail/spamassassin
>>>and clamav.
>>
>>this iron should handle serious load without probs.
>>
>>1.) how large is your userbase?
> 
> About 500

thats next to nothing - this userbase (smtp, pop3, spam, av) could be 
handled by an ancient P1 system without any problems (even if your 
userbase is heavily populated with "powerusers").

> 
>>2.) do you know the bottleneck? (cpu, i/o, ram etc.)
> 
> I'd say all of the above .

hardware is definitely NOT your problem.

> 
>>3.) average mails processed per day? (ham/spam/virus ratio?)
> 
> Average mails per day 2670
> Yesterday produced 29 virus mails found

this number is also not worth mentioning.

> 
> I don't have an analyzer script for mailboxes, but.. I did some 
> creative grepping and found 3493 spam emails received yesterday. 
> Some went to multiple users, which is why it is higher than the 
> average/day.
> 
> 
>>4.) sendmail is slow compared to other modern unix MTA`s
> 
> 
> I don't think sendmail is the problem..

absolutely, i was assuming around >5k users minimal AND a real config 
problem (you wrote: "Our place is growing, adding users and so, we need 
a bigger, faster box.").

> 
> 
>>5.) procmail and spamassassin are resource hogs
> 
> 
> This is the problem, along with amavis. Spamassassin seems 
> slowest.  'ps' would show many, many spamassassin processes 
> running. Perl is slow.  I wish spamassassin was in C !

...even if spamassassin would be coded in shell script ;-) - your 
problem is definitely NOT a scripting languages overhead.

follow the "mailserver admin`s ABC":

1.) limit the max. allowed connections to your smtpd daemon to a 
reasonable number (altough your dual xeon iron could handle very much 
concurrent smtp connections without even "seeing" them, we dont want to 
risk a big backqueue)

2.) reject as much junk as you can during initial smtp handshake.
a.) OF COURSE reject mails to unknown recipients.
b.) check for typical NON RFC / illegal or "spammy" behaviour during the 
smtp handshake (faked helo/ehelo, illegal reverse mx, non existent 
sender domain etc.) and reject this junk.
c.) use some wisely selected RBL`s if your policy allows this.
d.) use greylisting if your policy allows this.
e.) all of the above cuts your number of mails to process down to a 
handful of messages - amavis and spamassassin would be very idle.

3.) important: limit your max. allowed amavisd/spamassassin processes!
this point is very important in your case (in every case!) - see, modern 
MTA`s are very good when it comes to queue management - so if your 
backqueue of mails to process gets a little bit bigger, there is no 
problem as long as you limit your concurrent amavisd processes to (lets 
say) a number of four.
the point here is all about: process messages fast and fluently with 
only a few running amavis/spamassassin processes instead of killing the 
box with many of them. 25 spamassassin processes sloooooow down delivery 
(your backqueue gets bigger, the system gets unresponsive and swaps 
etc.) - 5 spamassassin processes let your box "room to breath" and mails 
"flow" through your system.

4.) also keep an eye on the resources used by your pop3 daemon (imap is 
another story - very RAM dependent) altough all of the pop3d`s i know 
are rather resource friendly.

> 
> 
> Thanks very much for your response
> 
> -Jim
> 
> !DSPAM:427252eb938451284235665!
> 

-- 

mfg.

christian damm
technische leitung
phone: dw 42
email: christian.damm at diewebmaster.at
icq at work: 124464652

die webmaster - flötzerweg 156 - 4030 linz - austria

phone: +43-732-381242
fax: +43-732-381242-22
isdn (leonardo): +43-732-381242-33

homepage: www.diewebmaster.at, public email: office at diewebmaster.at