Summary

  • RFC 3461 let an SMTP client ask for success, failure or delay reports and carry a transaction identifier and an original-recipient identifier through relays. RFC 3464 gave the reply a machine-readable, per-recipient form.
  • The vocabulary deliberately stops short of certainty. delivered does not mean read, relayed marks a boundary beyond which successful-delivery evidence may disappear, and DSNs themselves can be forged or suppressed.

The traditional bounce had an awkward job. It had to tell a person that mail had failed, help an operator diagnose a route, and give software enough structure to match the notice to a submission. Often it was only another email with an improvised explanation and a fragment of the rejected message. A distribution-list operator could receive hundreds of such notices and still struggle to identify the failing host, the affected recipient or the sending transaction.

SMTP's acceptance rule made the ambiguity consequential. Once a server returned a positive reply to a recipient command, it normally accepted responsibility either to deliver the message or later report failure. Yet “send a report” concealed several decisions. Did the sender want success notices, failures, prolonged delays, or silence? Which address should survive a forwarding rewrite? Which of several otherwise identical submissions did the notice describe? Was the message delivered to a final agent, merely handed into another system, or expanded into more recipients?

The Delivery Status Notification family answered by separating those questions. RFC 3461 defined the request carried in the SMTP envelope. RFC 3464 defined the report. RFC 3463 supplied transport-independent status codes. Published together in January 2003, they replaced the earlier 189x specifications and made an old human nuisance into a protocol evidence channel.

Four parameters divided request from result

A server advertises support with the DSN keyword in its EHLO response. The extension adds no new SMTP verb. Instead, it gives existing MAIL and RCPT commands four optional parameters.

NOTIFY belongs to a particular recipient. It can request reports for SUCCESS, FAILURE and DELAY, or it can say NEVER. The last value must stand alone. If the parameter is absent, a server may preserve the traditional failure-only behavior or add delay notices. The sender selects the kinds of evidence it is willing to receive; it does not determine the outcome.

That distinction is clearest with delay. NOTIFY=DELAY does not set a timer. The MTA holding the message decides when the delay has become unusual, and at that moment the final state is still unknown. A delay report says that attempts continue. The same temporary condition may later accompany a failure report after the MTA abandons delivery.

RET belongs to the transaction. For a failed report, FULL asks for the entire original message and HDRS asks only for its headers. If no failed recipient appears, the standard says only headers should return. This is not cosmetic. Returning the body may make diagnosis easier, but it duplicates content into a new message and can widen disclosure.

The remaining two parameters carry identity. Their separation is the architecture's quiet achievement.

A message had more than one identity

ENVID is an envelope identifier attached to the MAIL command. If a DSN is issued, the identifier comes back as Original-Envelope-Id. The mail system does not interpret the token. Its meaning belongs to the sender or user agent that created it.

An envelope identifier is not the message header's Message-Id. The latter identifies content; the former identifies a submission transaction. The same content can be submitted twice, to different recipient sets or at different times. Conversely, one envelope transaction can contain several recipients whose outcomes diverge. Treating the two identifiers as interchangeable would erase precisely the distinction the report needs.

ORCPT preserves a different identity: the original recipient supplied by the sender. At initial submission, it must match RCPT TO. Later, forwarding can change the operational address while the original value travels alongside it. A message addressed to one mailbox may be relayed to another domain or mapped through a gateway whose address syntax looks nothing like Internet mail. The current route answers “where is this attempt going now?”; ORCPT answers “which sender-named recipient does this evidence concern?”

This pairing made automated reconciliation possible across changing paths. A program could match a DSN to the transaction using ENVID, then match each recipient group using the original-recipient field. Neither token proves a person's identity or authenticates the report. They are correlation handles, and their reliability depends on preservation by the chain.

The report separated action from reason

RFC 3464 gave DSNs a MIME structure. The first part is a human-readable explanation. The second is message/delivery-status, with fields about the message followed by one field group for each reported recipient. A third part may return the original message or its headers.

For every recipient, the reporting MTA states an Action: failed, delayed, delivered, relayed or expanded. It also supplies an enhanced Status code. RFC 3463 organizes those codes as three numbers: a 2 class for success, 4 for persistent transient failure and 5 for permanent failure, followed by subject and detail.

