Summary

  • RFC4865 lets a submission client request that a message not be released before a future time. If it combines that request with DELIVERBY, the client must put the delivery deadline later than release; a supporting server must reject a request it determines has release later than the deadline.
  • Neither an acceptable interval nor an authenticated sender reserves delivery capacity. Clock quality, scheduled-storage quotas, deadline mode and reporting history remain separate operational responsibilities.

Imagine a message submitted in the morning with two instructions: do not release it until noon, and stop trying to deliver it after eleven. This is a hypothetical configuration, not a reported outage. No amount of spare bandwidth makes its obligations compatible. A server that silently removes either instruction can produce an apparently successful transaction only by changing the bargain.

The useful feature of RFC4865 is therefore not just its ability to hold mail. It makes one kind of impossible promise rejectable at submission. A service may be healthy, the sender authorized and the message validly addressed, yet this particular combination must not become accepted work. For an operator, that refusal can be the correct outcome.

Published in May2007, the specification defines Future Message Release for SMTP submission. It allows a client to use the submission server's storage rather than remain online with its own local queue. A reminder or announcement can be prepared earlier and held centrally. The convenience transfers something concrete: custody of content, use of storage and responsibility for deciding when the hold has ended. It does not transfer control over every system that will later carry the message.

Two times, two duties

The submission server advertises FUTURERELEASE and two limits: a maximum interval and a furthest release date-time. A client using the extension first checks support, then supplies exactly one hold parameter on MAIL. HOLDFOR gives an interval; HOLDUNTIL gives a date-time. The client must respect the corresponding advertised maximum. Supplying neither does not imply a default holding period.

The two forms accommodate different client capabilities. A device may have a usable sense of local time but inadequate time-zone information, or a clock unsuitable for constructing the desired absolute timestamp. RFC4865 accepts the practical case for both forms. It does not say that relative syntax solves timekeeping: its security discussion explicitly warns that inaccurate or changing server clocks affect both.

Once a message is accepted with a valid future-release request, the MSA must not release it before the specified interval has elapsed or the requested time occurs. That is a lower boundary on release. It is not a promise to release at precisely that instant, still less a promise to place the message in a recipient's mailbox then. Queue scheduling and subsequent transport have not disappeared because the client supplied a time.

DELIVERBY supplies a different kind of instruction. Defined in RFC2852, it associates a delivery interval with behavior if delivery does not occur in time. The extension expressly does not require priority processing. An operator may assign priority, but the request does not purchase it by its mere presence. Nor does the delivery interval extend the MTA's ordinary retention period for undeliverable mail.

These instructions can coexist when their meanings are respected. One prevents early release; the other governs a later delivery limit and its consequences. The interval between them is a possible operating window, not evidence that the path can complete its work inside it.

The comparison cannot be simplified

RFC4865 puts duties on both ends of the submission exchange, but their wording is not identical. Section5.2.1 says the client must ensure that its deliver-by time is farther in the future than the specified or implied release time. The client therefore needs a strictly later deadline.

Section5.2.2 says an MSA supporting both extensions must reject MAIL if it determines that release is farther in the future than deliver-by. This is the server's stated conflict condition. It should not be paraphrased into a newly invented greater-than-or-equal comparison. Conversely, that wording does not make equality a conforming request for the client. A client cannot justify a zero-length window by pointing to the narrower formulation of the server's rejection rule.

This is a small distinction with a large operational use. A client acceptance test should check the client's strict ordering requirement. A server test should check the rejection condition actually specified. If an implementation's equality behavior matters to a service, observe and document it separately. Do not turn silence in one sentence into a general authorization elsewhere.

For the obvious contradictory case—release after delivery deadline—the specification directs the server to reject the MAIL command. It recommends reply501 and enhanced status5.5.4. A rejection at that boundary can return the decision to the sender while the request is still being negotiated. The service should not quietly choose whether the sender values secrecy before release or avoidance of late delivery more.

A positive reply to MAIL is also not a receipt for final delivery, or even necessarily the end of submission acceptance. RFC2852 notes that inability to honor a request may become apparent at recipient processing or later message-data completion. Operational records must identify which command received which reply; a generic “accepted” counter blurs stages that have different consequences.

Expiry has more than one meaning

DELIVERBY's Return mode and Notify mode cannot be collapsed into a single red deadline marker. Under Return mode, if the message has not been delivered or relayed before the deadline, further delivery attempts must stop. The specification requires the relevant failed notification for recipients whose notification settings call for it. Under Notify mode, attempts should continue according to local policy, with the specified delayed notification for eligible recipients.

