David F. Skoll <[EMAIL PROTECTED]> wrote: > John Leslie wrote: > >> 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.
I'd say it has a far better idea than current graylisting does. The originator has logs to see whether the URI has been accessed: I see no reason the originator would take down an unreferenced URI in less than a few days. > It can (I suppose) confidently assume it will remain valid for a few > hours. Maybe even a day. I would restate that as "It can confidently assume anything taken down before being accessed after less than one day is very likely to have been abusive." > Any longer is risky. I'm hard-pressed to think of a case where you'd need more than 24 hours get "good enough" reputation information. > 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.) I suppose we could add a formal requirement: it doesn't seem necessary to me. I expect originators to keep things available for at least a week or two in the normal case -- taking down URIs where the logs show successful access, and possibly expiring some URIs according to a schedule the user requests. >> 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. That's a good implementation practice, though IMHO the period to keep it off needs to be configurable. -- John Leslie <[EMAIL PROTECTED]>