Action and status are intentionally not duplicates. A DNS timeout can produce a 4.x.x condition while the MTA still retries, so the action is delayed. Days later, the same class of condition may remain, but the queue gives up and the action becomes failed. The status describes the condition; the action records the decision the reporting system has taken.

The five actions also refuse a single, comforting meaning for “delivery.” failed is terminal: attempts have been abandoned. delayed is not terminal. delivered is terminal for that recipient, but can include delivery to a mailing-list exploder and never means a person read the message. expanded means a multiple-recipient alias accepted the message and created further recipients, so later failure or delay reports can still follow.

Most revealing is relayed. It means the message crossed into an environment that does not accept responsibility for successful-delivery DSNs. The reporting system can prove the handoff it made, not the eventual mailbox result. Instead of inventing certainty at a gateway, the protocol names the point where its evidence runs out.

Reliability required a one-way failure

A status report is itself mail, so it can also fail. If every failed DSN generated another DSN, two unreachable systems could manufacture a loop of notices about notices. The standards close that path. A DSN sent over SMTP uses the null reverse-path, MAIL FROM:<>, and a failed attempt to deliver it must not generate another network DSN.

This rule sacrifices recursive visibility to preserve system stability. The sender may never learn that the report was lost. That is preferable to an unbounded feedback loop. The design therefore offers reliable semantics within an explicit failure boundary, not guaranteed knowledge of every failure.

Relays create a second boundary. A conforming MTA passes the notification request and identifiers to another DSN-capable SMTP hop. When mail enters a foreign environment, the gateway makes a best effort to translate the request and later translate a report back. Some environments cannot promise success notification. Others use different address or diagnostic forms. relayed is the honest outcome when the chain can no longer preserve the same responsibility.

Confidential forwarding can narrow visibility deliberately. A recipient may forward mail to an address it does not wish to reveal. RFC 3464 allows an implementation to omit sensitive remote fields, stop downstream positive notifications or issue a relayed report at the boundary. Complete telemetry and recipient privacy are competing objectives; the standard does not pretend they can always coexist.

Structured did not mean authenticated

Machine readability made DSNs actionable, not trustworthy by construction. RFC 3464 states that a DSN can be forged as easily as ordinary Internet mail. A false success can persuade a system to stop escalation. A false failure can trigger retries, list removal or an unnecessary support case. A fabricated final recipient or remote MTA can misdirect an investigation.

ENVID does not repair this weakness. Because the sender chooses it and the mail system assigns no semantics, possession of a plausible token is correlation evidence, not cryptographic proof. Systems that automate decisions from DSNs still need transport and message-authentication context, replay controls, expected-recipient state and proportional consequences.

Returned content creates a separate exposure. RET=FULL can place an entire original message inside a failure report that traverses a different route and is stored in different logs or mailboxes. Headers alone can still expose correspondents, subjects and routing. The parameter lets the sender choose a trade-off; it cannot ensure every intermediate system handles the copy as intended.

A receipt became a map of limited authority

The historical importance of DSN lies less in making bounces prettier than in distributing authority accurately. The sender controls the request and its correlation tokens. Each MTA controls acceptance, retry and the action it reports. A gateway controls the fidelity of translation. A confidential forwarder can stop disclosure. The recipient's reading behavior remains outside SMTP altogether.

That allocation is visible in the vocabulary. NOTIFY expresses preference, not command. ENVID and ORCPT preserve identity without interpreting it. Action records a decision, while Status records a condition. relayed acknowledges lost observability. The null reverse-path makes one class of failure intentionally silent to prevent instability.

The IANA SMTP registry still lists DSN against RFC 3461. The registration preserves a capability whose most durable contribution is epistemic discipline. A report can say which transaction, which original recipient, which reporting system, which action and which diagnostic condition it describes. It also says, through its terminal states and gaps, how far that knowledge reaches.

The receipt could support queues, support desks, list hygiene and automated reconciliation. It could not promise inbox placement, human attention or truth beyond the reporting boundary. By resisting those larger claims, SMTP DSN made delivery evidence more useful than a generic bounce—and more honest than a universal receipt.

Sources