On Oct 12, 2011, at 1:15 AM, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
I think the only real value in this extension would be to reward clients
that recognize it, by providing their users with more predictable
service (=less delay, more uniform delay).
When I wrote my CEAS paper on greylisting, I found that very little
legit mail is affected by it. A reasonable greylister only delays the
first message seen from an IP, and after that whitelists it. (I
realize there are greylisters that delay every new [IP,from] or
[IP,from,to] but the solution is not to do that.) Very little legit
mail comes from an IP you've never seen before.
Every discussion list I know comes from a single IP or a very small
set of IPs, so the first message or more likely the subscription
confirmation might be delayed, but nothing after that.
I really don't see anything to fix.
There may not be anything to fix, but there's most certainly a lot to
break. The history of email agents parsing and processing time values isn't
exactly trouble free.
While true, that hardly seems like the thing that's most likely to break. My
guess is that most MTAs aren't set up to be able to (re)attempt delivery within
a particular time window.
One reason that I suggested a subset of ISO 8601 format (and even a subset of
that specified in RFC 3339) is that working ISO 8601 parsers are commonplace.
If there were interest, it should also be possible to craft an SMTP extension
so that the server would supply a token along with the 4xx message, to be used
when retrying. Then, if the client attempted to retransmit the file outside of
the assigned window, the server could respond with a different 4xx error
message:
4xx retry outside specified window, retry again between
YYMMDDTHHMMSSZ-YYYYMMDDTHHMMSSZ
...so that the broken client would get fixed. (The hardest thing about making
mail work right, IMO, is arranging for the errors indications to get to the
party most capable of fixing them).
Is any of this extra complexity actually worth the trouble? I have no idea.
Keith