An Extensible Message Format for Delivery Status Notifications
Extracted elements (26)
Both the Action field and the Status field are retained because they convey complementary information: a '4.x.x' (temporary failure) status code can appear with either 'delayed' or 'failed' action values depending on whether the MTA is still retrying. The fields are not redundant.
DSN fields that carry mailbox addresses, MTA names, and status codes use a 'type; value' structure rather than assuming any particular format, enabling the protocol to operate in multi-protocol (X.400, LAN-based) environments without losing 'foreign' information.
DSNs carry both a transport-independent status code (Status field) and a transport-specific diagnostic code (Diagnostic-Code field) because translating a foreign error code to a status code may lose precision. The Diagnostic-Code is provided for trouble tickets and tunneling scenarios.
Mailing list exploders should use the Original-Recipient field (if available) to match subscriber addresses in DSNs, because Final-Recipient may have been rewritten by forwarding or aliasing. A subscriber should not be removed from a list based on any single failure DSN; persistent failure over time is the recommended criterion.
When gatewaying from a foreign system to DSN format, the gateway must attempt to supply Reporting-MTA, Final-Recipient, Action, and Status fields by translating foreign notification elements. The gateway name MUST appear in the DSN-Gateway field, and the original foreign diagnostic code should be preserved in Diagnostic-Code.
Extension DSN field names not beginning with 'X-' MUST be registered with IANA and published in an RFC. Names beginning with 'X-' are reserved for experimental use and will never be accepted as standard fields.
MTAs MUST NOT generate the Original-Recipient field of a DSN unless the mail transfer protocol provides the address originally specified by the sender. Ordinary SMTP does not provide this guarantee; the SMTP DSN extension (RFC 3461) does.
The DSN-Gateway field MUST appear in any DSN translated by a gateway from a foreign system into DSN format, and MUST NOT appear otherwise.
The DSN MUST be addressed (in both message header and transport envelope) to the return address from the transport envelope of the original message. For SMTP-delivered DSNs, the MAIL FROM command MUST use a NULL return address ('MAIL FROM:<>').
The envelope-id in the Original-Envelope-Id field is CASE-SENSITIVE; the DSN MUST preserve the original case and spelling. An MTA MUST NOT supply this field unless an envelope-identifier was present in the incoming envelope.
The envelope sender address of the DSN MUST be chosen to prevent mail loops; whenever SMTP is used to send a DSN, MAIL FROM MUST use a NULL return address.
The Final-Recipient field MUST report exactly the address received in the envelope, preserving case. The Reporting MTA is not expected to validate that the address conforms to address-type syntax, except that CR and LF characters are prohibited in DSN fields.
The message/delivery-status content MUST use '7bit' encoding to maintain readability when viewed by non-MIME mail readers.
The Reporting-MTA field is required in every DSN. The Final-Recipient, Action, and Status fields MUST be present for each recipient described in the DSN. These four fields constitute the minimal conforming implementation.
The Will-Retry-Until field is optional for 'delayed' DSNs and MUST NOT appear in any other DSN type. Date-time fields in DSNs (Arrival-Date, Last-Attempt-Date, Will-Retry-Until) MUST use numeric timezones in [+/-]HHMM format.
DSNs may reveal confidential forwarding addresses (e.g., pager or wireless mailbox addresses). MTAs are encouraged to allow users to suppress this leakage by issuing 'relayed' DSNs, omitting Remote-* fields, or using NOTIFY=NEVER on the forwarded message. Non-compliant downstream MTAs that honor Return-Receipt-To headers cannot be controlled.
A DSN is a MIME message with top-level content-type multipart/report, report-type parameter set to 'delivery-status'. The second component MUST be message/delivery-status; an optional third component carries the original message or simulated RFC 822 headers.
Several DSN fields use a '*-type' sub-field mechanism: address-type specifies mailbox address format (e.g., 'rfc822'), diagnostic-type specifies status code format (e.g., 'smtp'), and mta-name-type specifies MTA name format (e.g., 'dns'). Type values are case-insensitive atoms registered with IANA.
The Action field indicates the disposition of the message for a recipient, with five defined values: 'failed' (delivery abandoned), 'delayed' (retry ongoing), 'delivered' (terminal success), 'relayed' (forwarded to DSN-unaware environment), 'expanded' (forwarded to multiple addresses, non-terminal).
IANA maintains registries of address-types (e.g., 'rfc822'), diagnostic-types (e.g., 'smtp'), and MTA-name-types (e.g., 'dns'). Registrations require: proposed name, syntax specification, encoding rules for non-ASCII values, and optionally a mapping to Internet addresses or DSN status codes. Names beginning with 'X-' are excluded.
DSNs may be forged as easily as ordinary Internet email. Threats include falsified delivery or non-delivery notifications, falsified Final-Recipient or Remote-MTA addresses, falsified relay notifications for dead-ended messages, and unsolicited DSNs. Automated systems should take precautions against denial-of-service via forged DSNs.
DSNs provide no non-repudiation guarantee. Even a 'failed' DSN cannot prove a message was not delivered: an SMTP race condition (connection dropped after DATA completes but before response is received) can cause duplicate delivery, resulting in both a successful delivery and a failure DSN for the same message.
Per-message fields include optional Original-Envelope-Id, required Reporting-MTA, optional DSN-Gateway, optional Received-From-MTA, optional Arrival-Date, and zero or more extension fields. The Reporting-MTA field is the only mandatory per-message field.
Per-recipient fields include optional Original-Recipient, required Final-Recipient, required Action, required Status, optional Remote-MTA, optional Diagnostic-Code, optional Last-Attempt-Date, optional Final-Log-ID, optional Will-Retry-Until, and zero or more extension fields.
The message/delivery-status body consists of per-message fields followed by one or more per-recipient field groups, each group preceded by a blank line: delivery-status-content = per-message-fields 1*( CRLF per-recipient-fields ). Fields follow RFC 822 header syntax and are case-insensitive.
The Status field carries a transport-independent three-part status code with format DIGIT '.' 1*3DIGIT '.' 1*3DIGIT. The first sub-field is 2 (success), 4 (temporary failure), or 5 (permanent failure). No leading zeros are allowed; whitespace is prohibited within the code.