Summary

  • An explicit SMTP source route was mutable envelope state. A relay consumed its own first element in the forward-path and moved an environment-appropriate identity into the reverse-path.
  • The route was not the absolute mailbox, and SMTP envelope paths were not the message's visible To: and From: fields. Neither path authenticated authorship or proved that the named relays had actually been traversed.
  • MX and globally meaningful domain names moved ordinary route choice from a sender-written itinerary to the sending MTA, DNS and local policy. Later SMTP kept recognizing the obsolete grammar without automatically restoring its former forwarding authority.

The recipient address had a part that was meant to disappear

Freeze an SMTP transaction after the client has supplied a reverse-path in MAIL FROM. For one recipient, it sends:

RCPT TO:<@ONE,@TWO:JOE@THREE>

RFC 821 calls the RCPT argument a forward-path. The colon divides two different ideas. JOE@THREE is the absolute mailbox: the final recipient identity within its destination domain. @ONE,@TWO is a source route: information about how to get there. The specification explicitly warns that route and mailbox must not be confused.

ONE recognizes itself as the first route element. It deletes that element, leaving @TWO:JOE@THREE for the next stage. At the same time, it inserts its own identifier at the beginning of the reverse-path. Information that had described an unperformed forward step now contributes to the return path for a failure discovered after responsibility has moved onward.

The address-like object therefore changed with custody. Its forward side contracted as instructions were performed. Its reverse side accumulated state behind the message. A relay was not simply looking up an unusually long destination; it was executing a distributed state transition.

The return path was not the reader's From field

SMTP's envelope and the message it carries occupy different surfaces. The reverse-path supplied by MAIL FROM helps allocate responsibility for delivery failures. It need not be the visible From: field. It is not Reply-To:, and it is not an authenticated statement about who wrote the body.

The forward-path supplied by RCPT TO likewise need not be copied into To: or Cc:. One message can have several envelope recipients. A blind-copy recipient may be absent from the visible header. A visible address may not be a recipient in this transaction at all.

RFC 822 separated a route-addr into a route and an addr-spec, while discouraging source routing unless a special need existed. That related message-format history does not collapse the envelope/header boundary. A route-like form in a header and the path received in an SMTP command are not interchangeable evidence.

When ONE moves its name backward, it does not rewrite the human author. An archive that keeps only the delivered message may have lost the original envelope route. Conversely, a reverse-path cannot be promoted into proof of authorship merely because it contains something shaped like an email address.

A relay could need a different name on the far side

RFC 821 gives ONE a subtle naming instruction. When adding itself to the reverse-path, it should use the name by which it is known in the environment into which it is sending, not necessarily the name used by the incoming environment.

That rule mattered at gateways between naming systems and mail communities. A source route looked like a complete map written by the originator, yet each boundary could require the current relay to restate its identity in a locally meaningful form. The characters alone did not contain every interpretation needed to bring an error back.

The relay also lacked a general right to delete whatever appeared first. If the leading forward-path element did not identify the current SMTP, it was not consumed. It could instead guide selection of the next SMTP. Consumption depended on the correspondence between position and identity.

None of this amounted to cryptographic authentication. A matching name did not prove control of a domain, honest traversal of a machine or agreement by every system in the list. The path supplied processing instructions. It did not notarize their execution.

MX did not move the relay list into DNS

RFC 974 associates a destination domain with mail exchangers and preference values. A sending SMTP queries the destination and tries appropriate exchangers under the stated rules. The user can keep addressing user@domain while the domain changes the hosts that receive its mail.

An MX set is not a serial list of mandatory waypoints. RFC 974 warns against recursively following the MX records of an exchanger to construct extravagant mail routes. The result of an MX lookup cannot be read as @ONE,@TWO stored somewhere else.

The architectural transfer was more consequential. The sender named a destination. The MTA selected a next action at send time, using DNS, reachability and local policy. The destination domain could change its receiving infrastructure without changing every mailbox identity or asking every correspondent to learn the new topology.

The repair surface changed with the authority. A stale explicit route could be copied through address books, aliases and queues. An MX change could be made at the administrative point responsible for the domain. Routing knowledge became a revisable decision rather than durable content in the address.

Retirement began by stopping new production

RFC 1123 says a Sender-SMTP should not send an explicit @...: source route in RCPT. Its architectural decision favored universal naming over source routing: a globally meaningful domain and the MX system were expected to cover the principal need.

The Receiver-SMTP still had to accept source-route syntax. “Accept” needs a narrow reading here. The receiver had to recognize the form; it did not have to provide unrestricted relay service to the client. If it did not implement the requested route, it could, under the specified conditions, attempt direct delivery to the domain to the right of the rightmost @.

That asymmetry is a deliberate retirement mechanism. New clients stop manufacturing an old form, while existing queues, gateways, aliases and software do not become unreadable on the same day. The ability to interpret an installed object survives longer than the authority to create more of it.

