Frank Ellermann wrote:
On 30 October 2011 11:06, Hector Santos wrote:
I personally don't think this will work without
enforcement.
IBTD, it is "opt-in" on both sides. For starters
you can't "opt-in" if it's not yet implemented in
your SMTP. Some folks said that they would never
publish the retry details, because it could help
to defeat their GL in simple botnet clients.
That is why its OPTIONAL. :) Measure PROS/CONS on a per site basis,
not one's site patterns as a baseline for what should be globally done
or not done.
And of course clients are not forced to take the
hint, they can stick to their own retry strategy
based on RFC 5321.
Again, optional. I like to think the proposal offers a SMTP compliant
practical engineering solution to an existing issue. No new training
of how systems should behave. Simply adding optional client/server
negotiated "time data" to the words "temporary" and "try again later."
The "enforcement" is limited to "implement the
retry format as documented in RFC-to-be, because
that is your best chance for interoperability in
this (pun) grey area."
Enforcement is probably the wrong word, but protocols don't work well,
if its based on a Honor System and little to no regulations behind it.
And in view, the examples used (down, maintenance) unfortunately
muddles the water because its a different set of issues. For example,
if you are down, meaning no listening server is accepting connections,
that provides an explicit error condition that may be already factored
in MTA retry logics. I don't suspect an MTA is going to continue with
short initial retry delays for a down system. It may try other MX/IP
if any.
So if a response such as:
"421 domain, Wait=3600 NextMX=none"
is provided, that could indeed help preempt secondary MX/IP attempts.
But in my opinion, it SHOULD mean what it says so that the client is
not lied to and tries again and still finds the server is still
issuing 421s. Another participant commented he was concern about
servers that might lie about the hints. It would be very much similar
issue. Draft -02 has the follow to help address this concern:
If a SMTP server offers a "retry=time-delay" hint which results
in a wasted 2nd attempt and requires additional attempts, the
SMTP client MAY begin to ignore the server's "retry=time-delay" hint
after the 2nd wasted retry. The SMTP client implementation can
decide
what limits to place on honoring "retry=time-delay" hints and wasted
attempts it provides.
That is what I mean overall with "Enforcement" semantics and its more
appropriate IMO after the 421 and the SMTP is open for business.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net