ietf-smtp
[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-11 12:57:29


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