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
