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.
----- Original Message -----
From: Peter J. Holzer [mailto:hjp-ietf-smtp(_at_)hjp(_dot_)at]
Sent: Friday, October 28, 2011 03:10 PM
To: ietf-smtp(_at_)imc(_dot_)org <ietf-smtp(_at_)imc(_dot_)org>
Subject: Re: SMTP traffic control
On 2011-10-24 15:38:16 -0700, Carl S. Gutekunst wrote:
Hector wrote:
Personally I think this is a solution looking for a problem.
The cliche is nice, but there is a recognized problem and a
reproducible proof of concept solution possible to help minimize the
impact.
Hector, I've seen nothing in the past two of weeks of discussion that
identify a "problem."
It may not be a problem for you. For some (many?) users long and
unpredictable delays in mail delivery are a problem, especially if the
mail is sent during a phone call.
Such delays can be reduced and regularized if the server can provide
information about when to retry (and possibly other info, like the
number of allowed concurrent connections) to the client.
I really don't understand the resistance against the idea. Some servers
and some clients will implement it and benefit from it (if they are
talking to each other), others won't and for them everything will be as
before. How would a standardized way of conveying the same information
that some servers already convey informally hurt the mail system?
hp
--
_ | Peter J. Holzer | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR | "Netz der kleinen Geister".
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Oliver Cromm in desd