ietf-corpus

rfc-2852

Deliver By SMTP Service Extension

D. Newman
date2000-06 streamLegacy statusPROPOSED STANDARD pages13 canonicalhttps://www.rfc-editor.org/rfc/rfc2852 doi10.17487/RFC2852 errataview
This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]

updates

Extracted elements (23)

design-rationale §4

A delta time (seconds remaining) is used instead of an absolute timestamp to avoid problems from clock differences between SMTP clients and servers; the server converts the delta to a local absolute deliver-by-time upon receipt.

email

design-rationale §9

The Deliver By extension is explicitly not intended as a priority mechanism; MTAs are free to assign whatever processing priority they wish, and DSNs triggered by Deliver By requests are not required to receive expedited processing.

email

design-rationale §4

Zero and negative by-time values are permitted for by-mode 'N' to preserve historical delivery timing information for the recipient, DSNs, or NDNs, even when the deadline has already passed.

email

interoperability-note §7

MX hosts must ensure their advertised min-by-time does not substantially differ from what the destination host can handle or fail to account for relay latency; presenting an incompatible value forces relay failures.

email

interoperability-note §7

Sites using Deliver By with MX-directed mail need to ensure all their MX hosts support the Deliver By extension, since a by-mode 'R' message cannot be relayed to a non-supporting server.

email

normative-requirement §4.1.4.1 MUST NOT

A message with by-mode 'R' MUST NOT be relayed to a SMTP server that does not support the Deliver By extension, and the receiving server MUST NOT have a fixed minimum by-time greater than the remaining delivery window.

email

normative-requirement §4.1.2 MUST

If deliver-by-time has not passed and a message cannot be delivered for permanent reasons, the SMTP server or MTA MUST return a 'failed' DSN with appropriate status for each relevant recipient address.

email

normative-requirement §4 SHOULD

If the by-time is valid but the server cannot honor it for a server-specific reason, the server SHOULD respond with 455 (transient) or 555 (permanent), plus an enhanced error code if supported.

email

normative-requirement §7 SHOULD NOT

SMTP clients supporting Deliver By SHOULD NOT attempt multiple MX hosts looking for one that supports Deliver By.

email

normative-requirement §4 MUST

The BY esmtp-keyword MUST have an associated esmtp-value; the by-time alone is not sufficient.

email

normative-requirement §2 MUST

The maximum length of the MAIL FROM command line is increased by 17 characters to accommodate the BY keyword and its value.

email

normative-requirement §4 SHOULD

When by-mode is 'R' and the by-time is zero or negative, the SMTP server SHOULD return a permanent failure 501 reply code, and if enhanced error codes are supported, SHOULD also return 5.5.4.

email

normative-requirement §4.1.3 MUST

When deliver-by-time is reached or passed and by-mode is 'N', delivery attempts should continue per site policy, and the server or MTA MUST issue a 'delayed' DSN with status 4.4.7 for each applicable recipient.

email

normative-requirement §4.1.4.2 MUST

When relaying a by-mode 'N' message before deliver-by-time to a server that does not support Deliver By, the relaying client MUST issue a 'relayed' DSN for each applicable recipient.

email

normative-requirement §4.1.4.2 SHOULD

When relaying a by-mode 'N' message to a non-Deliver-By server supporting DSN, if no NOTIFY parameter was supplied 'NOTIFY=FAILURE,DELAY' SHOULD be requested; if NOTIFY was specified and is not 'NEVER', 'DELAY' SHOULD be added if not already present.

email

normative-requirement §4.1.4 MUST

When relaying a message to another SMTP server that supports Deliver By, a new BY parameter MUST be relayed with a by-time value indicating the remaining seconds until deliver-by-time.

email

normative-requirement §4.1.4 SHOULD

When relaying a message with the by-trace 'T' field, a 'relayed' DSN SHOULD be generated by the relaying SMTP client for each recipient not using NOTIFY=NEVER.

email

protocol-element §5

A new DSN per-message field 'Deliver-by-date' is defined, with value of type date-time (RFC 822 as amended by RFC 1123), indicating the deliver-by-time as computed by the MTA or SMTP server generating the DSN.

email

protocol-element §4

The by-time field is a delta time (number of seconds) ranging from -999,999,999 to +999,999,999. Upon receipt, the server converts it to an absolute deliver-by-time by adding the by-time to the current local time.

email

protocol-element §2

The DELIVERBY SMTP service extension is advertised via the EHLO keyword 'DELIVERBY', with an optional numeric parameter (min-by-time) indicating the minimum by-time the server will accept when by-mode 'R' is specified.

email

security-consideration §8

Implementation of Deliver By enables tracing of the mail transport system. The by-trace 'T' field explicitly requests trace DSNs, and even without it, a crude trace can be generated by submitting messages with incrementally increasing by-time values (e.g., BY=0;R, BY=1;R, BY=2;R).

email, security

wire-format §4

The BY esmtp-parameter has the form 'BY=<by-time>;<by-mode>[T]' where by-time is a signed decimal integer of up to 9 digits (seconds), by-mode is 'N' (Notify) or 'R' (Return), and the optional 'T' flag requests trace DSNs.

email

wire-format §5

The Deliver-by-date DSN field has syntax: 'Deliver-by-date' ':' date-time, where date-time follows RFC 822 as amended by RFC 1123. It extends the per-message-fields of RFC 1894.

email