== 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 _MAIL FROM_ addresses.
# reject mail to nonexistent users during the SMTP transaction.
# reject selected _HELO_/_EHLO_ names.
# 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: _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).