When I wrote my CEAS paper on greylisting, I found that very little
legit mail is affected by it. A reasonable greylister only delays the
first message seen from an IP, and after that whitelists it. (I
realize there are greylisters that delay every new [IP,from] or
[IP,from,to] but the solution is not to do that.) Very little legit
mail comes from an IP you've never seen before.
In the several years that we've been running GL on our servers I've yet to
see a single legit message not get through. The false positive rate is as
close to zero as one can get as long as you are running a sane
configuration. And as the checks are done during the SMTP transaction, we
save a lot by not having to queue on the backend. HUGE savings on backend
The problem is the initial delays in messages (we run [IP,from,to]) - takes
a bit of education of the users, and the initial responses are not always
positive. I think we're running a 10 minute timeout for most systems, and
have noticed delays in retries of an hour or more in some cases depending on
the sending side configurations.
Some configurations that have been mentioned (greylisting *everything* and
setting ridiculously long timeout windows for instance) in my opinion are
terribly broken configurations. If a BCP can help people understand how
this fits into the grand scheme of things then perhaps it is a good thing.
For those that run with a one day window - I'm surprised how they can keep
their jobs - it would seem to me that with the progressive backoff
algorighims used by senders this would result in regular and consistent loss
of email, not to mention unwarranted message delays. Protocol changes will
not protect us from administrators lacking common sense and the ability to
properly configure their systems.
Every discussion list I know comes from a single IP or a very small
set of IPs, so the first message or more likely the subscription
confirmation might be delayed, but nothing after that.
I really don't see anything to fix.