Commit | Line | Data |
---|---|---|
83b3156e C |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f |