RFC 974

Mail routing and the domain system

📅 published January 1986, from ietf

Status of this Memo ✨

Okay bestie, let's start with the title block 🎀. This is RFC 974, titled MAIL ROUTING AND THE DOMAIN SYSTEM. It was written by Craig Partridge of CSNET CIC BBN Laboratories Inc and dated January 1986 🌸. The header doesn't list any obsoletes or updates, so nothing gets replaced there 💅.

The memo describes how mail systems on the Internet are expected to route messages using the domain system from RFCs 882, 883 and 973 💌. Distribution of this memo is unlimited 🦋.

Introduction 🧚

So the whole point of this memo is to explain how mailers decide where to send a message addressed to a given Internet domain name 📬. This involves talking about how mailers read MX RRs, which are the records used for message routing 💜. Heads up though: this memo says nothing about how mailers handle MB and MG RRs, which are used for interpreting mailbox names 🙈.

Under RFC-882 and RFC-883, some of the old assumptions about mail addresses changed 😭. Before that, you could usually assume that if a message was addressed to a mailbox at something like LOKI.BBN.COM, you could just open an SMTP connection to LOKI.BBN.COM and hand the message over 📨. Honestly that system broke down in certain situations, like with certain UUCP and CSNET hosts that weren't directly attached to the Internet 💀. Those hosts got 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 🔥.

With domains, you can't just open a connection to LOKI.BBN.COM anymore 🙅‍♀️. You have to ask the domain system where messages to LOKI.BBN.COM should actually be delivered ✨. And the domain system might point the mailer at an entirely different host, like SH.CS.NET 🌈. Or, in a more complicated situation, the mailer might find out it has a choice of routes to LOKI.BBN.COM 👑. This memo is basically a set of guidelines for how mailers should behave in this more complex world 🫶.

Readers are expected to be familiar with RFCs 882 and 883, plus the updates to them, like RFC-973 🤓.

What the Domain Servers Know 💅

The domain servers store information as a series of resource records (RRs) 📚. Each one holds a specific piece of information about a domain name, which is usually a host but not always 🌷. The simplest way to picture an RR is as a typed pair of data: a domain name matched with relevant data, plus some extra type info so systems can tell when it's relevant 🎀.

For message routing, the system stores MX RRs 💌. Each MX matches a domain name with two pieces of data: a preference value, which is an unsigned 16-bit integer, and the name of a host 🦋. The preference number tells the mailer what order to try the MX hosts in, and the lowest numbered MX gets tried first 🥇. Multiple MXs can share the same preference, and when they do, they have the same priority 🍓.

The servers also store some other RR types that mailers might run into or decide to use 👀. One is the canonical name (CNAME) RR, which just says that the domain name you asked about is actually an alias for another domain name, the proper or canonical one 🧚. The other is the Well Known Service (WKS) RR, which holds info about network services, like SMTP, that a given domain name supports 🌸.

General Routing Guidelines 🌈

Before we get into the nitty gritty of how mailers do routing, it makes sense to get a quick overview of how this memo tackles the routing problem ✨.

The first big principle comes from how the preference field in MX records is defined, and it exists to stop mail from looping 🔁. If the mailer is on a host that's listed as an MX for the destination host, the mailer may only deliver to an MX with a lower preference count than its own host 👑. Main character rule, no loops 💜.

Mail can also loop because routing info is out of date or incomplete 😭. Out-of-date info is only a problem when domain tables change 🔄. The changes won't be known to every affected host until their resolver caches time out ⏳. There's no way to make this never happen short of making mailers and their resolvers always send queries to an authoritative server and never use cached data 🙅‍♀️. That's not practical, though, because getting rid of resolver caching would make mailing inordinately expensive 💸.

