I finally got round to writing up some documentation on the greylisting setup that I use, and that we've been shipping in an exim-greylist package in Fedora for some time.
This setup avoids some of the common mistakes that greylisting implementations make, and tries hard to avoid delaying mail except where it's actually likely to be a benefit to you. Mostly, that means:
- Remember which hosts actually do retry, and never delay mail from those hosts in future.
- Only delay mails which actually look suspicious in some way; don't just delay everything blindly.
- Avoid greylisting for hosts on the DNS Whitelist database.
I also see a lot of greylisting which happens at RCPT time, without even looking at the mail. I appreciate that some people claim that they don't want to use the extra bandwidth to actually look at the mail, or the extra CPU time. I think that's a very poor decision, if it means you're delaying mail that has absolutely nothing wrong with it. Bandwidth and CPU time on a mail host really shouldn't be an issue these days. Some people even do it at RCPT time when the sender is empty (a bounce), which means that sender verification also fails (temporarily) and they end up delaying their own outgoing mail.
Using dnswl.org is something I added quite recently, and also makes a lot of sense — if the host is registered as a known mail server, it's almost certain to retry the mail and therefore you gain nothing by greylisting except for a delay.
This greylisting is done purely in Exim's ACL configuration, which is quite versatile enough to handle it — there's no need to call out to external software at all. For storage, it uses an sqlite database, again using Exim's built-in capabilities rather than calling out to an external database server. (Thanks to Jeff Garzik for that bit; I used to use simple text files with a fairly evil hack to append to them, but he converted it to sqlite for me after I added sqlite support to Exim.)