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.
