Summary

  • RFC 821 let a sender place an explicit relay sequence before a destination mailbox; each relay consumed its own name and moved it into the return path.
  • RFC 1123 shifted ordinary Internet mail toward universal domain names and DNS MX routing. Receivers still had to accept the old syntax, but they could discard the requested relays and use the final mailbox domain.
  • Current SMTP keeps that distinction: a server may ignore, reject or deliberately execute a source route. Parsing a legacy form is not authorization to relay and not a promise to obey it.

One path, three conforming outcomes

Suppose a client sends:

RCPT TO:<[relay alpha, relay beta]:[mailbox user in domain gamma]>

The notation contains two different objects. The user mailbox in domain gamma is the destination. The names before the colon are a proposed sequence of relays. A server can recognize both without granting them the same authority.

One current server may strip the alpha-and-beta relay prefix and route toward gamma.example. Another may refuse an address that asks it to relay. A third, operating under an exceptional policy, may use the source route and contact alpha.example first. The syntax has not changed between the three transactions. What changed is who is entitled to choose the next hop.

That is the historical lesson hidden in an obsolete-looking address. Internet protocols sometimes retain an old language so that new systems can meet old input safely. They do not have to preserve every power that language once exercised.

When the sender supplied the itinerary

RFC 822 called the construction a route-addr. Its route portion listed hosts or transmission services that the originator wanted the message to traverse, while the address after the colon remained the global mailbox.

RFC 821 made that route operational in the SMTP envelope. Its example listed relays ONE and TWO before JOE's mailbox in domain THREE, deliberately separating the mailbox from instructions for reaching it. When a message arrived at a named relay, the relay removed its own identifier from the forward-path, inserted that identifier at the front of the reverse-path, became a sender and contacted the next SMTP in the list.

The two paths were a moving ledger. The forward side recorded work still requested; the reverse side accumulated a route back toward the originator for a later failure. A relay that accepted the task also accepted responsibility for the next transfer. It could still reject the task, just as it could reject a local recipient. The route was an instruction inside a transaction, not a universal right to use any host.

RFC 821 also kept the envelope distinct from the authored message. These paths appeared in MAIL FROM and RCPT TO; they did not need to appear in To, From or CC. A reader-visible address and a transport itinerary could therefore diverge without either becoming the other.

Universal names replaced serial directions

By 1989, the architecture had changed. RFC 1123 told sending SMTPs not to generate explicit source routes. Its explanation was unusually direct: Internet mail had chosen universal naming rather than source routing. SMTP provided connectivity, the DNS supplied globally unique and location-independent names, and MX records handled the main case that once appeared to require a sender-written relay sequence.

The result was not a ban on relays. A domain can still designate mail exchangers, and several servers may carry a message before delivery. The difference is authority. The sender names the destination domain; DNS and the participating servers determine the available next hop under current policy. An address no longer doubles as a private routing table imposed by the originator.

This move also made route repair local. If an exchanger changes, the destination domain can update DNS without requiring every correspondent to learn a new list. The sender's durable record remains the mailbox domain rather than yesterday's topology.

Compatibility without obedience

RFC 1123 did not simply make the old form a syntax error. A receiving SMTP had to accept the explicit route syntax, but a server that did not implement the relay function should try the terminal mailbox domain. Its worked example removes relays ALPHA and BETA from the path and routes JOE's mailbox directly toward domain GAMMA.

RFC 2821 sharpened the rule. Senders should not create source routes. Receivers must recognize them but should strip the route and use the domain associated with the mailbox as though no route had been supplied. Relay names must not be copied into the reverse-path. A compatibility parser could no longer rebuild RFC 821's moving return route merely because it saw familiar punctuation.

This distinction prevents two opposite failures. A receiver that cannot parse the old grammar may mistake delimiters for mailbox data or reject mail that it could safely route. A receiver that automatically obeys every parsed hop can let a legacy token choose an intermediate server outside current relay policy. Recognition protects interoperability; non-obedience protects the contemporary trust boundary.

The old grammar still has bounded meaning

RFC 5321 retains A-d-l—the comma-separated domain list—in the normative path grammar. Its compact instruction carries the whole compromise: the form must be accepted, should not be generated and should be ignored.

The surrounding rules matter. A server may decline relay service or refuse an address containing a route. It may ignore the route and use the last destination. If it deliberately uses the route, however, it must send to the first domain shown and must not invent a shortcut. Compatibility does not mean that all interpretations are interchangeable.

The standard also identifies a migration trap. Some senders used invalid final destination names and expected an intermediate relay to resolve them. Once a conforming server strips the route, that hidden dependency fails. A string can remain grammatically valid while an assumption embedded in its old execution model becomes invalid.

Source routes remain available for unusual debugging or severe temporary configuration trouble. Those exceptions do not restore them as routine sender authority. They make route execution an explicit operational decision whose evidence and risk belong to the server choosing it.

Header history followed the same boundary

RFC 5322 retains the route form in its obsolete message-address grammar and says the route portion should be ignored when interpreting an address. That rule is adjacent to SMTP but not identical to it. A header parser accepting an old route-addr does not create an SMTP envelope instruction, just as a To field does not prove which recipients the SMTP transaction actually carried.

The separation is useful in archives. Old mail can remain readable without treating historical punctuation as a live forwarding command. Preservation of meaning requires knowing which layer owned the field and which parts of its former behavior survived.

Sources and limits

The transition is documented by RFC 821, RFC 822, RFC 1123, RFC 2821, RFC 5321 and RFC 5322. Together they establish the grammar and standards obligations, not how often modern products encounter or execute source routes. They do not show current vendor defaults, filtering rates or delivery success.

The durable result is narrower and more important. SMTP learned to say: “I understand the route you wrote” without saying “you control my route.”