Spamassasin as a milter works well. Cloudmark has different anti-spam products.
Basically, run anti-spam on another machine and TUNE IT. With the milter, you can run spamass on another machine and sendmail elsewhere. IO load high? Put another spindle in there. Break up sendmail queues. Put them not on var (where logging is). Put mail spools for qpopper on another spindle. Put syslog into async write mode. Mail burdens are almost always IO. If you've tackled, IO, there's other stuff, but IO is always that first step. Filtering burdens are often CPU/RAM. And 2 machines handling SMTP and both doing Spam Detection that both deliver to the pop machine give you redundancy, separate POP performance from 99% of the email. And tos a note to your government rep just explaining that spam is costing you hardware, people and general resources. These spammers are taking money from your company and the economy. I want to see spammers caned on Fox TV (perhaps as an alternate choice to a couple years of hard time for costing businesses and ISPs billions of dollars). Now back to dealing with qpopper. Quoting Simon Byrnand ([EMAIL PROTECTED]): > At 13:16 3/03/03 -0500, Alan Brown wrote: > > This is a bit off topic, but.... > > >On Mon, 3 Mar 2003, Steve Hillman wrote: > > > >> At 04:06 AM 3/3/2003 -0500, you wrote: > >> >The mailserver I had handling 1-2 million messages/day was only a > >> >k6/400. Tweaking sendmail makes a big difference. > >> > >> Just curious - Sendmail and qpopper (or some other popper) on the one > >box, > >> or just sendmail acting as an MX? > > > >Both on the same box, with some level of spam filtering too - using > >DNSBLs (light load) and Spam Assassin (tagging only). > > Whether you use Spam Assassin for "tagging only" or sorting spam into other > folders, the load is the same. It is the tests that determine if it is spam > or not which take most of the CPU time. > > >I had to update from a 486 to handle body tagging. Spam Assassin is > >/bin/sh based so was killing the machine. > > Umm, not sure what you mean by /bin/sh based - Spam Assassin is most > definately Perl based. > > >Perl based filtering agents have the same (or worse) problem. The > >startup load for a dozen parallel perl proceses can quickly kill a > >ramstarved (< 256Mb) machine. > > Which is why Spam Assassin gives you the option of using the spamc/spamd > client server pair. > > One spamd daemon (a full perl copy of spamassassin) runs in the background > waiting for connections. It uses approximately 15MB of ram, and because its > running all the time, that is preloaded. > > spamc is a very small C program that connects to spamd, and has a > neglibible startup time or memory footprint. Each spamc request causes > spamd to fork off a process to handle it, but because of copy on write VM > there is no startup overhead or memory overhead in forking that new spamd > child. > > >Memory is more important than CPU most of the time - if you start > >hitting swap, you're only going to run as fast as your hard drives, even > >if you have a 200GHz Itanium processor from5 years in the future.
