On Oct 28, 2011, at 12:28 PM, Rosenwald, Jordan wrote:
Perhaps I missed something (this has been a long thread), but I'm completely
missing how this will solve the problem of long, unpredictable delays for
users. Everything I've read says these are return codes for server
consumption, not to be returned to users.
As best I can tell this proposed idea does nothing for the end user.
Mail that's delivered quickly, in a minute or so, vs mail that sometimes takes
a half hour to deliver makes a difference to the end user. Both due to the
noticeable delay, and the annoyance of conversations arriving out of order.
Sometimes mailservers want to shed load, or prioritize one source of traffic
over another. The only way to do that within SMTP that doesn't require you to
keep a session open is to respond with a 4xx deferral and wait for the client
to retry.
An ESMTP client, such as your ISP smarthost, will wait a while before retrying
in response to a 4xx deferral. The RFCs say they should wait at least 30
minutes the first time.
If Yahoo!, uh, I mean the receivers MX, only needs to shed load for a short
time period, or just wants you to drop your open TCP session and go back to the
TCP connect queue so that someone else gets a chance then all they can do is
send that 4xx response and delay that mail delivery by 30 minutes or so.
It would be nice if the server could say "give me a minute to get my stuff
together and come back", have the client retry in 60 seconds and get the mail
accepted for delivery - with a delay of a minute or so, rather than a delay of
30 minutes. The server gets to shed load, the client gets to dump a message out
of it's queue and the human correspondents see fast, in-order mail delivery
rather than slow, out-of-order delivery.
That's the end-user visible part of the thought behind
https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/ anyway.
Cheers,
Steve