Summary

  • Ordinary SMTP mail supplies a reverse-path for later delivery reports. A notification uses MAIL FROM:<> so failure of the notification cannot demand another notification and create an error loop.
  • The null path is an explicit envelope state, not a missing From: header, anonymous legitimacy or permission to skip controls. Submission must support it, and SPF can evaluate the sending host through HELO.
  • Structured DSNs improved correlation and per-recipient evidence, but they retained the terminal sender. When remote reporting stops, responsibility moves to local logs or postmaster handling rather than disappearing.

A reliable promise creates an awkward second message

SMTP can reject a recipient while the sending client is still connected. In that case, the negative reply carries the failure inside the existing transaction. The client knows it still owns the message. No new email is required.

The harder case begins after acceptance. A relay may return positive completion after DATA because it has stored the message and accepted responsibility, then discover later that the next system is unreachable, a mailbox is gone or a downstream gateway cannot complete delivery. The original sender is no longer on the connection. The failure itself must become mail.

That second message needs a recipient: the reverse-path from the original envelope. It appears also to need a sender, because SMTP normally names a reverse-path in MAIL FROM. But giving the notification an ordinary return mailbox creates a recursive promise. If the notification cannot be delivered, the next server sends a notification to the notification's sender. If that new notice also fails, the process can repeat.

The protocol needed to report failure without promising to report the failure of the report.

Empty brackets carried positive meaning

RFC 821 recognized the problem in 1982. A server that had accepted a relay task and later could not deliver was to construct an undeliverable-mail notification for the original reverse-path. The document also warned that servers should not send notification messages about problems with notification messages.

Its loop-breaking device was a null reverse-path in the notification's MAIL command:

MAIL FROM:<>

The angle brackets do not describe a mailbox with a blank local part. They encode an intentional absence in the SMTP envelope: there is no remote mailbox to which another delivery notice should be sent. A receiver may still accept and deliver the message to its actual RCPT TO destination. Only the backward notification edge is removed.

This is why “senderless” is a misleading description. The notification was generated by a mail system, travelled over a connection and can carry trace evidence. What it lacks is not a producer but a remote failure destination.

A suggestion became a host requirement

The original SMTP text described null as one way to prevent loops. RFC 1123 hardened the behavior in 1989. An empty reverse-path had to be supported. A receiver could no longer treat MAIL FROM:<> as malformed merely because an ordinary address was absent.

RFC 1123 also completed the termination rule. A notification about a failure discovered after acceptance must use a null reverse-path. If the address to which that notification would be sent is already null, the receiver must not send it.

Two obligations therefore meet at the empty value. Systems must accept the syntax because valid infrastructure mail uses it. Systems must also interpret it as a stop signal when considering another notification. Implementing only one side breaks the design: rejecting every null sender loses legitimate reports; accepting the syntax and bouncing it recreates recursion.

Envelope and message belonged to different conversations

The reverse-path is an SMTP transaction value. It is not the reader-facing From: field. It is not Reply-To, and it is not a claim that nobody authored the body.

An automatic notification can have a human-readable From address naming a service operator, so a reader can understand who produced it or report a malfunction. Its envelope can simultaneously be MAIL FROM:<>, telling transport software not to create a DSN if this message fails.

That separation is essential. Header From participates in a human conversation. Reply-To can tell a person where a considered response should go. Envelope reverse-path allocates machine responsibility for delivery failure. Copying one surface into another because it “looks like an email address” changes the control graph.

The mistake is common in generic automation. A program sees no envelope sender, finds a visible From address and answers it. The program has just restored the edge that the mail system removed to prevent a loop. Syntax-aware software must preserve absence rather than fill it.

The point of acceptance determined the remedy

The empty reverse-path also illuminates SMTP's responsibility model. Under RFC 5321, positive completion after DATA is a formal handoff. The receiver takes responsibility for delivery, further relay or subsequent notification. Before that response, the sender can still receive an immediate rejection and keep control.

The safest failure is often the earliest defensible one. If a receiving system can determine during the transaction that a recipient is invalid or a policy refuses the message, a negative SMTP reply informs the actual connected client. It does not create a separate bounce addressed to a possibly forged reverse-path.

Some failures cannot be known in time. Mailing-list expansion, temporary DNS problems, downstream gateways and later local processing can reveal them only after acceptance. In those cases, notification mail is unavoidable. The null sender contains the new risk by ensuring the generated branch has no further remote report branch.

