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.
Past experience says otherwise.
My guess is that most MTAs aren't set up to be able to (re)attempt delivery
within a particular time window.
Which is exactly my point. This is a tricky thing to add to an existing
queuing strategy.
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.
Which is effectively saying that the simplest and easiest part of this is
simple and easy. Which is obviously true but barely relevant.
Ned