Removing both at once would turn stored state into syntax errors. Preserving full route authority indefinitely would prevent retirement. Compatibility occupies the productive middle: understand the old request, then make a current and observable decision about it.

A compatible parser was not an open relay

A server can parse @ONE,@TWO:JOE@THREE correctly and refuse to carry it for an unauthorized third party. Client authentication, source network, local destinations, permitted domains and anti-abuse policy govern relay permission. Grammar governs whether the command can be understood.

RFC 2821 marks source routes deprecated. Servers must be prepared to receive the syntax, should normally ignore the route and may decline relay. Clients should not generate it.

When a server ignores the route, it should not copy the listed relay names into the reverse-path. The forward-to-reverse movement described by RFC 821 belongs to the older route-using mode. It is not a hidden rewrite performed on every later SMTP message.

If a server exceptionally chooses to use the route, the specification constrains that choice: it must send toward the first domain shown and must not guess a shortcut. Explicitly using, ignoring or rejecting the route is auditable. Claiming to use it while silently reordering selected elements is not.

“The server accepted a source route” is therefore an incomplete incident statement. Did it accept the grammar, the recipient, relay authorization or responsibility after DATA? Those boundaries occur at different times and carry different consequences.

On mail islands, the user's map could be the missing infrastructure

RFC 1711, published in 1994, describes explicit source routing as integrating into the address an MTA through which the user wants the message to travel. When the message reaches that MTA, the MTA strips itself and routes the remainder normally.

The document gives the earlier design a concrete setting: sparsely connected “mail islands.” If a user knew a gateway connected to a remote island, placing that knowledge in the address could turn an abstract destination into a deliverable one. The source route supplied reachability information that the infrastructure did not yet distribute universally.

As the Internet became more fully interconnected, an end user's knowledge of mail topology ceased to be necessary for ordinary delivery and became vulnerable to staleness. RFC 1711 also notes inconsistent handling among relays as a reason explicit routing was strongly discouraged.

This is a historical assessment from 1994, not a present-day deployment measurement. It does not establish that every gateway, diagnostic use or isolated community vanished simultaneously. It does document a reversal in value: the user's static map shifted from filling a connectivity gap to competing with systems closer to current state.

Percent-hack addresses, UUCP bang paths and gateway mappings belong to the surrounding history, but they are not synonyms for the @relay1,@relay2:user@host grammar. They may bury routing in a local-part or apply different transformations. This article does not use them to blur the mechanism it is tracing.

The grammar outlived its ordinary reason

RFC 5321 says MX removed the normal need for explicit source routes and fully qualified domain-name requirements eliminated the last significant general justification. Clients should not generate them except in unusual circumstances such as debugging or a serious temporary DNS problem.

Servers still recognize the obsolete syntax. They may decline relay, ignore the route and process the final destination, or use it within the protocol's narrow constraints. Remaining in the grammar does not give the form a normal role in newly generated mail.

Ignoring the route does not guarantee rescue. Some invalid historical addresses depended on names that made sense only at an intermediate relay. Once the route is stripped, the final domain may not resolve in the global DNS. Compatibility cannot infer a vanished local naming context.

The honest operational state therefore has more than two values. A route can be recognized, preserved, ignored, rejected or used. Its final domain may resolve or fail. Responsibility may be declined during the transaction or accepted before a later delivery failure. A single “source routes supported” flag hides the decisions that matter.

A written itinerary could not prove an actual journey

Finding @ONE,@TWO in a stored field proves that the field contains those names. Without session evidence, it does not prove that ONE consumed its element, that TWO received a connection or that THREE accepted the message.

The inverse error is just as easy. Finding only JOE@THREE after normalization does not prove that the original command lacked a route. An edge MTA may have removed it. A collector may have stored only the parsed mailbox. The visible message headers may never have contained it.

Useful evidence keeps the raw command argument, session endpoints, time, parse result, policy decision, SMTP response, next-hop resolution and queue outcome. A normalized address is valuable for indexing, provided it remains labeled as a derivative rather than replacing what arrived.

Even the accumulated reverse-path was not an authenticated path attestation. It supported error handling; it did not guarantee that every named relay participated once, honestly and under control of the apparent domain. An inference has to stop where the field's specified function stops.

Sources and evidence boundary

The source set is RFC 821, RFC 822, RFC 974, RFC 1123, RFC 1711, RFC 2821 and RFC 5321. These close the grammar, normative transition and bounded historical interpretation. They do not measure current prevalence, product conformity, open-relay exposure, attack incidence or delivery success.

They also do not turn SMTP source routes into IPv4 Loose or Strict Source and Record Route. Both let a sender express path information at a high level of abstraction; their layer, object, processor, authority and retirement history remain different.