This boundary later became important in backscatter. If malicious ordinary mail supplies the address of an uninvolved victim as its reverse-path, accept-then-bounce sends traffic to that victim. Null on the DSN prevents recursive bounces, but it does not undo the first misdirected notification. Early rejection and sender/host authorization solve adjacent parts of the problem.

Termination did not mean silent destruction

What happens if a valid DSN itself cannot be delivered? The remote protocol conversation ends, but operational responsibility remains.

RFC 5321 allows the local system to log or otherwise transmit information about null-address failures inside the same environment. It notes that sites may direct failed notifications to a postmaster able to repair the mail system. The key is that this path must not create another external DSN.

The difference is governance as much as mechanics. A remote notice tries to return a delivery fact to the party that named a reverse-path. A local escalation tells the operator, “Our terminal report could not reach its destination; inspect configuration, queue and routing.” One moves responsibility across domains. The other keeps it with the system that has reached the protocol's end state.

Null is therefore not an excuse to discard evidence. Queue IDs, original envelope data, recipient status and diagnostic results still need retention proportional to operational and privacy requirements. The empty path says who must not be mailed, not what the operator may forget.

DSN requests became explicit

Early nondelivery notices varied widely. Human text differed by product and language, and automation had difficulty correlating reports with recipients. RFC 3461 added an SMTP extension for Delivery Status Notifications.

Its parameters separated several choices. ENVID carries an envelope identifier selected for correlation. RET asks for headers or more of the original content in a returned report. NOTIFY can request SUCCESS, FAILURE or DELAY reports; NEVER stands alone and requests none. ORCPT preserves the original recipient address when rewriting or gatewaying might otherwise lose it.

These parameters describe evidence and reporting preferences. They do not make an otherwise valid recipient valid or invalid, and a server is not meant to change its MAIL or RCPT acceptance decision merely because valid DSN parameters appear.

The termination invariant remained stronger than the new detail. A conforming MTA must not issue a DSN for any message whose MAIL FROM was null, even if a plausible sender appears in the message headers. Guessing defeats the transport signal. The local postmaster can be informed through a path that will not itself produce DSNs.

When a DSN is transmitted, its sender address must be null. RET must not be used on the DSN's own transaction. If NOTIFY is present, it must be NEVER. The report can contain rich delivery evidence while categorically refusing to ask for a report about itself.

A bounce became a structured report

RFC 3464 defined the DSN format. A DSN is a MIME multipart/report with report type delivery-status. It can contain a human-readable explanation, a machine-readable message/delivery-status part and selected material from the original message under the applicable return and privacy rules.

One DSN concerns exactly one original message but may contain separate blocks for multiple recipients. The Action field can distinguish failed, delayed, delivered, relayed and expanded outcomes. Status carries a structured code. Reporting MTA, arrival data, remote MTA, diagnostic information and retry horizon can support investigation.

This evolution matters because “failed” and “delayed” are different claims. A delayed report says attempts continue; a failed report says the reporting MTA has abandoned that recipient. A human paragraph might blur the difference. Structured fields allow a user agent or list manager to update state without parsing prose.

Yet structure is not authentication. RFC 3464 treats forgery and confidentiality as real concerns. A DSN can expose original recipients, forwarding addresses and message material. A malicious actor can fabricate report-looking content. The format improves evidence granularity; it does not provide non-repudiation.

The null reverse-path remains necessary because better evidence does not remove recursion. Indeed, a larger structured report could make an error loop more expensive.

Partial delivery made one message many outcomes

An original message may name several recipients. Some deliveries can succeed while others fail or remain delayed. A single textual “delivery failed” cannot safely represent that state.

Per-recipient DSN blocks preserve the partition. Operators and applications can ask which address failed, which was delayed, what the last remote response was and whether further attempts are planned. The original envelope identifier can connect those outcomes to the submission without asserting that the visible Message-ID is a unique transport transaction.

That distinction supports responsible automation. A mailing list may remove or suspend one repeatedly failing subscription without treating every subscriber as failed. A sender can retain a pending state for one address while considering another delivered.

It also creates privacy pressure. A report that reveals confidential forwarding addresses or every expanded member can expose information the original sender was not entitled to learn. RFC 3464 permits omission or boundary changes in such cases. Evidence should be sufficient for the authorized decision, not maximal because the protocol can carry it.

Vacation bots inherited the same termination problem

