Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
Extracted elements (29)
The DSN service was designed to be (a) reliable—DSN requests are honored or an error is returned, (b) unambiguous—success and failure are mutually exclusive, (c) stable—failed DSN delivery never triggers additional DSNs, (d) information-preserving through forwarding and gatewaying, and (e) interoperable with non-SMTP environments.
The ORCPT parameter exists because the RCPT TO address may differ from the original recipient address (e.g., after forwarding A@B.C to A@D.E), and the original sender needs to identify which recipient caused the notification. This also supports messages gatewayed from non-Internet-style address environments.
For compatibility with SMTP clients that do not use the NOTIFY facility, the absence of a NOTIFY parameter in a RCPT command may be interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. This preserves backward-compatible behavior with legacy SMTP clients.
The 'delivery' point for IMAP/POP mailboxes is when the message is made available to the IMAP/POP service, not when it is retrieved by the user agent. For mailing list exploders, 'delivery' is when the message is made available to the exploder, even if the exploder rejects the message.
When gatewaying to a foreign environment that cannot return positive delivery notifications, the MTA SHOULD issue a 'relayed' DSN for SUCCESS-requesting recipients. The return-of-content conditions from RET are nonbinding in foreign environments but SHOULD be honored using available mechanisms.
A conforming SMTP server MUST NOT refuse a MAIL command based on the presence or absence of valid ENVID or RET parameters, and MUST NOT refuse a RCPT command based on the presence or absence of NOTIFY or ORCPT parameters. Invalid parameter values or duplicate parameters MUST result in a 501 reply.
A DSN MUST NOT be returned to the sender for any message whose SMTP MAIL command used a NULL return address ('<>'), even if the sender's address is available elsewhere. The MTA SHOULD notify the local postmaster of delivery failures via a mechanism that will not itself generate DSNs.
If any DSN-related requests are transmitted within the message itself (e.g., in message headers) rather than via SMTP extensions, those requests MUST be removed from the message before it is transmitted via SMTP.
If NOTIFY=NEVER was specified for a recipient, a DSN MUST NOT be issued regardless of delivery outcome. When relaying to a non-conforming server with NOTIFY=NEVER, the client MAY use a separate SMTP transaction with an empty reverse-path to prevent DSN generation by the downstream MTA.
Implementation limits: a conforming MTA MUST accept ENVID of at least 100 chars, NOTIFY of at least 28 chars, ORCPT of at least 500 chars, and RET of at least 8 chars. It MUST accept SMTP command lines of at least 1036 characters.
The DSN sender address in the SMTP MAIL command MUST be a null reverse-path ('<>'). When transmitting a DSN via SMTP, the RET parameter MUST NOT be used. If NOTIFY is used, its value MUST be NEVER.
The message/delivery-status body part MUST include: Original-Envelope-ID (if ENVID was present), Reporting-MTA (with mta-name-type 'dns' if FQDN is known), Original-Recipient (if ORCPT was provided), Final-Recipient, Action, Status (using codes from RFC 3463), and for SMTP relay attempts, Remote-MTA and Diagnostic-Code with diagnostic-type 'smtp'.
The RET and ENVID parameters MUST NOT appear more than once each in any single MAIL command. The NOTIFY and ORCPT parameters MUST NOT appear more than once in any RCPT command. The ESMTP server SHOULD respond with '501 syntax error in parameters or arguments' if duplicates are present.
Upon local delivery, if NOTIFY=SUCCESS was specified the MTA MUST issue a 'delivered' DSN. If NOTIFY was specified without SUCCESS, the MTA MUST NOT issue a DSN. If NOTIFY was not supplied, the MTA MUST NOT issue a DSN.
When a conforming MTA fails to deliver a message, it MUST issue a 'failed' DSN if NOTIFY=FAILURE was specified. If NOTIFY was specified without FAILURE, a DSN MUST NOT be issued. If no NOTIFY was supplied, a 'failed' DSN MUST be issued.
When a message is redistributed to a mailing list, the ENVID, NOTIFY, RET, and ORCPT parameters of the redistributed message MUST NOT be derived from those of the original message. The envelope return address is rewritten to point to the list maintainer.
When initially submitting a message via SMTP, if the ORCPT parameter is used it MUST contain the same address as the RCPT TO address (encoded as xtext). When a mailing list redistributes a message, the ORCPT parameter MUST match the new RCPT TO address for each recipient.
When relaying to a conforming SMTP server, the ENVID, RET, NOTIFY, and ORCPT parameters MUST be propagated unchanged with their original esmtp-values. If a parameter was absent on receipt, it MUST NOT be added when relaying. An ORCPT parameter MUST NOT have its alphabetic characters case-changed.
When relaying to a non-conforming SMTP server, ENVID, NOTIFY, RET, and ORCPT parameters MUST NOT be issued. The relaying MTA must itself generate 'relayed' or 'failed' DSNs as appropriate based on the NOTIFY value and the SMTP reply code received.
A DSN is transmitted as a MIME multipart/report message with report-type='delivery-status'. The first part is human-readable text, the second is message/delivery-status (RFC 3464), and the third contains the original message or its headers.
The DSN SMTP service extension is advertised via the EHLO keyword 'DSN'. It adds two optional parameters to RCPT (NOTIFY, ORCPT) and two to MAIL (RET, ENVID), enabling senders to specify conditions for delivery status notification generation.
The ENVID parameter on MAIL carries an envelope identifier (up to 100 characters, encoded as xtext) that is propagated through the delivery chain and returned in any DSNs, allowing the sender to correlate notifications with the original transaction.
The NOTIFY parameter on RCPT specifies when DSNs should be generated. Values are NEVER (no DSN under any conditions), SUCCESS (on successful delivery), FAILURE (on delivery failure), and DELAY (if delivery is delayed for an unusual time). Multiple keywords may be combined with commas; NEVER must appear alone.
The ORCPT parameter on RCPT conveys the original recipient address as 'addr-type;xtext', preserving the sender-specified address through relaying and gatewaying. The entire ORCPT parameter MAY be up to 500 characters in length.
The RET parameter on MAIL specifies whether failed DSNs should return FULL (entire message) or HDRS (headers only). If omitted, the MTA MAY return either. For DSNs with no delivery failures, only headers should be returned regardless.
The 'rfc822' address-type is used for Internet email addresses in Original-Recipient and Final-Recipient DSN fields. The 'smtp' diagnostic-type carries SMTP reply codes as Diagnostic-Code values. The 'dns' MTA-name-type carries fully-qualified domain names in Reporting-MTA fields.
The DSN extension does not create new security exposures but adds implementation complexity and thus increases risk of implementation errors. Previous ad-hoc notification mechanisms sometimes produced notification storms due to unanticipated interactions with mailing list expansion; this specification carefully designs success notification to prevent such storms.
When a message arrives with both non-functional recipient addresses and a null return address, a failed DSN delivery attempt would see a null return path. To avoid silent message loss, the MTA SHOULD inform the local postmaster rather than silently discarding, since a non-functional return address often indicates a configuration problem.
ENVID and ORCPT parameter values are encoded as 'xtext': printable ASCII characters '!' (33) through '~' (126) except '+' and '=' may appear as-is; all other octets must be encoded as '+XX' where XX is two uppercase hexadecimal digits. This allows transmission of values outside the normal esmtp-value character range.