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

Fake MX records can work like greylisting and often much faster. It doesn't require the installation of new software. What you do is add a fake highest and lowest MX record. Normal email will probably retry but spammers often don't. This is especially true of virus infected windows zombie spam. Here's an example MX configuration.

 fake0.example.com   10
 realmx.example.com  20
 fake1.example.com   30

The fake records can either be undefined or can point to dead IP addresses or to real IP addresses with port 25 closed. On the lowest numbered MX be sure it's pointed to a closed port because if you just use a temporary error then Qmail, which is not RFC compatible, will never move up to the next MX record.

Fake Lowest MX

The reason for the fake lowest MX record is that where most email is delivered. Real servers will get the error and retry the middle MX and deliver the email with only a few seconds delay. Zombie spam will just move on to the next victim. No good email is lost but a huge amount of spam never makes it into the system at all. This not only reduces spam but also reduces system load as SA doesn't have to process any of this.

Fake Highest MX

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.

Optionally you can add a lot of fake MX records on the top side. Additional fake MX records on the lowest numbers end will cause some additional delay, but on the high end there's no penalty. The reason for additional higher MX records is if spammers start trying random MX records then this give them more dead MX records to try.

 fake0.example.com   10
 realmx.example.com  20
 fake1.example.com   30
 fake2.example.com   40
 fake3.example.com   50
 fake4.example.com   60
 fake5.example.com   70

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)

exim: Marc Merlin wrote exim-sa, running SA during smtp time. With adaptive greylisting:

• mails with a low spam score are accepted without delay
• mails with an average spam score are greylisted, and only those are delayed
• mails with high spam scores are rejected regardless (no greylisting)

http://marc.merlins.org/linux/exim/sa.html

milter-greylist (http://hcpnet.free.fr/milter-greylist/) is an excellent greylisting solution for Sendmail. I've been using it for almost two years now, and the difference in the amount of mail SpamAssassin has to worry about is amazing.

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)

exim: Marc Merlin wrote exim-sa, running SA during smtp time. With adjustable teergrubing. IMHO Exim + exim-sa offer the most sophisticated Spam controll any MTA has to offer... http://marc.merlins.org/linux/exim/sa.html

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.