Our @debian.org addresses are just too polluted. It's a fact, and nobody moves. It's really tiredsome.

I happen to also be a co-admin on a mail server, that accepts almost 300k per MX, which is not very big, but quite big enough.

I've written a little tool called whitelister. It's used in conjunction with postgrey that we use as a POLICY daemon for postfix. Basicaly, what it does is quite simple:

  • it checks a lot of RBL (also possibly SPF, but my experience is that it's a very bad idea), and if the mail is clean for every R(H)BL it is configured to check, then it accepts the mail,
  • else postgrey takes the relay, and do its greylist thing.

This approach has spectacular results: greylisting in action

Edit: the same statistics on our backup/secondary MX greylisting in action

The green area are the mails we accept for delivery (after the AV-checks and classicale anti-UCE-checks). The red line is the amount of messages that the bayesian antispam (bogofilter) marks as spam. Since our clever greylisting is up, the results are just unbelievable: we drop a huge amount of spam, without needing bayesian spamfilter or clamav or any CPU-intensive checks, so almost for free.

The statistics we run show that a very few mails are actually submitted again (less than 20 per week), and most of them are spam anyway. And an analysis of the remaining spams shows that those are spam that come from redirections services (mail lists, @debian.org, …). We almost drop 99% of the spam that is submitted into the SMTP network through one of our MX's.

For the record, we only use cbl.abuseat.org, dul.dnsbl.sorbs.net and dynablock.njabl.org.

why doing it that way ?

greylisting is all about creating a dynamic map of the SMTP queues of the planet.

What I do, is only using RBL's that already exists to make that principle converge faster. Moreover, even if you use "bad" blacklists that have too many false positives, the greylist is here to let legitimates mails through.

So basicaly, it combines two bad[1] methods, to make a good one:

  • RBL's already exists, and allow us to avoid the delays that greylist implies for most of the legitimate mail sources (and if a SMTP forwards spam, greylist won't save us, it's a SMTP, it will submit it again, so avoid to greylist it in the first place);
  • the greylist saves the few errors the RBL can let you make, with a relatively small penality.

It's a win-win use.

Conclusion

I'd really like to see such a system be installed on our main MX's. @debian.org emails addresses are overloaded with spam (and 90% of the spam I receive, comes from my @debian address).

btw, in a MTA like exim (that some of our MX use), a tool like whitelister is not needed. It's possible to achieve the same thing within the exim configuration files (but don't ask me how, I never used exim, I just know it's possible to do it).

Is there anybody out there to support such an idea ?

Notes

[1] Used singly, I consider those methods really bad.