[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Steve
Sent: Tuesday, October 11, 2011 10:46 AM
To: SMTP Interest Group
Subject: Re: We need an IETF BCP for GREY LISTING
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.
That's true, though the disruption should be minor and not persistent as the
delayed sender is only delayed the first time he/she gets greylisted. In my
experience so far this hasn't been a major problem.
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.
I think "4xx" does exactly that. It sounds like what you're after is "Go away,
come back at time X" but only tell the good guys that. Perhaps this would be a
combination of 4xx load shedding coupled with greylisting merely as a way of
giving the hint to the good guys. This is where something actually specified
might be handy.