A Notify deadline can therefore pass while the transport remains authorized to work. A Return deadline cannot be treated that way. Calling both cases “expired” without preserving mode risks either premature abandonment or delivery after the sender's stopping condition.

The downstream path matters too. A Return-mode message must not be relayed to a server lacking DELIVERBY, or one whose fixed minimum interval exceeds the time remaining. A Notify-mode message can cross a non-supporting hop, with the reporting consequences described by RFC2852. Capability continuity affects which promise can travel; it is not merely an optional label in a log.

Even Return mode does not promise that the sender will learn promptly of failure. The report itself need not receive expedited treatment. RFC2852 is explicit about this limitation. A deadline can bound further attempts without bounding the arrival of knowledge about them. A support procedure that waits a fixed period for a bounce and then assumes success would be manufacturing a guarantee the extension does not provide.

A scheduled queue has a balance sheet

Moving waiting time from a device into an MSA shifts resource use rather than abolishing it. A properly authenticated user can submit enough future work to exhaust storage. RFC4865 distinguishes that problem from unauthorized use: authorization is part of the submission framework, while scheduled-storage quotas address consumption by those already entitled to submit.

The specification says future-release storage should be subject to a per-user quota. If the MSA imposes such a quota and detects that an incoming message would exceed it, it must reject MAIL. The conditional matters. This is not a claim that every implementation necessarily has the same quota, charges it identically or performs an identical capacity reservation.

The enhanced status vocabulary also distinguishes insufficient per-user quota from insufficient system quota: X.7.16 and X.7.17. The distinction tells an operator which budget failed. Waiting for one user's queue to drain is not the same diagnosis as waiting for the shared system to recover. It does not establish a universal retry delay.

A far-future horizon is an advertised service limit, not proof of future spare capacity. Even where storage admission succeeds, many messages may become eligible for release together. A concentrated release is an operational scenario to test, not a measured incident asserted here. Its significance is straightforward: the resource constraint can move from stored bytes to processing and outbound delivery without any sender having violated an individual holding limit.

This is where Lu Heng's agency argument offers an editorial lens. His Note32 asks what happens when control is separated from economic consequences. Applied to scheduled mail, the question is who can promise a large future workload, who budgets the queue and who answers for the result. It is not evidence that a particular vendor or engineer has bad motives. Note36's insistence on describing structure rather than advocacy is equally important: the concern is the allocation of duties, not a campaign against scheduling.

Records should preserve the request without pretending to be the event

Future-release reporting is designed to retain context. If an MSA generates a DSN about a message containing a future-release request, RFC4865 requires Arrival-Date and Future-Release-Request in the machine-readable report. The latter preserves the original hold value in its defined form.

These fields help distinguish a message deliberately held from one merely delayed in transport. They do not by themselves prove the exact instant the hold ended, that a release attempt succeeded or that the recipient received the message. A useful investigation needs observations of those later events as well as the original request.

The extension also excludes two tempting recursive uses. A client must not request future release when submitting a DSN or a message disposition notification to the MSA. The report about processing is not supposed to become another deliberately scheduled notification through this mechanism.

A message's Date header should not be mistaken for the queue's clock record. RFC4865 says the header, specifically Date, remains unchanged after submission; a sending client may choose a future release date for that field, and the transport is not expected to rewrite trace information to conceal the delay. This is distinct from bounded submission-time completion or correction permitted by RFC6409, which replaces the earlier submission specification. It is not a universal assertion that an MSA can never correct a missing or malformed Date.

RFC6409 also clarifies why the role boundary matters: submission and relay can apply different policies. Submission normally uses port587; its general allowance for designated submission on25 does not turn an ordinary relay service into a FUTURERELEASE service. The scheduling extension's own submission-only scope still governs.

What the documents establish—and what they do not

Two errata are worth retaining in the evidence. Verified Editorial erratum2040 corrects RFC4865's dangling date-time grammar reference to the RFC3339 production. The submitter's accompanying 2010 statement about a working server is attributed historical testimony, not a current deployment census. RFC2852's Editorial erratum2300, held for document update, concerns missing whitespace in its grammar; it does not change deadline behavior.

This analysis has not sent SMTP commands, manipulated clocks or examined a provider's production queue. It establishes the specified obligations and derives questions for controlled testing. Actual rejection codes, equality handling, timing accuracy and capacity behavior require observations from the implementations in use.

The leadership value is not a reassuring scheduled-send icon. It is an admission policy that refuses contradictory duties, a queue whose cost has an owner and evidence that distinguishes planned release from observed release and eventual delivery. Before promising that a message will arrive on time, someone must first be allowed to let it leave.

Sources