SMTP Service Extension for Delivery Status Notifications
obsoleted by
- rfc-3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
Extracted elements (31)
DSN stability (goal 2(c)) is achieved by requiring DSNs be sent with null reverse-path combined with the rule that no DSN is issued for messages with null reverse-path. This prevents DSN storms where a failed DSN delivery attempt could recursively trigger another DSN.
The ENVID parameter's value is opaque to the mail system and meaningful only to the sender or their user agent. This design allows the sender to use any identifier scheme (e.g., including transaction IDs or timestamps) without requiring the mail infrastructure to interpret it.
The ORCPT parameter was introduced to preserve the sender-visible original recipient address separately from the RCPT TO address used for actual delivery. Without it, forwarding, aliasing, or gatewaying would lose the identity of the original intended recipient in any DSN returned to the sender.
When relaying a message with NOTIFY=NEVER to a non-conforming SMTP server, a conforming client MAY send that recipient's message in a separate SMTP transaction with an empty reverse-path ('<>'). This prevents legacy RFC 821 MTAs from issuing unsolicited DSNs for those recipients.
A conforming MTA MUST accept ESMTP parameters of at least: ENVID=100 chars, NOTIFY=28 chars, ORCPT=500 chars, RET=8 chars. It MUST also accept SMTP command lines of at least 1036 characters (512 base + 530 for ORCPT and NOTIFY parameters on RCPT).
A conforming SMTP server MUST return the same reply-code for MAIL commands with valid ENVID/RET parameters as it would without them, and MUST NOT refuse a MAIL command based on the presence or absence of these parameters. The same rule applies to NOTIFY/ORCPT on RCPT commands.
A 'delayed' DSN MAY be issued only if NOTIFY included DELAY or no NOTIFY was supplied. If NOTIFY was supplied without the DELAY keyword, a delayed DSN MUST NOT be issued. A conforming MTA is never required to issue delayed DSNs.
A DSN MUST NOT be returned to the sender for any message whose SMTP MAIL command reverse-path was NULL ('<>'). However, the MTA SHOULD inform the local postmaster of delivery failures through a mechanism that will not itself generate DSNs.
For DSNs generated from failed SMTP relay attempts, Remote-MTA (mta-name-type 'dns') and Diagnostic-Code (diagnostic-type 'smtp') fields MUST be supplied for each affected recipient.
If ORCPT was provided for a recipient, the Original-Recipient DSN field MUST be supplied from the ORCPT value; if absent it MUST NOT appear. The Action field and Status field MUST be supplied; when no specific status code applies, 4.0.0 or 5.0.0 MUST be used.
In a DSN, if ENVID was present on the MAIL command, the Original-Envelope-ID field MUST be supplied with the xtext-decoded value; if absent it MUST NOT appear. The Reporting-MTA field MUST be supplied; if the FQDN is known, MTA-name-type MUST be 'dns'. The Final-Recipient field MUST be supplied with the envelope recipient address.
On delivery failure, if NOTIFY=FAILURE was specified the MTA MUST issue a 'failed' DSN. If NOTIFY was supplied without FAILURE, a DSN MUST NOT be issued. If no NOTIFY was supplied, a 'failed' DSN MUST be issued. Forwarding to a dead-letter mailbox is still delivery failure; the DSN Action MUST be 'failed'.
RET and ENVID parameters MUST NOT appear more than once each in a single MAIL command. NOTIFY and ORCPT parameters MUST NOT appear more than once in any RCPT command. Servers SHOULD respond with '501 syntax error in parameters or arguments' if duplicates appear.
The DSN SMTP envelope MUST use a null reverse-path ('<>') in the MAIL command. When transmitting a DSN via SMTP, the RET parameter MUST NOT be used; if NOTIFY is used its value MUST be NEVER. The ENVID and ORCPT parameters MAY be used.
Upon successful local delivery, if NOTIFY includes SUCCESS the MTA MUST issue a 'delivered' DSN; if NOTIFY was supplied without SUCCESS the MTA MUST NOT issue a DSN; if NOTIFY was absent the MTA MUST NOT issue a DSN. 'Delivery' for IMAP/POP occurs when the message is made available to the access service, not when retrieved.
When gatewaying into a foreign environment, if NOTIFY=NEVER was specified a DSN MUST NOT be issued. If the foreign environment cannot confirm successful delivery and NOTIFY=SUCCESS was requested, the MTA SHOULD issue a 'relayed' DSN. RET parameter conditions are nonbinding but the MTA SHOULD attempt to honor them.
When redistributing a mailing list message, the ENVID, NOTIFY, RET, and ORCPT parameters MUST NOT be derived from those of the original message. The envelope return address MUST be rewritten to the list maintainer and MUST forward unrecognized DSNs to the human responsible.
When relaying to a conforming SMTP server, ENVID, RET, NOTIFY, and ORCPT parameters MUST be preserved exactly as received, including case of ORCPT values. Parameters absent on receipt MUST NOT be added (except ORCPT, which MAY be added if not originally present, set to the received RCPT address).
When relaying to a non-conforming SMTP server, DSN parameters MUST NOT be issued. If NOTIFY=SUCCESS was specified and the server accepts the RCPT (2xx), the client MUST issue a 'relayed' DSN. If NOTIFY=FAILURE and the server returns 5xx, the client MUST issue a 'failed' DSN. If NOTIFY=NEVER, the client MUST NOT issue a DSN.
A recipient's confidential forwarding address can be protected by treating the forward as a mailing list: the MTA issues a DSN (if requested) upon 'delivery' to the original address, then forwards with a new envelope return address. Any DSNs from the forwarded delivery will not reveal the actual forwarding destination to the original sender.
The DSN SMTP service extension is advertised via the EHLO keyword 'DSN' with no allowed parameters. An SMTP client wishing to request delivery status notifications must check for this keyword in the EHLO response before using extension parameters.
The ENVID esmtp-keyword on the MAIL command carries an opaque envelope identifier (encoded as xtext, up to 100 characters) that is propagated with the message and included in any DSNs, allowing the sender to correlate DSNs with the original transmission.
The NOTIFY esmtp-keyword on the RCPT command specifies DSN generation conditions. Its value is either 'NEVER' (alone) or a comma-separated list of 'SUCCESS', 'FAILURE', and/or 'DELAY' (case-insensitive). Absence of NOTIFY may be treated as NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
The ORCPT esmtp-keyword on the RCPT command conveys the original recipient address in the form 'addr-type;xtext', where addr-type is an IANA-registered address type. The parameter MAY be up to 500 characters in length.
The RET esmtp-keyword on the MAIL command specifies whether DSNs for delivery failure should include the full message ('FULL') or only the message headers ('HDRS'). If omitted, the MTA MAY return either; success-only DSNs should always return only headers.
The 'dns' MTA-name-type is defined for use in Reporting-MTA DSN fields, representing fully-qualified Internet domain names. The name must be registered in DNS and Postmaster@{mta-name} must be valid; domain-literals containing IP addresses are acceptable when domain names are unavailable.
The 'rfc822' address-type is defined for use in Original-Recipient and Final-Recipient DSN fields, representing Internet email addresses of the form [route] addr-spec with fully-qualified DNS domain names. MTAs MUST NOT modify envelope addresses to force syntax conformance.
The 'smtp' diagnostic-type is defined for Diagnostic-Code DSN fields, encoding SMTP reply codes in the format '*( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text'. Single-line replies should be transcribed exactly; multi-line replies require a SPACE inserted before each continuation line.
The null reverse-path requirement for DSN envelopes, combined with the prohibition on issuing DSNs for messages with null return addresses, is the primary mechanism preventing notification loops. MTAs that would silently lose messages when both the recipient address and return address are non-functional should notify the local postmaster instead.
A DSN is transmitted as a MIME multipart/report message with report-type='delivery-status'. The first component is human-readable text, the second is of content-type message/delivery-status, and the third is the original message or its headers depending on RET and whether failures are present.
xtext encoding is used for ENVID and ORCPT parameter values to allow arbitrary octets within esmtp-values. ASCII characters between '!' (33) and '~' (126), except '+' and '=', may appear as-is; all other octets MUST be encoded as '+' followed by two uppercase hexadecimal digits.