Summary

  • In RFC 5321, a positive completion reply to the final DATA terminator means that the receiving SMTP server has accepted the message and taken responsibility for delivering or relaying it. It is a custody handoff, not a destination receipt.
  • The digits cannot be interpreted without the command and transaction state. A 250 after EHLO, MAIL, RCPT, RSET or NOOP says something different from the 250 after the message body.
  • A defensible mail record joins the accepted envelope, recipient replies, final DATA reply, queue custody, each downstream handoff and any later per-recipient result. Mailbox placement, policy filtering and human reading remain independent facts.

The green line arrived before the message did

An incident report contains one reassuring row:

05:14:08 remote response 250 OK

The operator closes the ticket. The sending MTA deleted its queue copy after receiving the reply, so the exchange succeeded. Hours later, the intended recipient has nothing. Both observations can be true without SMTP contradicting itself.

The missing field is not another status code. It is the boundary at which the code was returned.

SMTP uses 250 for several positive completions. It can follow EHLO, confirming that client and server have entered the initial protocol state and allowing the server to advertise extensions. It can follow MAIL FROM, accepting a reverse path and starting the envelope. It can follow an individual RCPT TO, retaining that forward path for the transaction. RSET and NOOP can also receive 250, even though one clears a transaction and the other deliberately does no work.

Only a positive completion reply after the final DATA indicator accepts the stored message. RFC 5321 says that at this point the receiver takes full responsibility. The three digits are therefore not a portable verdict. They become evidence only when joined to the command, connection, envelope and point in the state machine.

This is the part of the protocol associated with John Klensin. The official IETF profile identifies Dr. John C. Klensin and listed 60 RFCs at the time of this research. RFC 5321 names him as its author. That attribution establishes a contribution to a collective standard. It does not put him in charge of a deployed mail queue or turn his name into a certificate for one implementation.

A period changes who must remember

The DATA exchange has two decisions. First the receiver sends an intermediate 354, permitting the client to send the content. That is not acceptance of the complete message. The client transmits the body and an end-of-data indicator. The receiver then processes the stored reverse path, accepted forward paths and mail data.

At that final boundary, the base SMTP model does not allow a half-accepted transaction. The server sends a positive completion if it accepts the message for delivery, or a failure reply if it does not. When it chooses the positive path, responsibility moves.

Before the reply, the sender still needs a retryable copy. After a clear positive reply, the receiver must be able to deliver, relay or generate the required later failure notice. The sending server may remove its copy because another operator has promised custody. That promise is operationally consequential even though the recipient has not yet received anything.

The distinction explains why durable storage matters before the reply leaves. An implementation that returns success and only then attempts to persist the message creates an interval in which both systems may believe the other owns the only copy. RFC 5321 says the receiver must not lose an accepted message for frivolous reasons such as a later crash or a predictable resource shortage. Running code must turn that obligation into a queue write, replication or another local durability mechanism; the RFC cannot observe whether it did.

Heng Lu's running-code lens keeps the layers honest. A standard defines the grammar of responsibility. Logs and durable state show whether one implementation executed it. A vendor badge, the RFC author's name or a syntactically correct reply cannot substitute for the receipt created by the machine that took custody.

Responsibility contains two permitted destinations

RFC 5321 does not say that the receiver has necessarily placed the message in the final mailbox. It says that the server has accepted responsibility for delivering or relaying it.

Those verbs create different next steps. A delivery server may hand the message to a local delivery agent, a mailbox store, a list processor, a policy engine or another non-SMTP environment. A relay becomes a client in a new SMTP transaction and seeks a new acceptance reply from the next hop. Each transition has its own authority and clock.

A Received trace field helps reconstruct the path. It records the identity claimed for the sending host, the receiving host and the time of the handoff. Relayed mail accumulates these lines. But the trace is not a signed end-to-end delivery certificate. It can show that a system says it accepted a hop without proving that the next queue was durable, that an alias expanded correctly or that a mailbox provider released the message to the user.

Even the phrase “final delivery” has a bounded SMTP meaning. RFC 5321 defines it as the message leaving the SMTP environment. Normally that leads to a destination user or associated mail drop, but the message may still be processed and transmitted by another mail system. Final for one protocol is not necessarily final for the human.

An operational status model should therefore resist a single Boolean called delivered. Useful states include accepted-by-this-hop, persisted-in-this-queue, accepted-by-next-hop, entered-local-delivery, placed-in-mailbox, quarantined, discarded-by-policy and user-access-unknown. Not every service can expose every state. Unknown is still more accurate than borrowing certainty from the previous hop.

Silence after acceptance is not success evidence

If an accepted message later cannot be delivered, RFC 5321 normally requires the responsible server to formulate a notification. The notification goes to the envelope reverse path and uses a null reverse path of its own so that an undeliverable failure report does not generate an endless chain of failures.

