The minimum antispam features of a modern SMTP server
I have a machine running Debian's 'Woody' release. Debian Woody is several years old and uses Exim 3 as its (normal) mailer. Exim 3 unfortunately doesn't have many anti-spam features.
Exim 3's lack of antispam features combined with spammers vigorously finding some email addresses on the machine has been giving me lots of opportunities to a) experience semi-normal Internet spam life (eugh, says I), b) grind my teeth a lot, and c) contemplate what anti-spam features I now consider necessary in any SMTP server I actually want to run.
My current list is:
- reject bad
- reject mail to nonexistent users during the SMTP transaction.
- reject selected
- be able to be run under an inetd-style frontend, so I can use a separate frontend of my own choosing. Failing this, DNS blocklist support.
- support some sort of greylisting, even if that's just per-IP-address.
- run external filters on email messages, with full envelope information available as well; filters can at least reject messages, which will cause a SMTP-time rejection.
Everyone can do #1. Everyone should do #2, because otherwise your
SMTP server is going to spam innocent third parties when spammers
forge their address into
MAIL FROM and send spam to nonexistent
users on your machines. (Yes, I'm looking at you, QMail; please wake
up and join the 21st century.)
A majority of the spam my Debian machine is being hit with uses
clearly invalid HELO names:
127.0.0.1, the machine's
hostname, the machine's IP address (without '
[' and '
it), and so on. Filtering this sort of crud out is now clearly
I want the ability to run my own frontend inetd-like server because no SMTP server is going to build in the kind of powerful connection-time filtering I want. (And I can't ask them to; it's a lot of specialized code.) This can be faked by a message filter that has the envelope information available, if I really have to.
So far I would rather implement DNS blocklists in the frontend than in the SMTP server; my feeling is that I can make them more flexible there. (I may recant this view at some point; there are certainly some tricks a really flexible SMTP server could play.)
Evidence from my Debian machine suggests that almost all spam comes from open proxies (as if I didn't know that already). Greylisting, even of a very basic sort, is the most powerful mechanism to trim this down. Basic per-IP-address greylisting can be implemented in a frontend, but I'd rather have more powerful things.
Support for #6 enables a number of advanced tricks, including SMTP time rejection of viruses.
Of these, it appears that Exim 3 will do #1, #2, and check DNS blocklists. Exim 4 seems like it can do everything except perhaps #4 (but it can check DNS blocklists itself). Surprisingly few SMTP servers seem to have really good support for #6, and of course I rather suspect #4 will make MTA authors laugh derisively (except for QMail; pity that's ruled out for other reasons).