rfc974.txt

RFC 相关的技术文档

Network Working Group                                    Craig Partridge
Request for Comments: 974                 CSNET CIC BBN Laboratories Inc
                                                            January 1986

                   MAIL ROUTING AND THE DOMAIN SYSTEM


Status of this Memo

   This RFC presents a description of how mail systems on the Internet
   are expected to route messages based on information from the domain
   system described in RFCs 882, 883 and 973.  Distribution of this memo
   is unlimited.

Introduction

   The purpose of this memo is to explain how mailers are to decide how
   to route a message addressed to a given Internet domain name.  This
   involves a discussion of how mailers interpret MX RRs, which are used
   for message routing.  Note that this memo makes no statement about
   how mailers are to deal with MB and MG RRs, which are used for
   interpreting mailbox names.

   Under RFC-882 and RFC-883 certain assumptions about mail addresses
   have been changed.  Up to now, one could usually assume that if a
   message was addressed to a mailbox, for example, at LOKI.BBN.COM,
   that one could just open an SMTP connection to LOKI.BBN.COM and pass
   the message along.  This system broke down in certain situations,
   such as for certain UUCP and CSNET hosts which were not directly
   attached to the Internet, but these hosts could be handled as special
   cases in configuration files (for example, most mailers were set up
   to automatically forward mail addressed to a CSNET host to
   CSNET-RELAY.ARPA).

   Under domains, one cannot simply open a connection to LOKI.BBN.COM,
   but must instead ask the domain system where messages to LOKI.BBN.COM
   are to be delivered. And the domain system may direct a mailer to
   deliver messages to an entirely different host, such as SH.CS.NET.
   Or, in a more complicated case, the mailer may learn that it has a
   choice of routes to LOKI.BBN.COM.  This memo is essentially a set of
   guidelines on how mailers should behave in this more complex world.

   Readers are expected to be familiar with RFCs 882, 883, and the
   updates to them (e.g., RFC-973).









Partridge                                                       [Page 1]



RFC 974                                                     January 1986
Mail Routing and the Domain System


What the Domain Servers Know

   The domain servers store information as a series of resource records
   (RRs), each of which contains a particular piece of information about
   a given domain name (which is usually, but not always, a host).  The
   simplest way to think of a RR is as a typed pair of datum, a domain
   name matched with relevant data, and stored with some additional type
   information to help systems determine when the RR is relevant.  For
   the purposes of message routing, the system stores RRs known as MX
   RRs. Each MX matches a domain name with two pieces of data, a
   preference value (an unsigned 16-bit integer), and the name of a
   host.  The preference number is used to indicate in what order the
   mailer should attempt deliver to the MX hosts, with the lowest
   numbered MX being the one to try first.  Multiple MXs with the same
   preference are permitted and have the same priority.

   In addition to mail information, the servers store certain other
   types of RR's which mailers may encounter or choose to use.  These
   are: the canonical name (CNAME) RR, which simply states that the
   domain name queried for is actually an alias for another domain name,
   which is the proper, or canonical, name; and the Well Known Service
   (WKS) RR, which stores information about network services (such as
   SMTP) a given domain name supports.

General Routing Guidelines

   Before delving into a detailed discussion of how mailers are expected
   to do mail routing, it would seem to make sense to give a brief
   overview of how this memo is approaching the problems that routing
   poses.

   The first major principle is derived from the definition of the
   preference field in MX records, and is intended to prevent mail
   looping.  If the mailer is on a host which is listed as an MX for the
   destination host, the mailer may only deliver to an MX which has a
   lower preference count than its own host.

   It is also possible to cause mail looping because routing information
   is out of date or incomplete.  Out of date information is only a
   problem when domain tables are changed.  The changes will not be
   known to all affected hosts until their resolver caches time out.
   There is no way to ensure that this will not happen short of
   requiring mailers and their resolvers to always send their queries to
   an authoritative server, and never use data stored in a cache.  This
   is an impractical solution, since eliminating resolver caching would
   make mailing inordinately expensive.  What is more, the out-of-date
   RR problem should not happen if, when a domain table is changed,


Partridge                                                       [Page 2]



RFC 974                                                     January 1986
Mail Routing and the Domain System


   affected hosts (those in the list of MXs) have their resolver caches
   flushed. In other words, given proper precautions, mail looping as a
   result of domain information should be avoidable, without requiring
   mailers to query authoritative servers.  (The appropriate precaution
   is to check with a host's administrator before adding that host to a
   list of MXs).

   The incomplete data problem also requires some care when handling
   domain queries.  If the answer section of a query is incomplete
   critical MX RRs may be left out.  This may result in mail looping, or
   in a message being mistakenly labelled undeliverable.  As a result,
   mailers may only accept responses from the domain system which have
   complete answer sections.  Note that this entire problem can be
   avoided by only using virtual circuits for queries, but since this
   situation is likely to be very rare and datagrams are the preferred
   way to interact with the domain system, implementors should probably
   just ensure that their mailer will repeat a query with virtual
   circuits should the truncation bit ever be set.

Determining Where to Send a Message

   The explanation of how mailers should decide how to route a message
   is discussed in terms of the problem of a mailer on a host with
   domain name LOCAL trying to deliver a message addressed to the domain
   name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
   correct domain names.  Furthermore, LOCAL is assumed to be the
   official name for the host on which the mailer resides (i.e., it is
   not a alias).

Issuing a Query

   The first step for the mailer at LOCAL is to issue a query for MX RRs
   for REMOTE.  It is strongly urged that this step be taken every time
   a mailer attempts to send the message.  The hope is that changes in
   the domain database will rapidly be used by mailers, and thus domain
   administrators will be able to re-route in-transit messages for
   defective hosts by simply changing their domain databases.

   Certain responses to the query are considered errors:

      Getting no response to the query.  The domain server the mailer
      queried never sends anything back.  (This is distinct from an
      answer which contains no answers to the query, which is not an
      error).

      Getting a response in which the truncation field of the header is



Partridge                                                       [Page 3]



RFC 974                                                     January 1986
Mail Routing and the Domain System


      set.  (Recall discussion of incomplete queries above).  Mailers
      may not use responses of this type, and should repeat the query
      using virtual circuits instead of datagrams.

      Getting a response in which the response code is non-zero.

   Mailers are expected to do something reasonable in the face of an
   error.  The behaviour for each type of error is not specified here,
   but implementors should note that different types of errors should
   probably be treated differently.  For example, a response code of
   "non-existent domain" should probably cause the message to be
   returned to the sender as invalid, while a response code of "server
   failure" should probably cause the message to be retried later.

   There is one other special case.  If the response contains an answer
   which is a CNAME RR, it indicates that REMOTE is actually an alias
   for some other domain name. The query should be repeated with the
   canonical domain name.

   If the response does not contain an error response, and does not
   contain aliases, its answer section should be a (possibly zero
   length) list of MX RRs for domain name REMOTE (or REMOTE's true
   domain name if REMOTE was a alias).  The next section describes how