The nenie.org domain uses a home grown SMTP server which applies some of the following anti-spam techniques. Nothing particularly novel on its own, but the combination of techniques works quite well so far, with spam down to a few message a days; out of about a hundred or two daily spam attempts.
All of the techniques used are SMTP-level, that is any message is rejected there and then during the SMTP session with an SMTP error. Well-behaved clients should transmit this error to the real sender, allowing them to take action in case of a false positive. How many bounces do get back to sender is perhaps uncertain, given the popularity of statistical filtering and misdirected bounces.
Most techniques used operate on the SMTP envelope, that is before the email is actually sent, allowing to save bandwidth by rejecting spam before the actual message is sent. None involve costly content analysis, unlike statistical techniques.
They are not all immune to false positives. This is mitigated by sometimes using several techniques together, reducing the amount of spam caught a bit, but also reducing false positives to the intersection of those of each individual technique.
Most techniques are also completely trivial to circumvent. Fortunately, they are obscure enough that spammers are not bothered to implement a workaround just to be able to spam me. If you run a major ISP's SMTP server, please don't start using them!
Some spammers use open HTTP proxies with a HTTP POST command, sending a whole SMTP session as the payload, not looking at the answer and hoping it will get through. It is very easy to detect the HTTP header, and there are no possible false positives.
This technique is about rejecting email from unknown senders with a SMTP "try again later" error. Regular senders will retry, most spammers will not. The official description proposes to apply it to all incoming email, but here it is combined with other techniques to avoid delaying regular email.
A blacklist is a realtime database of "bad" sender IP addresses, accessible via the DNS. Some like spamhaus are pretty conservative and take care before listing addresses, to avoid false positives. Others do list much more easily anybody who has sent some spam, but may also send ham. They catch more spammers at the cost of more false positives. They are particularly useful to keep track of hijacked end-user computers, through which most spam is currently sent.
Properly configured domains include a reverse DNS entry for their email senders. Domains used by spammers often don't. False positives do exist though.
Or at least independently rediscovered...
Some viruses are rather larger than regular email. Blocking large email stops them. Many modern servers will advertise the message size in the envelope, allowing blocking before the message is actually sent -- this is useful when the virus is sent via the victim's regular ISP server. This technique requires whitelisting of people allowed to send larger emails.
Virtually all SMTP servers tolerate a deviation from the SMTP standard: the use of a space in the MAIL/RCPT commands:
MAIL FROM:_<helo@example.invalid>
Many dedicated spamming tools have this error. Very few real email senders do -- I know of only one pretty obscure mailer.
The HELO SMTP command is supposed to contain the sender's domain name. It's not unusual for spamming tools, short of a correct domain, to use the receiver's own domain. This is very unlikely to be used by a proper sender, even a misconfigured one.
Some lazy spam tools don't bother forging the sender address and use the same as the recipient's address. No false positive.
(Last modified 2004-07-02)