Other Trick For Blocking Spam
This section is for other tricks to block spam that may or may not directly relate to SpamAssassin.
Fake MX Records
Email is supposed to be sent to the lowest numbered MX record first with the higher MX records being backup servers. Spammers often with try the highest MX record first thinking that the backup servers have less spam filtering than the main email server. They try the highest MX record and then never come back. So I set my highest MX record to point to an IP address that always returns a temporary "Come Back Later" error.
A real email will retry and get through. But the spammer will just go away. This trick saves having to process about 25,000 messages a day on my server.
Greylisting
Instead of a 2nd fake MX you can use greylisting, which returns a temporary "Come Back Later" error for users currently not known. It has the advantage of helping you on the primary MX directly, and rejects about 60% of the connections here. This is because spammers only try to send once, and if there is an error, they drop it. Real mail servers retry later.
A disadvantage could be that e-mail is delayed a bit, as some users seem to demand that e-mail arrives immediately, and cannot wait some minutes. Either you can tell your users to wait, and save lots of SPAM, or don't use greylisting *g*.
Very good greylist server for postfix are:
postgrey: http://isg.ee.ethz.ch/tools/postgrey/ (uses DB style files, easy to configure, good support) sqlgrey: http://sqlgrey.sourceforge.net/ (uses SQL databases)
Long delay (high latency)
I've seen that after changing my mail system from an old 486 with a very slow Internet connection (about 80 ms) to a fast server with just 5 to 10 ms, I got much much more spammail. Obviously spammers don't have much time to deliver one single mail. So it might help for a server which receives just some mails a day (maybe less than 200 a day) to increment the delay. I've seen no way to do this with iptables or ipfilter but maybe someone has an idea for this.
Rolf Winterscheidt
FYI: CommuniGate Pro and many others already have this implemented now. It is usualy called SMTP Prompt Delay. This delays an SMTP Prompt for a given time and in case a spammer connects to your server before it sent out the HELO prompt, all data received is dropped on the floor. We found this reduces a whole lot of spam as it effectively slows down their delivery. Any delay below 30 seems to work fine. Delays >=30 Seconds cause lots of problems with different ISPs which would then not be able to deliver mail to you. (Stefan Seiz)
qmail: Jon Lewis wrote smtp-delay; banner-delay code for the qmail MTA, with whitelisting capabilities among other extremely useful features... http://www.lewis.org/smtp-delay/ (Jeremy Eder)
Policy Daemons
Some MTAs such as postfix 2.1 and later can delegate a spam/ham decision to a policy server at any stage, i.e. before DATA or after. Before DATA, i.e. at RCPT TO stage has advances in such, that multirecipient mail remains intact and that it is possible to let the user decide whether or not to use the policy daemon. One example with greylisting, throttling, etc pp would be policyd: http://policyd.sourceforge.net/ another example, which acts like a mini-SpamAssassin but before the content has been received (i.e. at RCPT TO stage) would be policyd-weight: http://www.policyd-weight.org/ . Both can drastically reduce your bandwidth and CPU-Cycles and other MTA resources.