diff options
Diffstat (limited to 'doc/rfc/rfc974.txt')
| -rw-r--r-- | doc/rfc/rfc974.txt | 399 |
1 files changed, 399 insertions, 0 deletions
diff --git a/doc/rfc/rfc974.txt b/doc/rfc/rfc974.txt new file mode 100644 index 0000000..97d79a4 --- /dev/null +++ b/doc/rfc/rfc974.txt @@ -0,0 +1,399 @@ + + +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 + 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] + |