Here's the thing though: the out-of-date RR problem shouldn't happen if affected hosts (the ones in the list of MXs) get their resolver caches flushed when a domain table changes 🧹. So with proper precautions, mail looping from domain info should be avoidable, without making mailers query authoritative servers 🙌. (The right precaution is to check with a host's administrator before adding that host to a list of MXs 📞.)

Incomplete data needs some care too when handling domain queries 👀. If the answer section of a query is incomplete, critical MX RRs might get left out 😬. That can cause mail looping, or a message being wrongly labelled undeliverable 💀. So mailers may only accept responses from the domain system that have complete answer sections 🫶. This whole problem can be avoided by only using virtual circuits for queries, but since it's likely to be really rare, and datagrams are the preferred way to talk to the domain system, implementors should probably just make sure their mailer repeats a query with virtual circuits if the truncation bit ever gets set 🦋.

Determining Where to Send a Message 🎀

The way mailers should decide how to route a message is explained through a scenario: a mailer on a host with domain name LOCAL is trying to deliver a message addressed to the domain name REMOTE 💌. Both LOCAL and REMOTE are assumed to be syntactically correct domain names 🧠. Also, LOCAL is assumed to be the official name of the host the mailer lives on, so it's not an alias 🏠.

Issuing a Query 🔍

The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE 🚀. It's strongly urged that this step happens every single time a mailer tries to send a message 💖. The hope is that changes in the domain database get picked up by mailers quickly, so domain admins can re-route in-transit messages for defective hosts just by updating their domain databases 🪄.

Some responses to the query count as errors 🚨:

  • Getting no response to the query. The domain server the mailer queried never sends anything back. (This is different from an answer that has no answers to the query, which isn't an error 🙈.)
  • Getting a response where the truncation field of the header is set. (Remember the incomplete queries bit from above 👀.) Mailers may not use responses of this type, and should repeat the query using virtual circuits instead of datagrams 🔁.
  • Getting a response where the response code is non-zero 😬.

Mailers are expected to do something reasonable when they hit an error 🫶. How each type of error gets handled isn't specified here, but implementors should note that different error types should probably be treated differently 🌈. For example, a response code of "non-existent domain" should probably make the message get returned to the sender as invalid 💌, while a response code of "server failure" should probably make the message get retried later ⏰.

There's one more special case 👑. If the response contains an answer that's a CNAME RR, it means REMOTE is actually an alias for some other domain name 🎭. The query should be repeated using that canonical domain name 🔁.

If the response doesn't contain an error and doesn't contain aliases, its answer section should be a list of MX RRs for the domain name REMOTE (or REMOTE's true domain name, if REMOTE was an alias) 📋. The list can be zero length, so an empty answer is fine 🦋. The next section explains how this list gets interpreted ✨.

Interpreting the List of MX RRs ✨

okay bestie, this section is ONLY about how mailers choose which names to try delivering a message to, working from a list of RRs 📬 It does not cover how delivery actually happens. 🫶

NOTE 📝 Whenever this doc says "delivering a message," it just means the mailer does 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 actual mechanics of moving the message over the network to the address behind a domain name are not in scope for this memo. 🌸

It's possible 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.) The mailer should also skip any further processing of the list and attempt to deliver the message to REMOTE. 💖 The idea is that if a domain doesn't advertise anything about a particular name, we give it the benefit of the doubt and try delivery anyway. 🫶

If the list is not empty, the mailer should remove irrelevant RRs from it using 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 that 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 the irrelevant RRs, the list can be empty again. 💀 This is now an error condition, and it can happen in a few ways. The simplest case is that the WKS queries found that none of the listed hosts supports the mail service desired. The message is then deemed undeliverable, though extremely persistent mail systems might want to try delivering to REMOTE's address (if it exists) before returning the message. 🌈

The more dangerous possibility is that the domain system believes LOCAL is handling messages for REMOTE, but the mailer on LOCAL isn't 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, so clearly something is wrong. 🚨 How a mailer handles these situations is somewhat implementation dependent, so it's 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 first. 🎀 The mailer is required to attempt delivery to the lowest valued MX. Implementors are encouraged to write mailers that try the MXs in order until one of them accepts the message or all of them have been tried. 🔥 A somewhat less demanding system, where a fixed number of MXs is tried, is also reasonable. 🍓 Note that multiple MXs may share the same preference value. In that case, all MXs with a given value must be tried before any with a higher value are tried. 🌸 Also, in the special case where several MXs have the lowest preference value, all of them should be tried before a message is deemed undeliverable. 💜

Minor Special Issues 🔍

There are a couple of special issues left out of the previous section because they would have complicated the discussion. 🙃 They're covered here in no particular order. 🦋

Wildcard names, the ones containing the character *, may be used for mail routing. 🌈 There are likely to be servers on the network that simply say any mail to a domain should be routed through a relay. For example, when this RFC was being written, all mail to hosts in the domain IL was routed through RELAY.CS.NET. 🇮🇱 This is done by creating a wildcard RR that states *.IL has an MX of RELAY.CS.NET. This should be transparent to the mailer, since the domain servers 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. 🗑️

⚠️ Heads up! The algorithm to delete irrelevant RRs breaks if LOCAL has an alias and that 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 the 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 UNIX.BBN.COM accepts any responsibility for mail for .IL.) 🙅‍♀️ No chains, bestie!

Finally, this is a standard for routing on the Internet. Mailers serving hosts that lie on multiple networks will presumably have to make some decisions about which network to route through. 🛣️ That 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. 👑

Examples 🎀

To illustrate the discussion above, here are three examples of how mailers should route messages. 💖 All of them 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

Example one 🦋 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 isn't one of those MX RRs, and all three MXs support SMTP mail (according to the WKS entries), so none of the MXs get eliminated. 🙌 The mailer is obliged to try delivering to A.EXAMPLE.ORG as the lowest valued MX. If it can't reach A.EXAMPLE.ORG, it can (but isn't required to) try B.EXAMPLE.ORG. And if B.EXAMPLE.ORG isn't responding, it can try C.EXAMPLE.ORG. 🌈

Example two 🌸 This time the mailer is on B.EXAMPLE.ORG, and it's again trying to deliver a message addressed to A.EXAMPLE.ORG. There are once again three MX RRs for A.EXAMPLE.ORG, but here the mailer must discard the RRs for itself and for C.EXAMPLE.ORG, because the MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for B.EXAMPLE.ORG. 🫣 That leaves only the RR for A.EXAMPLE.ORG, so the mailer can only try delivery to A.EXAMPLE.ORG. 🎯

Example three 💜 Last one! 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, it should try the other MX (e.g., C.EXAMPLE.ORG). 🧚✨

📦 where this page comes from