ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-04, Issue 38: MX queuing behavior with options

2007-06-01 06:55:35


On Thu, 31 May 2007, John C Klensin wrote:

I believe that, with the way the text in 2821 is written, a
client that is successful in opening an SMTP session (getting
the 220 greeting, sending an EHLO command, and getting a
response) to at least one of smtp1 or smtp2 is not permitted to
fall back to backup.foo.example under any circumstances.

No: it says "the SMTP client MUST be able to try each of the relevant
addresses in this list in order, until a delivery attempt succeeds", so
after a successfully established connection but a failed (4yz) delivery
the client will try another server.

Not necessarily, if for no other reason than that some believe there's
a difference between a successful *delivery* and a successful delivery
*attempt*.

As a practical matter the further in to the transaction the faiure occurs the
more time and resources the client has devoted to this one delivery (no doubt
out of many pending) and the less likely that other MXes will succeed where
this one has failed. The question is where to draw the line: Some
implementations do as you say and will retry all MXes in the event of a 4yz
error at any  point, others may give up on receipt of a 4xy as banner greeting
and still others put the cut point somewhere between the beginning and the end.
And there are also some clients that take the type of 4yz error into account.
But since clients don't have a crystal ball to consult this becomes a question
of what are the best heuristics to use.

My personal position is that it definitely makes sense to retry if the failure
occurs before a transaction has started, and retries after message data has
been transferred are more trouble than they are worth. Beyond that my opinion
varies depending on my mood and behavior I've observed recently.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>