An Extensible Message Format for Delivery Status Notifications
obsoleted by
- rfc-3464 — An Extensible Message Format for Delivery Status Notifications
updated by
- rfc-2852 — Deliver By SMTP Service Extension
Extracted elements (30)
Both a transport-independent status code (Status field) and a transport-specific diagnostic code (Diagnostic-Code field) are provided because translation to a generic status code may lose precision. The Diagnostic-Code retains the original transport error for trouble tickets and tunneling of foreign NDNs.
Several DSN fields use a "-type" subfield (address-type, diagnostic-type, mta-name-type) followed by a semicolon and value. This design allows DSNs to carry addresses, diagnostic codes, and MTA names from arbitrary foreign mail systems without assuming any particular format, enabling multi-protocol interoperability.
The Action field is not redundant with the Status field: a status code of "4" (temporary failure) can accompany either a "delayed" or "failed" action. An MTA may issue a "delayed" DSN and later a "failed" DSN both carrying the same 4.x.x status code, distinguishable only via the Action field.
The DSN format carries both the original (sender-specified) and final (as seen by the Reporting MTA) recipient addresses because different users of the DSN need different forms: the sender needs the original to match their records, while a postmaster needs the final address to reproduce a failure.
Many existing MTAs send nondelivery notifications to the return address in the message header rather than the envelope return address, in violation of SMTP. If a message is forwarded through such an MTA, no action by the forwarding MTA can prevent the downstream MTA from disclosing a confidential forwarding address.
When gatewaying foreign delivery notifications into DSN format, the gateway MUST supply the DSN-Gateway field, MUST attempt to provide Reporting-MTA, Final-Recipient, Action, and Status fields, and SHOULD retain the original foreign diagnostic code in the Diagnostic-Code field with an appropriate diagnostic-type value.
A minimal conforming implementation need generate only the Reporting-MTA per-message field, and the Final-Recipient, Action, and Status fields per recipient. Generation of all other optional fields is strongly recommended when appropriate.
An MTA MUST NOT supply the Original-Envelope-Id field unless an envelope-identifier was present in the envelope when the message arrived at the Reporting MTA (except when the DSN is issued by the sender's own MTA). The envelope-id is case-sensitive and MUST be preserved exactly.
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 defined 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 at submission time. Ordinary SMTP does not make that guarantee; the SMTP DSN extension (RFC 1891) does.
The Action field MUST be present for each recipient and takes one of five values: "failed", "delayed", "delivered", "relayed", or "expanded". "delivered" and "failed" are terminal states; "delayed" and "expanded" are not.
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. It identifies the gateway that performed the translation.
The DSN MUST be addressed (in both message header and transport envelope) to the return address from the transport envelope of the original message. When sent via SMTP, the MAIL FROM command MUST use a NULL return address ("MAIL FROM:<>") to prevent mail loops.
The Final-Recipient field MUST be present in each per-recipient group and MUST contain the mailbox address exactly as received in the transport envelope. The case of alphabetic characters in the address MUST be preserved.
The Last-Attempt-Date field MUST NOT be included if the actual date and time of the last delivery attempt are not available. Date/time MUST use RFC 822 date-time format with numeric timezones ([+/-]HHMM format).
The message/delivery-status content MUST use "7bit" encoding to maintain readability when viewed by non-MIME mail readers.
The Remote-MTA field MUST NOT be included if no remote MTA was involved in the attempted delivery. When present, it identifies the next-hop MTA that reported delivery status to the Reporting MTA.
The Reporting-MTA field is required in every DSN. It identifies the MTA that attempted delivery, relay, or gateway of the described message — not necessarily the MTA that issued the DSN (e.g., a gateway translating a foreign NDN uses the foreign MTA's name, not its own).
The Status field MUST be present for each delivery attempt. The status-code format is DIGIT "." 1*3DIGIT "." 1*3DIGIT where the first subfield is 2 (success), 4 (persistent temporary failure), or 5 (permanent failure). Each numeric subfield MUST be expressed without leading zeros.
The Will-Retry-Until field MUST NOT appear in DSNs other than those of type "delayed". It gives the date after which the Reporting MTA expects to abandon all delivery attempts for the recipient.
A DSN is a MIME multipart/report message with report-type parameter "delivery-status". The first part is human-readable explanation, the second is message/delivery-status, and the optional third part is the original message or a portion thereof.
Per-message fields identify the overall message transaction and apply to all delivery attempts in the DSN. They include: optional Original-Envelope-Id, required Reporting-MTA, optional DSN-Gateway, optional Received-From-MTA, optional Arrival-Date, and extension fields.
Per-recipient fields convey delivery results for each recipient and include: optional Original-Recipient, required Final-Recipient, required Action, required Status, optional Remote-MTA, optional Diagnostic-Code, optional Last-Attempt-Date, optional Will-Retry-Until, and extension fields.
IANA maintains registries of address-type, diagnostic-type, and MTA-name-type values. Initial values include "rfc822" address-type, "smtp" diagnostic-type, and "dns" MTA-name-type. Names beginning with "X-" are reserved for experimental use and will not be accepted for registration.
DSNs can inadvertently disclose confidential forwarding addresses (e.g., pager addresses). MTAs should provide mechanisms to preserve forwarding address confidentiality, including issuing "relayed" DSNs, omitting Remote-* fields, using NOTIFY=NEVER, or having the forwarding MTA rewrite the envelope return address.
DSNs may be forged as easily as ordinary Internet email. Threats include falsified delivery/non-delivery notifications, falsified Final-Recipient addresses, falsified Remote-MTA identifications, falsified relay notifications, and unsolicited DSNs. Automated mail handlers should take precautions against denial-of-service from forged DSNs.
DSNs provide no non-repudiation guarantee. Even a "failed" DSN cannot be relied upon as proof that a message was not received, due to SMTP race conditions (duplicate delivery when a connection drops after DATA completion) and active forgery possibilities.
Status code is encoded as three numeric subfields separated by periods: status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT. Whitespace and comments are NOT allowed within a status-code, though a parenthesized comment MAY follow the last subfield.
The body of message/delivery-status consists of per-message fields followed by one or more groups of per-recipient fields, each group preceded by a blank line. Formally: delivery-status-content = per-message-fields 1*( CRLF per-recipient-fields ).
The xtext encoding allows arbitrary octets in DSN fields: printable ASCII chars (except "+", "\", "(") may appear as-is; other octets are encoded as "+" followed by two uppercase hex digits. The "+" character itself MUST be encoded as "+2B".