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