John Leslie wrote:
I quite agree that graylisting needs fixing (and Doug and I did try
to sneak some fixing into TBR).
I don't see what's broken about a good greylisting implementation.
[...]
I look upon graylisting as a temporary measure to gain time for
better information about the sender -- not just whether they keep state
and run the queues.
Yes, that's what it is.
The "fix" Doug and I put into TBR is to extend the time to formal
handoff, by any amount the receiving mail system may choose, which
accomplishes much of what keeping the TCP connection open would -- at
a far smaller cost (the queue of URIs could be written to disk, for
one example).
Except the receiving mail system cannot really choose "any amount", because
it has no idea for how long the URI will remain valid. It can (I suppose)
confidently assume it will remain valid for a few hours. Maybe even a day.
Any longer is risky.
So unless you have a formal requirement for how long the URI must remain
valid, you're still at the mercy of the sender's queueing policy (as
with greylisting.)
What would others like to see in a fix for graylisting?
A good greylisting implementation will turn off greylisting once a
host has been known to retry, and keep it off for that host for some
fairly long time (like a month or so.) This greatly reduces the
annoying impact of greylisting on legitimate MTAs without much
reducing its effectiveness.
The enormous advantage of greylisting over TBR is that it doesn't
require an ESMTP extension, so it doesn't require a significant
percentage of the Internet to adopt it for it to be useful.
Regards,
David.