+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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
+ 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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
projects / unix-history / commitdiff