ietf-asrg
[Top] [All Lists]

Re: [Asrg] LIMP: Local Interpretation of MX Priority

2003-04-22 08:27:44
From: "Alan DeKok" <aland(_at_)freeradius(_dot_)org>

...
  You're stuck on verbiage from the RFC's, to the point where any
proposed approach which *doesn't* use SMTP verbiage is rejected out of
hand by you.  (That's not entirely true, you reject pretty much every
proposal, so far as I've been able to tell.)

...
People who lack field-specific vocabularly tend to also lack field-specific
knowledge.

  That's fine, but it shouldn't interfere with the "field experts"
ability to understand general concepts.

...
  I guess I won't rely on RFC 974 any more.

  "Implementors are encouraged to write mailers so that they try the
   MXs in order until one of the MXs accepts the message, or all the MXs
   have been tried."

  RFC 2821, Section 5 says:

   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds. 

  But why should I believe the RFC's, if you disagree with them?

In practice, those words are understood as applying only to a single "queue
run" or attempt to send a message.  An SMTP client tries the MX servers
for a domain name until it finds one that answers the TCP SYN.  It then
tries to delivere the message.  If it receives a 5yz result, it forgets
entirely about the message (except for the exception that is treated like
a 4yz result).  If it receives a 4yz result, it saves the message but
forgets all of the details of its efforts until the next "queue run."
Your notion is based on one or or both the obviously bad ideas:

  1. STMP clients treat a 4yz as needing an immediate retry at another
     SMTP server.  This is obviously bad because 4yz responses mean
     "try again *LATER*."  MX RRs often point to the same host (e.g.
     when it is multi-homed) and even if not, trying again immediately
     at an SMTP server related to one that has said "I'm too busy try
     again later" violates the spirit of "try again later."

  2. SMTP clients remember which the MX servers they have tried in
     previous "queue runs".  This is obviously a bad idea because
     it would make it make it hard to change DNS data if SMTP clients
     cached it indefinitely.  No, SMTP clients could not look at old
     and new DNS data and merge changes.  Moreover, after the RFC 2821
     suggested 30 minute delay (see section 4.5.4.1) it would be
     silly to restart with a secondary or tertiary MX server.

Please do not send me any more mail.  We lack sufficient mutual regard.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



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