![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc974.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc|
Return to rfc974.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc |
1.1 root 1:
2:
3: Network Working Group Craig Partridge
4: Request for Comments: 974 CSNET CIC BBN Laboratories Inc
5: January 1986
6:
7: MAIL ROUTING AND THE DOMAIN SYSTEM
8:
9:
10: Status of this Memo
11:
12: This RFC presents a description of how mail systems on the Internet
13: are expected to route messages based on information from the domain
14: system described in RFCs 882, 883 and 973. Distribution of this memo
15: is unlimited.
16:
17: Introduction
18:
19: The purpose of this memo is to explain how mailers are to decide how
20: to route a message addressed to a given Internet domain name. This
21: involves a discussion of how mailers interpret MX RRs, which are used
22: for message routing. Note that this memo makes no statement about
23: how mailers are to deal with MB and MG RRs, which are used for
24: interpreting mailbox names.
25:
26: Under RFC-882 and RFC-883 certain assumptions about mail addresses
27: have been changed. Up to now, one could usually assume that if a
28: message was addressed to a mailbox, for example, at LOKI.BBN.COM,
29: that one could just open an SMTP connection to LOKI.BBN.COM and pass
30: the message along. This system broke down in certain situations,
31: such as for certain UUCP and CSNET hosts which were not directly
32: attached to the Internet, but these hosts could be handled as special
33: cases in configuration files (for example, most mailers were set up
34: to automatically forward mail addressed to a CSNET host to
35: CSNET-RELAY.ARPA).
36:
37: Under domains, one cannot simply open a connection to LOKI.BBN.COM,
38: but must instead ask the domain system where messages to LOKI.BBN.COM
39: are to be delivered. And the domain system may direct a mailer to
40: deliver messages to an entirely different host, such as SH.CS.NET.
41: Or, in a more complicated case, the mailer may learn that it has a
42: choice of routes to LOKI.BBN.COM. This memo is essentially a set of
43: guidelines on how mailers should behave in this more complex world.
44:
45: Readers are expected to be familiar with RFCs 882, 883, and the
46: updates to them (e.g., RFC-973).
47:
48:
49:
50:
51:
52:
53:
54:
55:
56: Partridge [Page 1]
57:
58:
59:
60: RFC 974 January 1986
61: Mail Routing and the Domain System
62:
63:
64: What the Domain Servers Know
65:
66: The domain servers store information as a series of resource records
67: (RRs), each of which contains a particular piece of information about
68: a given domain name (which is usually, but not always, a host). The
69: simplest way to think of a RR is as a typed pair of datum, a domain
70: name matched with relevant data, and stored with some additional type
71: information to help systems determine when the RR is relevant. For
72: the purposes of message routing, the system stores RRs known as MX
73: RRs. Each MX matches a domain name with two pieces of data, a
74: preference value (an unsigned 16-bit integer), and the name of a
75: host. The preference number is used to indicate in what order the
76: mailer should attempt deliver to the MX hosts, with the lowest
77: numbered MX being the one to try first. Multiple MXs with the same
78: preference are permitted and have the same priority.
79:
80: In addition to mail information, the servers store certain other
81: types of RR's which mailers may encounter or choose to use. These
82: are: the canonical name (CNAME) RR, which simply states that the
83: domain name queried for is actually an alias for another domain name,
84: which is the proper, or canonical, name; and the Well Known Service
85: (WKS) RR, which stores information about network services (such as
86: SMTP) a given domain name supports.
87:
88: General Routing Guidelines
89:
90: Before delving into a detailed discussion of how mailers are expected
91: to do mail routing, it would seem to make sense to give a brief
92: overview of how this memo is approaching the problems that routing
93: poses.
94:
95: The first major principle is derived from the definition of the
96: preference field in MX records, and is intended to prevent mail
97: looping. If the mailer is on a host which is listed as an MX for the
98: destination host, the mailer may only deliver to an MX which has a
99: lower preference count than its own host.
100:
101: It is also possible to cause mail looping because routing information
102: is out of date or incomplete. Out of date information is only a
103: problem when domain tables are changed. The changes will not be
104: known to all affected hosts until their resolver caches time out.
105: There is no way to ensure that this will not happen short of
106: requiring mailers and their resolvers to always send their queries to
107: an authoritative server, and never use data stored in a cache. This
108: is an impractical solution, since eliminating resolver caching would
109: make mailing inordinately expensive. What is more, the out-of-date
110: RR problem should not happen if, when a domain table is changed,
111:
112:
113: Partridge [Page 2]
114:
115:
116:
117: RFC 974 January 1986
118: Mail Routing and the Domain System
119:
120:
121: affected hosts (those in the list of MXs) have their resolver caches
122: flushed. In other words, given proper precautions, mail looping as a
123: result of domain information should be avoidable, without requiring
124: mailers to query authoritative servers. (The appropriate precaution
125: is to check with a host's administrator before adding that host to a
126: list of MXs).
127:
128: The incomplete data problem also requires some care when handling
129: domain queries. If the answer section of a query is incomplete
130: critical MX RRs may be left out. This may result in mail looping, or
131: in a message being mistakenly labelled undeliverable. As a result,
132: mailers may only accept responses from the domain system which have
133: complete answer sections. Note that this entire problem can be
134: avoided by only using virtual circuits for queries, but since this
135: situation is likely to be very rare and datagrams are the preferred
136: way to interact with the domain system, implementors should probably
137: just ensure that their mailer will repeat a query with virtual
138: circuits should the truncation bit ever be set.
139:
140: Determining Where to Send a Message
141:
142: The explanation of how mailers should decide how to route a message
143: is discussed in terms of the problem of a mailer on a host with
144: domain name LOCAL trying to deliver a message addressed to the domain
145: name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
146: correct domain names. Furthermore, LOCAL is assumed to be the
147: official name for the host on which the mailer resides (i.e., it is
148: not a alias).
149:
150: Issuing a Query
151:
152: The first step for the mailer at LOCAL is to issue a query for MX RRs
153: for REMOTE. It is strongly urged that this step be taken every time
154: a mailer attempts to send the message. The hope is that changes in
155: the domain database will rapidly be used by mailers, and thus domain
156: administrators will be able to re-route in-transit messages for
157: defective hosts by simply changing their domain databases.
158:
159: Certain responses to the query are considered errors:
160:
161: Getting no response to the query. The domain server the mailer
162: queried never sends anything back. (This is distinct from an
163: answer which contains no answers to the query, which is not an
164: error).
165:
166: Getting a response in which the truncation field of the header is
167:
168:
169:
170: Partridge [Page 3]
171:
172:
173:
174: RFC 974 January 1986
175: Mail Routing and the Domain System
176:
177:
178: set. (Recall discussion of incomplete queries above). Mailers
179: may not use responses of this type, and should repeat the query
180: using virtual circuits instead of datagrams.
181:
182: Getting a response in which the response code is non-zero.
183:
184: Mailers are expected to do something reasonable in the face of an
185: error. The behaviour for each type of error is not specified here,
186: but implementors should note that different types of errors should
187: probably be treated differently. For example, a response code of
188: "non-existent domain" should probably cause the message to be
189: returned to the sender as invalid, while a response code of "server
190: failure" should probably cause the message to be retried later.
191:
192: There is one other special case. If the response contains an answer
193: which is a CNAME RR, it indicates that REMOTE is actually an alias
194: for some other domain name. The query should be repeated with the
195: canonical domain name.
196:
197: If the response does not contain an error response, and does not
198: contain aliases, its answer section should be a (possibly zero
199: length) list of MX RRs for domain name REMOTE (or REMOTE's true
200: domain name if REMOTE was a alias). The next section describes how
201: this list is interpreted.
202:
203: Interpreting the List of MX RRs
204:
205: NOTE: This section only discusses how mailers choose which names to
206: try to deliver a message to, working from a list of RR's. It does
207: not discuss how the mailers actually make delivery. Where ever
208: delivering a message is mentioned, all that is meant is that the
209: mailer should do whatever it needs to do to transfer a message to a
210: remote site, given a domain name for that site. (For example, an
211: SMTP mailer will try to get an address for the domain name, which
212: involves another query to the domain system, and then, if it gets an
213: address, connect to the SMTP TCP port). The mechanics of actually
214: transferring the message over the network to the address associated
215: with a given domain name is not within the scope of this memo.
216:
217: It is possible that the list of MXs in the response to the query will
218: be empty. This is a special case. If the list is empty, mailers
219: should treat it as if it contained one RR, an MX RR with a preference
220: value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
221: MX). In addition, the mailer should do no further processing on the
222: list, but should attempt to deliver the message to REMOTE. The idea
223:
224:
225:
226:
227: Partridge [Page 4]
228:
229:
230:
231: RFC 974 January 1986
232: Mail Routing and the Domain System
233:
234:
235: here is that if a domain fails to advertise any information about a
236: particular name we will give it the benefit of the doubt and attempt
237: delivery.
238:
239: If the list is not empty, the mailer should remove irrelevant RR's
240: from the list according to the following steps. Note that the order
241: is significant.
242:
243: For each MX, a WKS query should be issued to see if the domain
244: name listed actually supports the mail service desired. MX RRs
245: which list domain names which do not support the service should be
246: discarded. This step is optional, but strongly encouraged.
247:
248: If the domain name LOCAL is listed as an MX RR, all MX RRs with a
249: preference value greater than or equal to that of LOCAL's must be
250: discarded.
251:
252: After removing irrelevant RRs, the list can again be empty. This is
253: now an error condition and can occur in several ways. The simplest
254: case is that the WKS queries have discovered that none of the hosts
255: listed supports the mail service desired. The message is thus deemed
256: undeliverable, though extremely persistent mail systems might want to
257: try a delivery to REMOTE's address (if it exists) before returning
258: the message. Another, more dangerous, possibility is that the domain
259: system believes that LOCAL is handling message for REMOTE, but the
260: mailer on LOCAL is not set up to handle mail for REMOTE. For
261: example, if the domain system lists LOCAL as the only MX for REMOTE,
262: LOCAL will delete all the entries in the list. But LOCAL is
263: presumably querying the domain system because it didn't know what to
264: do with a message addressed to REMOTE. Clearly something is wrong.
265: How a mailer chooses to handle these situations is to some extent
266: implementation dependent, and is thus left to the implementor's
267: discretion.
268:
269: If the list of MX RRs is not empty, the mailer should try to deliver
270: the message to the MXs in order (lowest preference value tried
271: first). The mailer is required to attempt delivery to the lowest
272: valued MX. Implementors are encouraged to write mailers so that they
273: try the MXs in order until one of the MXs accepts the message, or all
274: the MXs have been tried. A somewhat less demanding system, in which
275: a fixed number of MXs is tried, is also reasonable. Note that
276: multiple MXs may have the same preference value. In this case, all
277: MXs at with a given value must be tried before any of a higher value
278: are tried. In addition, in the special case in which there are
279: several MXs with the lowest preference value, all of them should be
280: tried before a message is deemed undeliverable.
281:
282:
283:
284: Partridge [Page 5]
285:
286:
287:
288: RFC 974 January 1986
289: Mail Routing and the Domain System
290:
291:
292: Minor Special Issues
293:
294: There are a couple of special issues left out of the preceding
295: section because they complicated the discussion. They are treated
296: here in no particular order.
297:
298: Wildcard names, those containing the character '*' in them, may be
299: used for mail routing. There are likely to be servers on the network
300: which simply state that any mail to a domain is to be routed through
301: a relay. For example, at the time that this RFC is being written, all
302: mail to hosts in the domain IL is routed through RELAY.CS.NET. This
303: is done by creating a wildcard RR, which states that *.IL has an MX
304: of RELAY.CS.NET. This should be transparent to the mailer since the
305: domain servers will hide this wildcard match. (If it matches *.IL
306: with HUJI.IL for example, a domain server will return an RR
307: containing HUJI.IL, not *.IL). If by some accident a mailer receives
308: an RR with a wildcard domain name in its name or data section it
309: should discard the RR.
310:
311: Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
312: a alias and the alias is listed in the MX records for REMOTE. (E.g.
313: REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
314: can be avoided if aliases are never used in the data section of MX
315: RRs.
316:
317: Implementors should understand that the query and interpretation of
318: the query is only performed for REMOTE. It is not repeated for the
319: MX RRs listed for REMOTE. You cannot try to support more extravagant
320: mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX
321: for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
322: but this does not mean that UNIX.BBN.COM accepts any responsibility
323: for mail for .IL).
324:
325: Finally, it should be noted that this is a standard for routing on
326: the Internet. Mailers serving hosts which lie on multiple networks
327: will presumably have to make some decisions about which network to
328: route through. This decision making is outside the scope of this
329: memo, although mailers may well use the domain system to help them
330: decide. However, once a mailer decides to deliver a message via the
331: Internet it must apply these rules to route the message.
332:
333:
334:
335:
336:
337:
338:
339:
340:
341: Partridge [Page 6]
342:
343:
344:
345: RFC 974 January 1986
346: Mail Routing and the Domain System
347:
348:
349: Examples
350:
351: To illustrate the discussion above, here are three examples of how
352: mailers should route messages. All examples work with the following
353: database:
354:
355: A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG
356: A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG
357: A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG
358: A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP
359:
360: B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG
361: B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG
362: B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP
363:
364: C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
365: C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP
366:
367: D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG
368: D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
369: D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP
370:
371: In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
372: deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
373: query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.ORG
374: is not one of the MX RRs and all three MXs support SMTP mail
375: (determined from the WKS entries), so none of the MXs are eliminated.
376: The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
377: lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but is
378: not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
379: responding, it can try C.EXAMPLE.ORG.
380:
381: In the second example, the mailer is on B.EXAMPLE.ORG, and is again
382: trying to deliver a message addressed to A.EXAMPLE.ORG. There are
383: once again three MX RRs for A.EXAMPLE.ORG, but in this case the
384: mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
385: MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
386: B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG, and
387: can only try delivery to A.EXAMPLE.ORG.
388:
389: In the third example, consider a mailer on A.EXAMPLE.ORG trying to
390: deliver a message to D.EXAMPLE.ORG. In this case there are only two
391: MX RRs, both with the same preference value. Either MX will accept
392: messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
393: one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
394: and if that delivery fails should try the other MX (e.g.
395: C.EXAMPLE.ORG).
396:
397:
398: Partridge [Page 7]
399:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.