On Oct 11, 2011, at 10:32 AM, Murray S. Kucherawy wrote:
I think someone should take up the effort to begin/draft an GreyList
BCP for systems to follow.
Comments?
I'm not sure that it's worth the trouble. The whole point of
greylisting is to marginalize naive client implementations on the
assumption (largely valid to this point) that they're likely to be
spambots. But I expect that spambots will start to deal with
greylisting very soon. If IETF were to document greylisting it would
only accelerate that process.
I agree. I don't see what additional interoperability needs to be specified
here that isn't already handled by RFC5321. 4xx means retry, and that's it.
If, as a server, I give a hint as to when a retry will succeed, I'm giving
the bad guys information that I don't want them to have, while a compliant
RFC5321 implementation will do just fine as it is.
For classic greylisting that's all quite true (he whole point of greylisting is
the assumption that bad actors will not retry, while good actors will).
Greylisting does damage some forms of email, though - discussion lists, where
emails are delayed by seemingly arbitrary amounts, breaking up the flow of
conversation are one - but I can't think of any good way to mitigate that
damage other than telling servers not to use greylisting or telling clients to
retry quickly, neither of which seems like a good idea.
There's a vaguely related situation, though, where the current protocol isn't
ideal, and that's when an SMTP server wants to put some control on the volume
of mail it's being sent (by a specific SMTP client). The scarce resource is
number of concurrent sessions, not total bandwidth, so the appropriate level at
which to throttle is the SMTP session level. Yahoo, as one example, uses 4xx
deferrals in order to shed load or to reserve capacity for high value mail at
the expense of low value mail. That's not an ideal approach, as the SMTP
clients have no consistent retry policy, so it's a fairly crude tool for
capacity management. In that case, some minor extension to allow the SMTP
server to communicate something a bit more nuanced than "Go away, come back
later." might have some value.
Cheers,
Steve