An Extensible Message Format for Delivery Status Notifications
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Lo
This document is current and has been amended. 3 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 21 must, 12 should, 7 may.
2 Format of a Delivery Status Notification
- MUSTThe DSN MUST be addressed (in both the message header and the transport envelope) to the return address from the transport envelope which accompanied the original message for which the DSN was generated.
- SHOULDThe From field of the message header of the DSN SHOULD contain the address of a human who is responsible for maintaining the mail system at the Reporting MTA site (e.g., Postmaster), so that a reply to the DSN will reach that person.
- MAYException: if a DSN is translated from a foreign delivery report, and the gateway performing the translation cannot determine the appropriate address, the From field of the DSN MAY be the address of a human who is responsible for maintaining the gateway.
- SHOULDThe envelope sender address of the DSN SHOULD be chosen to ensure that no delivery status reports will be issued in response to the DSN itself, and MUST be chosen so that DSNs will not generate mail loops.
- MUSTWhenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e., "MAIL FROM:<>".
- MAYHowever, an MTA MAY report on the delivery status for several recipients of the same message in a single DSN.
2.1 The message/delivery-status content-type
- MUSTMIME type name: message MIME subtype name: delivery-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
2.2.1 The Original-Envelope-Id field
- SHOULDIf such an envelope identifier was present in the envelope that accompanied the message when it arrived at the Reporting MTA, it SHOULD be supplied in the Original-Envelope-Id field of any DSNs issued as a result of an attempt to deliver the message.
- MUST NOTExcept when a DSN is issued by the sender's MTA, an MTA MUST NOT supply this field unless there is an envelope-identifier field in the envelope that accompanied this message on its arrival at the Reporting MTA.
- MUSTThe DSN MUST preserve the original case and spelling of the envelope-id.
2.2.2 The Reporting-MTA DSN field
- SHOULDIf an MTA functions as a gateway between dissimilar mail environments and thus is known by multiple names depending on the environment, the mta-name sub-field SHOULD contain the name used by the environment from which the message was accepted by the Reporting-MTA.
2.2.3 The DSN-Gateway field
- MUSTThis field MUST appear in any DSN that was translated by a gateway from a foreign system into DSN format, and MUST NOT appear otherwise.
2.2.4 The Received-From-MTA DSN field
- SHOULDIf the message was received from an Internet host via SMTP, the contents of the mta-name sub-field SHOULD be the Internet domain name supplied in the HELO or EHLO command, and the network address used by the SMTP client SHOULD be included as a comment enclosed in parentheses.
- SHOULDSince case is significant in some mail systems, the exact spelling, including case, of the MTA name SHOULD be preserved.
2.2.5 The Arrival-Date DSN field
- MUSTNumeric timezones ([+/-]HHMM format) MUST be used.
2.3.2 Final-Recipient field
- MUSTThis field MUST be present in each set of per-recipient data.
- MUSTThe generic-address sub-field of the Final-Recipient field MUST contain the mailbox address of the recipient (from the transport envelope), as it was when the Reporting MTA accepted the message for delivery.
- MUSTInstead, it MUST report exactly the address received in the envelope, unless that address contains characters such as CR or LF which are not allowed in a DSN field.
- MUSTSince mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved.
2.3.3 Action field
- MUSTThis field MUST be present for each recipient named in the DSN.
- SHOULD NOTThis action-value SHOULD NOT be used unless the sender has requested notification of successful delivery for this recipient.
- SHOULD NOTAn action-value of "expanded" SHOULD NOT be used with a DSN issued on delivery of a message to a "mailing list".
2.3.4 Status field
- MUSTThis field MUST be present for each delivery attempt which is described by a DSN.
- MAY; White-space characters and comments are NOT allowed within ; a status-code, though a comment enclosed in parentheses ; MAY follow the last numeric sub-field of the status-code.
- MUST; Each numeric sub-field within the status-code MUST be ; expressed without leading zero digits.
2.3.5 Remote-MTA field
- MUST NOTIt MUST NOT be included if no remote MTA was involved in the attempted delivery of the message to that recipient.
2.3.6 Diagnostic-Code field
- MAYIn addition to the Diagnostic-Code itself, additional textual description of the diagnostic, MAY appear in a comment enclosed in parentheses.
- SHOULDHowever, this field SHOULD be included if transport-specific diagnostic information is available.
2.3.7 Last-Attempt-Date field
- MUST NOTIt MUST NOT be included if the actual date and time of the last delivery attempt are not available (which might be the case if the DSN were being issued by a gateway).
2.3.9 Will-Retry-Until field
- MUST NOTThe Will-Retry-Until field is optional for "delay" DSNs, and MUST NOT appear in other DSNs.
2.4 Extension fields
- MUSTDSN field names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC.
3 Conformance and Usage Requirements
- MUST NOTMTAs and gateways MUST NOT generate the Original-Recipient field of a DSN unless the mail transfer protocol provides the address originally specified by the sender at the time of submission.
- SHOULDEach sender-specified recipient address SHOULD result in at most one "delivered" or "failed" DSN for that recipient.
- SHOULDIf a positive DSN is requested (e.g., one using NOTIFY=SUCCESS in SMTP) for a recipient that is forwarded to multiple recipients of an "alias" (as defined in [DRPT], section 7.2.7), the forwarding MTA SHOULD normally issue a "expanded" DSN for the originally-specified recipient and not propagate the request for a DSN to the forwarding addresses.
- MAYAlternatively, the forwarding MTA MAY relay the request for a DSN to exactly one of the forwarding addresses and not propagate the request to the others.
- SHOULDUpon delivery of a message to a recipient address corresponding to a mailing list exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly as if the recipient address were that of an ordinary mailbox.
6 Acknowledgments
- MAY; White-space characters and comments are NOT allowed within a ; a status-code, though a comment enclosed in parentheses ; MAY follow the last numeric sub-field of the status-code.
- MUSTFor DSNs produced from foreign delivery or nondelivery notifications, the name of the gateway MUST appear in the DSN-Gateway field of the DSN.
- MAYIANA MAY reject DSN type registrations because of incomplete registration forms, imprecise specifications, or inappropriate type names.
- MUSTA registration for a DSN address-type MUST include the following information: