[Top] [All Lists]

Re: Putting it all together

2011-10-30 16:55:54

Frank Ellermann wrote:
On 30 October 2011 11:06, Hector Santos wrote:

I personally don't think this will work without

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.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net