Summary

  • RFC 2852 made a delivery limit part of the SMTP envelope. A sender supplied remaining seconds and chose whether expiry should stop further attempts or merely trigger a delay report while attempts continued.
  • A capable relay had to subtract elapsed time and pass the smaller budget. The extension did not grant priority, guarantee delivery, extend normal retention, or ensure that the resulting status report returned before the same deadline.

RFC 2852 began with an unusually human failure of timing. A sender might know that a message would become a page and should not disturb its recipient after business hours. The mail transfer agents carrying it would not know that. Their normal retry schedules could be perfectly correct for email and still deliver the message after its purpose had vanished.

That example exposes a gap in store-and-forward design. SMTP could say that a mailbox was unavailable, that a route should be tried later, or that a message had become permanently undeliverable. It could not naturally carry the sender's external fact that delivery after a particular interval was worse than non-delivery. Queue retention belonged to each site. The meaning of the hour belonged to the sender. Neither side alone could make the constraint survive a chain of relays.

The Deliver By SMTP Service Extension, published in June 2000, did not solve this by creating an urgent lane. It did something more disciplined. It turned time into an acceptance condition, gave expiry two distinct consequences, and required every supporting relay to inherit the remaining obligation rather than restart it.

A deadline was not a priority purchase

A server announces support with DELIVERBY in its EHLO response. It may append a fixed minimum: the shortest Return-mode interval it is prepared to accept. The client then adds a BY parameter to MAIL FROM. No new SMTP verb exists, and no command tells the receiver how to schedule the queue.

This restraint matters. A server can accept a deadline while assigning the message no special priority at all. It can preserve its own fairness rules, resource controls and retry machinery. RFC 2852 says users should not generally expect expedited processing, and even a status notification produced when time expires need not receive faster delivery back to the sender.

The sender therefore acquires no operational sovereignty over a remote MTA. It can propose a bounded obligation. The receiving system can advertise the limits it will accept, reject a request it cannot honor, or accept custody under the specified expiry behavior. Urgency remains an assertion by the sender; queue priority remains a decision by the operator.

The number measured what remained, not what the clocks said

The BY value carries a signed decimal number of seconds, a mode, and optionally T for trace. The range runs from minus to plus 999,999,999 seconds. The two modes are R for Return and N for Notify.

The seconds form a delta, not an absolute date. This avoided making two independently administered mail servers agree about wall-clock time before they could honor the same intent. On receipt, the server adds the interval to its local time and records a local deliver-by-time. When it later relays the message, it computes how many seconds remain as close as practical to the next MAIL FROM command.

The arithmetic is simple but not perfect. Transmission is not instantaneous. RFC 2852 acknowledges that command latency makes the effective interval slightly longer, and the error accumulates across hops. DELIVERBY supplied transferable discipline, not a globally synchronized clock.

Nor was the value a schedule for future release. It said “deliver within this interval,” not “do not deliver before this moment.” It also could not lengthen an MTA's ordinary retention period. A site whose policy abandons an undeliverable message sooner may still return it before the requested deadline.

Expiry forked the queue into two different duties

Return and Notify differ precisely when time runs out.

With R, zero or negative time is invalid. If the message has not been delivered or relayed when the deadline arrives, further attempts must stop. The MTA issues a failed Delivery Status Notification with enhanced status 5.4.7, “delivery time expired,” for recipients eligible for failure reporting. The deadline withdraws permission to keep trying.

With N, the same crossing is not a stop instruction. The MTA should continue under its normal delivery policy and issue a delayed DSN with status 4.4.7 for recipients eligible for delay reporting. Zero and negative values are legal because a late message may still need to carry evidence that the requested time has already passed.

The distinction prevents an attractive but dangerous compression. “Urgent” does not determine whether late delivery is useless. Some messages should disappear when their moment ends; others remain valuable but require an alert that the service objective was missed. One mode changes custody. The other changes evidence.

Permanent failure can still happen before either deadline. Temporary conditions can still be retried. A local retention limit can still end the queue earlier. DELIVERBY does not replace SMTP's failure model; it adds one sender-declared boundary to it.

