rfc974.txt

RFC 相关的技术文档

   this list is interpreted.

Interpreting the List of MX RRs

   NOTE: This section only discusses how mailers choose which names to
   try to deliver a message to, working from a list of RR's.  It does
   not discuss how the mailers actually make delivery.  Where ever
   delivering a message is mentioned, all that is meant is that the
   mailer should do whatever it needs to do to transfer a message to a
   remote site, given a domain name for that site.  (For example, an
   SMTP mailer will try to get an address for the domain name, which
   involves another query to the domain system, and then, if it gets an
   address, connect to the SMTP TCP port).  The mechanics of actually
   transferring the message over the network to the address associated
   with a given domain name is not within the scope of this memo.

   It is possible that the list of MXs in the response to the query will
   be empty.  This is a special case.  If the list is empty, mailers
   should treat it as if it contained one RR, an MX RR with a preference
   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
   MX).  In addition, the mailer should do no further processing on the
   list, but should attempt to deliver the message to REMOTE.  The idea




Partridge                                                       [Page 4]



RFC 974                                                     January 1986
Mail Routing and the Domain System


   here is that if a domain fails to advertise any information about a
   particular name we will give it the benefit of the doubt and attempt
   delivery.

   If the list is not empty, the mailer should remove irrelevant RR's
   from the list according to the following steps.  Note that the order
   is significant.

      For each MX, a WKS query should be issued to see if the domain
      name listed actually supports the mail service desired.  MX RRs
      which list domain names which do not support the service should be
      discarded.  This step is optional, but strongly encouraged.

      If the domain name LOCAL is listed as an MX RR, all MX RRs with a
      preference value greater than or equal to that of LOCAL's must be
      discarded.

   After removing irrelevant RRs, the list can again be empty.  This is
   now an error condition and can occur in several ways.  The simplest
   case is that the WKS queries have discovered that none of the hosts
   listed supports the mail service desired.  The message is thus deemed
   undeliverable, though extremely persistent mail systems might want to
   try a delivery to REMOTE's address (if it exists) before returning
   the message. Another, more dangerous, possibility is that the domain
   system believes that LOCAL is handling message for REMOTE, but the
   mailer on LOCAL is not set up to handle mail for REMOTE.  For
   example, if the domain system lists LOCAL as the only MX for REMOTE,
   LOCAL will delete all the entries in the list.  But LOCAL is
   presumably querying the domain system because it didn't know what to
   do with a message addressed to REMOTE. Clearly something is wrong.
   How a mailer chooses to handle these situations is to some extent
   implementation dependent, and is thus left to the implementor's
   discretion.

   If the list of MX RRs is not empty, the mailer should try to deliver
   the message to the MXs in order (lowest preference value tried
   first).  The mailer is required to attempt delivery to the lowest
   valued MX.  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.  A somewhat less demanding system, in which
   a fixed number of MXs is tried, is also reasonable.  Note that
   multiple MXs may have the same preference value.  In this case, all
   MXs at with a given value must be tried before any of a higher value
   are tried.  In addition, in the special case in which there are
   several MXs with the lowest preference value,  all of them should be
   tried before a message is deemed undeliverable.



Partridge                                                       [Page 5]



RFC 974                                                     January 1986
Mail Routing and the Domain System


Minor Special Issues

   There are a couple of special issues left out of the preceding
   section because they complicated the discussion.  They are treated
   here in no particular order.

   Wildcard names, those containing the character '*' in them, may be
   used for mail routing.  There are likely to be servers on the network
   which simply state that any mail to a domain is to be routed through
   a relay. For example, at the time that this RFC is being written, all
   mail to hosts in the domain IL is routed through RELAY.CS.NET.  This
   is done by creating a wildcard RR, which states that *.IL has an MX
   of RELAY.CS.NET.  This should be transparent to the mailer since the
   domain servers will hide this wildcard match. (If it matches *.IL
   with HUJI.IL for example, a domain server will return an RR
   containing HUJI.IL, not *.IL). If by some accident a mailer receives
   an RR with a wildcard domain name in its name or data section it
   should discard the RR.

   Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
   a alias and the alias is listed in the MX records for REMOTE.  (E.g.
   REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
   can be avoided if aliases are never used in the data section of MX
   RRs.

   Implementors should understand that the query and interpretation of
   the query is only performed for REMOTE.  It is not repeated for the
   MX RRs listed for REMOTE.  You cannot try to support more extravagant
   mail routing by building a chain of MXs.  (E.g. UNIX.BBN.COM is an MX
   for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
   but this does not mean that UNIX.BBN.COM accepts any responsibility
   for mail for .IL).

   Finally, it should be noted that this is a standard for routing on
   the Internet.  Mailers serving hosts which lie on multiple networks
   will presumably have to make some decisions about which network to
   route through. This decision making is outside the scope of this
   memo, although mailers may well use the domain system to help them
   decide.  However, once a mailer decides to deliver a message via the
   Internet it must apply these rules to route the message.









Partridge                                                       [Page 6]



RFC 974                                                     January 1986
Mail Routing and the Domain System


Examples

   To illustrate the discussion above, here are three examples of how
   mailers should route messages.  All examples work with the following
   database:

      A.EXAMPLE.ORG    IN    MX    10    A.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    MX    15    B.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    MX    20    C.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    WKS   10.0.0.1    TCP    SMTP

      B.EXAMPLE.ORG    IN    MX    0      B.EXAMPLE.ORG
      B.EXAMPLE.ORG    IN    MX    10     C.EXAMPLE.ORG
      B.EXAMPLE.ORG    IN    WKS   10.0.0.2    TCP    SMTP

      C.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
      C.EXAMPLE.ORG    IN    WKS   10.0.0.3    TCP    SMTP

      D.EXAMPLE.ORG    IN    MX    0     D.EXAMPLE.ORG
      D.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
      D.EXAMPLE.ORG    IN    WKS   10.0.0.4    TCP    SMTP

   In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
   deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
   query, it learns that A.EXAMPLE.ORG has three MX RRs.  D.EXAMPLE.ORG
   is not one of the MX RRs and all three MXs support SMTP mail
   (determined from the WKS entries), so none of the MXs are eliminated.
   The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
   lowest valued MX.  If it cannot reach A.EXAMPLE.ORG it can (but is
   not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
   responding, it can try C.EXAMPLE.ORG.

   In the second example, the mailer is on B.EXAMPLE.ORG, and is again
   trying to deliver a message addressed to A.EXAMPLE.ORG.  There are
   once again three MX RRs for A.EXAMPLE.ORG, but in this case the
   mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
   MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
   B.EXAMPLE.ORG).  It is left only with the RR for A.EXAMPLE.ORG, and
   can only try delivery to A.EXAMPLE.ORG.

   In the third example, consider a mailer on A.EXAMPLE.ORG trying to
   deliver a message to D.EXAMPLE.ORG.  In this case there are only two
   MX RRs, both with the same preference value.  Either MX will accept
   messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
   one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
   and if that delivery fails should try the other MX (e.g.
   C.EXAMPLE.ORG).


Partridge                                                       [Page 7]