Delivery reports are not the only automatic messages. Vacation responders, group services, help systems and content processors can all answer incoming mail. Two responders can trigger each other; one responder can amplify a forged request toward a victim; a reply guessed from a visible header can reach the wrong person.

RFC 3834 generalizes the discipline. A responder must not generate a response whose destination would be a null address. Automatic responses should normally go to the envelope Return-Path, not be guessed from human-oriented From or Reply-To fields.

Where a response itself should not receive an automatic answer, it may use MAIL FROM:<>. If the DSN extension is available, NOTIFY=NEVER is recommended. The responder states both its terminal envelope and its reporting preference.

Null prevents an automatic-response chain from continuing, but it does not solve amplification. Return addresses are often forged. RFC 3834 warns service responders against sending large replies or creating side effects without reason to believe the affected party authorized the request. A stop bit and an authorization check guard different edges.

Submission had to accept legitimate emptiness

Anti-abuse policy can tempt systems to reject every message that lacks an ordinary envelope sender. RFC 6409, which separates message submission from relay, rejects that shortcut. A null return path is permitted and must not by itself cause rejection. Mail user agents legitimately generate null-sender messages, including disposition notifications.

That rule does not demand blind acceptance. A submission agent can authenticate the submitting account, enforce authorization, rate limits and content policy, and reject inconsistent use. What it cannot do is use the null value alone as proof of abuse.

This is a recurring Internet design lesson: a value reserved for control looks anomalous if a security layer ignores protocol semantics. Treating every anomaly as hostility makes conforming behavior impossible. Treating every reserved value as trusted creates the opposite failure. The system must recognize the state and then apply the controls appropriate to it.

Host authorization survived the empty mailbox

The absence of an envelope mailbox also raised a question for SPF, which normally evaluates the MAIL FROM domain. RFC 7208 defines a deterministic answer. When the reverse-path is null, the MAIL FROM identity is constructed as postmaster at the HELO identity. This gives the sending host/domain an authorization surface even though no sender mailbox exists.

HELO checking does not authenticate the DSN body or prove that the reported failure happened. SPF authorizes a host in relation to a domain. An authorized server can emit an incorrect notification; a forged DSN can travel through an unrelated system; a valid report can fail SPF because of configuration.

The significance is narrower. Null does not mean that all identity and policy evaluation disappears. The protocol moves evaluation from a nonexistent mailbox to an identity the SMTP client already supplies for the session.

Null MX was a different kind of nothing

SMTP contains another famous null-shaped mechanism: null MX. The two should not be conflated. Null MX is a DNS statement that a domain does not accept email. Null reverse-path is an envelope value on a message that is actively being transmitted and may need to be accepted.

One suppresses attempts to deliver mail to a domain. The other suppresses generation of a delivery report for one transaction. Rejecting MAIL FROM:<> because a product associates “null” with “no mail” confuses namespace capability with message responsibility.

The Internet repeatedly uses explicit absence when silence would be ambiguous. Here the angle brackets distinguish “the sender field was forgotten” from “this notification is the end of remote failure reporting.”

Sources and evidence limits

The original undeliverable-mail notification and MAIL FROM:<> loop breaker are in RFC 821: https://www.rfc-editor.org/rfc/rfc821.html

Mandatory empty-path support and the prohibition on notifying a null return address are in RFC 1123: https://www.rfc-editor.org/rfc/rfc1123.html

DSN envelope parameters, null-sender handling and NOTIFY=NEVER are in RFC 3461: https://www.rfc-editor.org/rfc/rfc3461.html

The structured multipart DSN, per-message/per-recipient fields and privacy/security limits are in RFC 3464: https://www.rfc-editor.org/rfc/rfc3464.html

Rules for vacation, group and service responders are in RFC 3834: https://www.rfc-editor.org/rfc/rfc3834.html

The current responsibility handoff, null-sender message classes, forwarding discipline and local postmaster option are in RFC 5321: https://www.rfc-editor.org/rfc/rfc5321.html

Legitimate null-sender behavior at message submission is in RFC 6409: https://www.rfc-editor.org/rfc/rfc6409.html

HELO-based SPF identity for a null reverse-path is in RFC 7208: https://www.rfc-editor.org/rfc/rfc7208.html

These RFCs establish protocol requirements, not the authenticity of a particular DSN or current deployment behavior. Null sender is neither proof of legitimacy nor proof of abuse. DSN fields are reports rather than non-repudiation, and this article makes no claim about present bounce volume, rejection rates, provider policy or spam prevalence.