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:

1. reject bad MAIL FROM addresses.
2. reject mail to nonexistent users during the SMTP transaction.
3. reject selected HELO/EHLO names.
4. 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.
5. support some sort of greylisting, even if that's just per-IP-address.
6. 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: localhost, 127.0.0.1, the machine's hostname, the machine's IP address (without '[' and ']' around it), and so on. Filtering this sort of crud out is now clearly essential.

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).