Re: We need an IETF BCP for GREY LISTING

[Steve Atkins <steve@xxxxxxxxxxx>]

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