[CentOS] Planning Mail Server (with low resources)

Tue Dec 6 11:25:13 UTC 2005
Karanbir Singh <mail-lists at karan.org>

Rodrigo Barbosa wrote:
>>>First off, dump either antivirus or antispam on that machine. You
>>>don't have enough memory to keep both happy.
>>
>>How about using MailScanner ? and wrap that around clamav + 
>>spamassassin, you can run it with 2 - 4 threads on a machine with 
>>256megs of ram, and since spamassassin runs via its perl interface 
>>locally ( and not via spamd ), it uses up no resources while its not 
>>running.
> 
> Yeah, that will work for a month or 2. After than, the bayesian database
> will start to get huge, and spamassassin will take a lot of time to
> start and use a lot of memory.

for a 2k user density, it would be a good idea to cycle bayes db every 
so often, only on a site with 2 - 5 people would you really expect the 
bayes db to have data that is months and months old :) too much poison 
in the wild these days.

another option is to turn off bayes completely, and just use URIBL's 
like surbl.org - in most cases the final result is almost as good as 
with bayes - with the advantage of near zero false positives.

>>MailScanner might slow your inbound mail queue processing by a few 
>>seconds, but would allow you to better manage the resources you have on 
>>the machine ( and also implement any policy based email rules you might 
>>want to have )
> 
> 
> After 2 months, on a 256M machine, spamassassin alone can slow a single
> e-mail by up to 2 minutes. Which can lead to a nice snowball issue.

I setup mailscanning services for a network that has 1500 users, ( no 
storage, just inbound smtp, scan and forward ) with MailScanner, 
spamassassin, clamav, fprot and bitdeffender -  on a P-3 1.4ghz with 
196MB ram and a 120gig hdd. The machine handles the traffic just fine. 
Last time I checked, it was doing 17k - 21k emails per day.

>>Also, on a machine with that setup, I'd have a Gig of Swap. And that 
>>40GB hdd, i wonder how fast that runs :) might end up being the bottle 
>>neck in the equation.
> 
> The main tip would be to have the swap partition close to the middle
> of the disk, so you can reduce the disk head seek time. At least in
> theory, considering there is no sector realocation due to bad blocks.

Thats an interesting point. Would help, I am sure.

- K