ietf-smtp
[Top] [All Lists]

Re: Fixing graylisting [was TBR]

2007-11-13 13:22:46

David F. Skoll <dfs(_at_)roaringpenguin(_dot_)com> 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 <john(_at_)jlc(_dot_)net>