A relay inherited the remainder, not the original allowance

The most consequential rule appears at the handoff. If the next server supports DELIVERBY, the relaying MTA must send a new BY value containing the seconds still remaining. It preserves the mode. Twenty-two seconds spent in the first queue do not reappear when a second operator accepts the message.

Return mode makes this inheritance strict. A message marked R must not be relayed to a server that lacks DELIVERBY. It also must not be handed to a supporting server whose advertised minimum exceeds the remaining interval. The first relay may consider another legitimate route, but if no acceptable path remains, it must treat the message as undeliverable rather than silently discard the deadline.

Notify mode tolerates a loss of the same semantics because it does not withdraw the right to continue. It may cross to an incapable next hop. The relaying system must then expose that observation boundary with a relayed DSN for eligible recipients. If the next server supports DSN, delay notification handling is carried forward where permitted. The message can continue; the original timing promise cannot be pretended to remain intact.

This is thin coordination in practice. The standard does not run either queue. It specifies the minimum state that must cross the boundary: remaining time, expiry mode and evidence about any loss of support. Each operator keeps local decision power, but no operator may reset an accepted obligation while claiming continuity.

Acceptance could remain provisional

A server may answer MAIL FROM positively and discover only later that the request is impossible. Recipient information arrives with RCPT TO; resource or policy constraints may emerge during DATA or at end-of-data. RFC 2852 therefore permits later rejection in the same transaction.

This is not contradictory acceptance. It reflects staged knowledge. The sender declares the envelope-level condition before the server knows every recipient and before the server holds the entire message. A positive response proves only that the request was syntactically acceptable at that stage. It is not yet a certificate that every recipient can be served within the interval.

The advertised fixed minimum makes the admission boundary more explicit. A server can say that it supports Return mode but will not accept a deadline shorter than its credible operating floor. A downstream minimum larger than the remaining budget is not an inconvenience to be hidden; it is proof that this path cannot inherit the obligation.

The report had its own route and its own delay

DELIVERBY relies on DSN vocabulary for failed, delayed and relayed outcomes. It adds a Deliver-By-Date field to status reports and recommends recording arrival time. The optional trace flag can request a relayed DSN at each handoff, even without an explicit success-notification request. Those reports are nonterminal; another outcome may arrive later.

The previous history of DSN therefore remains relevant but does not absorb this one. DSN structures evidence about an action. DELIVERBY decides which action expiry creates. An R deadline changes whether the queue may continue. An N deadline leaves attempts in place and changes what must be reported.

Nor does a report close the timing loop. RFC 2852 warns that a failed DSN generated after BY=60;R is not guaranteed to reach the sender within sixty seconds. The forward deadline governs the message's delivery attempts. The return report travels as separate mail under separate queues. A protocol can make one obligation bounded without manufacturing control over every consequence.

Time improved accountability and widened observation

The trace option reveals an operational cost. Explicit relay reports can map handoffs. Even without T, a sender can submit a series of messages with different short intervals and compare outcomes, using time as a crude probe of transport structure or latency. The standard acknowledges this exposure.

The evidence must still be read narrowly. A negative Notify value says the local computed deadline is in the past; it does not identify which hop caused the delay. A failed Return outcome says the deadline obligation could no longer be honored; it does not prove congestion, negligence or a particular queue policy. A relayed report says a handoff occurred; it is not final delivery.

The current IANA SMTP registry still lists DELIVERBY and references RFC 2852 with requirement level MAY. Registration records a standardized capability, not its deployment share. No conclusion about present providers follows from the registry.

DELIVERBY's durable idea is architectural. The sender could name the point after which continued delivery became the wrong action. The receiving operator could refuse an unrealistic interval and retain control of scheduling. Every capable relay had to pass less time than it received. When semantics could not cross, the system had to expose or terminate the handoff rather than reset the clock in silence.

The deadline travelled because the protocol made it inheritable. It remained honest because the protocol refused to call that inheritance priority, guaranteed arrival, or guaranteed knowledge of failure.

Sources