This mechanism has limits. If the original reverse path is null, there is no address to which an SMTP failure notification may be returned. Some addresses cannot be validated during the transaction because the receiver is a relay, a list is involved or name resolution is temporarily uncertain. The standard also recognises present-day abuse conditions in which dropping unwanted mail without notifying the purported sender can be permitted.

The absence of a bounce is consequently not proof of delivery. It may mean successful delivery, a report still queued, an invalid or null return path, a gateway that cannot propagate the status, a local policy discard or missing observability. A monitoring system must record which negative channel was available before it interprets silence.

Delivery Status Notifications add a separate layer. RFCs 3461, 3463 and 3464 define how a sender can request notification preferences and how a report can carry per-recipient actions and status. A report may say failed, delayed, delivered, relayed or expanded. These are not synonyms. relayed explicitly stops short of claiming final mailbox arrival; delivered names a mail-system action, not human reading. A request also does not guarantee that a report will be produced or returned.

The existing BTW history of DSN owns that report grammar. Here the important join is chronological: final-DATA 250 establishes a responsibility holder; a later DSN, local-delivery receipt or downstream acceptance provides a different fact. Combining them into one green light loses both meanings.

The lost reply creates a duplicate-shaped uncertainty

Consider a server that safely stores the message and transmits 250 OK, but the TCP connection fails before the client observes the reply. The receiver owns a valid copy. The sender cannot prove that acceptance occurred and retains a copy for retry. A second delivery may result.

RFC 5321 gives the final DATA response a long timeout because the server may need to perform substantial processing. It also tells receivers to minimise the delay after the terminator, precisely because an ambiguous timeout is expensive. Yet no timeout value can eliminate the two-generals problem at the handoff: either the message or the acknowledgement can be the last thing successfully observed.

“No final reply observed” must therefore remain different from “remote server rejected the message.” The former is an ambiguous state carrying duplicate risk. A responsible queue records the connection loss, original message handle, retry decision and any downstream identifiers that might support deduplication. It should not announce either certain loss or certain absence of delivery.

The same reasoning applies to dashboards that sample only successful sessions. A ratio of positive replies says how many handoffs were acknowledged. It does not count messages that reached inboxes, and it may hide retries that created two copies. The denominator, retry policy and observation boundary belong beside the percentage.

SMTP and LMTP expose different recipient shapes

SMTP accepts recipients one by one during RCPT. One address may receive 250 while another receives 550. The later final DATA response, however, covers the accepted transaction as a whole; the base model does not return a different post-DATA outcome for every recipient.

LMTP was designed for a local handoff where the delivery agent can report per-recipient results immediately. RFC 2033 requires one reply after the final dot for every previously successful RCPT command, in the same order. A positive completion transfers responsibility for the corresponding recipient.

This is more than a protocol trivia question. A log parser that treats an LMTP reply sequence as one SMTP result can associate failure with the wrong address. Conversely, an SMTP transaction containing several accepted recipients cannot honestly be expanded into several final per-recipient successes merely because there was one 250 after DATA.

The minimum receipt must name the protocol, preserve RCPT order and retain reply cardinality. If the local delivery agent later produces one result per address, join those results explicitly. Never infer recipient-specific finality from a transaction-level reply.

Build the custody ledger, not a delivery badge

A practical receipt starts with connection and transaction identity. It records client and server as observed, while keeping TLS authentication separate from message acceptance. It preserves MAIL FROM, every RCPT and reply, the 354 that opened DATA, the final completion or failure, exact timestamps and any server queue identifier.

After acceptance, the record changes owner but does not stop. The receiver records durable queue state, each attempt, next-hop identity, next-hop reply and any ambiguous disconnect. Local delivery adds the agent or LMTP result. A DSN adds its per-recipient Action and Status plus evidence that the report itself was handed off. Spam placement, proprietary gateway processing and human reading remain unknown unless an independent system supplies them.

This is a minimum specification, not a universal mail architecture. Operators retain local choices about queue engines, retry intervals, privacy, retention and policy. The common contract is narrower: do not erase the command that gave a reply its meaning; do not call custody “delivery”; do not let one hop donate certainty to the next.

Klensin's role in this story is exact and limited. RFC 5321 made responsibility explicit at the protocol boundary. Implementers decide when to persist. Operators decide how to retry and report. Mailbox providers decide local placement. Users decide whether the message was useful or even seen. Heng Lu's agency principle requires every claim to stay with the actor who can actually make it true.

The clean incident conclusion is longer than 250 OK, but much safer: this server accepted this envelope and message at this command boundary; responsibility moved; later evidence shows the following relay or local-delivery states; these recipient and user outcomes remain unknown.

Sources