It's amazing how many greylisting implementations miss all
three of these fairly obvious points. I often see my
outgoing mails
being delayed due to greylisting, by hosts which I deliver
mail to all the time. That's just stupid. They
know it's going to be retried, so all they achieve
is a delay on mail that they're going to accept
later anyway.

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