Summary

  • In the original SMTP, 251 accepted an obsolete recipient and made the receiving server responsible for forwarding, while 551 rejected that recipient and returned a possible replacement for the sender to try.
  • Later standards allowed the same operational choices without revealing the replacement: an accepting server could answer 250, and a refusing server could answer 550.
  • A corrected path was never proof of personal identity or a global rename. Automatic future rerouting required trustworthy server evidence and a separate decision by the owner of stored address data.

Two replies that knew the same address

Consider one RCPT TO command addressed to a mailbox that has moved. Server A knows the replacement and returns 251. Server B knows the same replacement and returns 551. If a dashboard displays both as “user moved,” it erases the fact SMTP cared about most.

The 2 in 251 says the recipient step succeeded. Server A has accepted the old address for the current transaction and has taken responsibility for getting the message onward. The 5 in 551 says the recipient step failed permanently. Server B has not accepted responsibility; the sending side must decide whether to construct another attempt or report failure.

The path printed after each code may be identical. Responsibility is not.

The original protocol made the fork explicit

RFC 821 introduced both replies in 1982. Its forwarding section covered cases where the supplied forward-path was wrong but the receiving SMTP knew the correct destination. Either the host, the user name, or both could differ.

For 251 User not local; will forward, the receiver supplied the corrected path for future use and explicitly took responsibility for delivering the current message. For 551 User not local; please try, it refused mail for that recipient. The sender then had two choices: redirect according to the information or return an error to the originating user.

This was more than a convenient pair of messages. It kept a store-and-forward network honest about the point at which custody changed. A hint attached to acceptance could not be processed like a hint attached to refusal. The first current transaction continued; the second did not.

A current transaction was not an address-book edit

The distinction survives even if a client never stores the replacement. After 251, it must treat the old recipient as accepted. Sending the same message immediately to the suggested address as well could create a duplicate. After 551, treating the old recipient as accepted could silently lose the message.

Future behavior is a separate surface. The client might show the new path to a human, remember it for one retry, add an alias, update a contact or ignore it. RFC 5321 says servers using either code must not assume that clients will update address information or even return it to the user.

That refusal to assume is a durable design choice. SMTP can state the outcome it owns now. It cannot make every remote contact database converge on a new identity string.

Privacy made silence a valid forwarding policy

By the time RFC 2821 restated SMTP in 2001, silent forwarding was common. Enterprise aliases simplified addresses; personal forwarding linked an old mailbox to a new one. But exposing the final destination could reveal an internal host, a private account or an address the sender could not reach directly.

The protocol therefore separated responsibility from disclosure. An accepting server may forward and return ordinary 250, revealing no corrected address. A refusing server may return 550 without replacement details. RFC 5321 retains both choices and recommends configuration controls for sites that need to restrict 251 or 551.

Four outcomes become possible: accept and disclose, accept and conceal, reject and disclose, reject and conceal. A privacy policy changes the evidence released to the sender; it need not falsify who owns delivery.

Some moved mailboxes have no public path

The enhanced status vocabulary makes that boundary even clearer. RFC 3463 defined X.1.6 for a destination mailbox that moved with no forwarding address. The current IANA SMTP Enhanced Status Codes Registry preserves that description as a permanent-failure status.

“No forwarding address” can mean none exists, none is usable by this server, or none is being disclosed on this surface. It does not license the client to infer a destination from a header, an old delivery trace or a third-party directory. Absence of a referral is a complete protocol state, not a gap to fill with guesswork.

RFC 3464 reaches the same boundary from delivery reports. It warns that DSNs can be forged and recognizes users who autoforward without wanting the destination revealed. Implementations should offer a way to keep that address confidential. The message may travel farther while the original sender learns less.

A machine-readable path created a rerouting attack

Most SMTP reply text is for humans and may vary. The corrected path in 251 and 551 is an exception: clients need to parse it if they intend to act on it. That makes the response operationally useful and security-sensitive.

RFC 5321 warns that before a client automatically changes future behavior—such as updating an address book—it should be certain of the server's authenticity. An interposed attacker who substitutes a mailbox can redirect not only this message but every later message after the forged “correction” is stored.

Authentication still proves less than many interfaces imply. It can establish which server supplied the reply. It does not prove that the new mailbox belongs to the same human, that the change is permanent, or that one administrator may overwrite another person's canonical contact record. Transport authenticity is necessary evidence for automation, not universal naming authority.

Forwarding changed a recipient, not the authored message

RFC 5598 later described Internet mail as a set of roles. A normal relay moves a message without changing envelope addresses. An alias is different: it resubmits toward one or more alternate recipients while retaining the original message and usually the original return address.

That small envelope change carries a large semantic decision. The designated recipient has chosen another recipient. If delivery later fails, a report may go back to the original author, who does not know the hidden alias existed. Forwarding therefore redistributes operational responsibility without rewriting the visible To field or the author's intended message identity.

This is why a corrected SMTP path should not be described as an Internet-wide rename. It is one site's statement about how it will handle, or refuse, one envelope recipient. The message header, address book, personal identity and future routing remain independently governed records.

The history is a lesson in bounded correction

The elegant part of 251 and 551 is not that they exposed a new address. It is that they kept three questions apart: Was this recipient accepted? Who must act next? May the replacement be disclosed?

Later security practice added a fourth: who may make the change durable? The safest client acts on the current numeric outcome first, treats the path as protected evidence, and requires stronger authorization before altering future correspondence.

SMTP could help a message follow a person without claiming to rename the person. That restraint let forwarding remain useful even when the final address had to disappear from the reply.