Message Disposition Notification
This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X
Replaces RFC 2298: An Extensible Message Format for Message Disposition Notifications, RFC 3798: Message Disposition Notification.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 35 must, 15 should, 7 may.
2.1 The Disposition-Notification-To Header
- MUST NOTAn MDN MUST NOT itself have a Disposition-Notification-To header field.
- MUST NOTAn MDN MUST NOT be generated in response to an MDN.
- MUST NOTA user agent MUST NOT issue more than one MDN on behalf of each particular recipient.
- SHOULDUser agents SHOULD leverage support in the underlying message access protocol to prevent multiple MDNs from being generated.
- SHOULDIn particular, when the user agent is accessing the message using RFC-IMAP [RFC3501], it SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503].
- MUST NOTMDNs MUST NOT be sent automatically if the address in the Disposition-Notification-To header field differs from the address in the Return-Path header field (see RFC-MSGFMT [RFC5322]).
- MUSTIn this case, confirmation from the user MUST be obtained, if possible.
- MUST NOTIf obtaining consent is not possible (e.g., because the user is not online at the time or the client is not an interactive email client), then an MDN MUST NOT be sent.
- MUSTConfirmation from the user MUST be obtained (or no MDN sent) if there is no Return-Path header field in the message or if there is more than one distinct address in the Disposition-Notification-To header field.
- SHOULDThe local-part comparison SHOULD be done after performing local-part canonicalization, i.e., after removing the surrounding double-quote characters, if any, as well as any escaping "\" characters.
- MAY(See RFC-MSGFMT [RFC5322] for more details.) Implementations MAY treat known domain aliases as equivalent for the purpose of comparison.
- SHOULDSimilarly, if an existing message is resent or gatewayed to a newsgroup, the agent that is resending/gatewaying SHOULD strip the Disposition-Notification-To header field.
- SHOULD NOTClients that see an otherwise valid Disposition- Notification-To header field in a newsgroup message SHOULD NOT generate an MDN.
2.2 The Disposition-Notification-Options Header
- MAYAn importance of "optional" indicates that an MUA that does not understand the meaning of this disposition-notification-parameter MAY generate an MDN in response anyway, ignoring the value of the disposition-notification-parameter.
- MUSTnotification-parameter attribute names MUST be registered with the Internet Assigned Numbers Authority (IANA) using the "Specification Required" registration policy [RFC5226].
2.3 The Original-Recipient Header Field
- SHOULDRFC-DSN-SMTP [RFC3461] is amended as follows: if the ORCPT information is available, the delivering MTA SHOULD insert an Original-Recipient header field at the beginning of the message (along with the Return-Path header field).
- MAYThe delivering MTA MAY delete any other Original-Recipient header fields that occur in the message.
- SHOULD; MDN generators SHOULD use "*WSP" ; (Typically a single space or nothing.
- SHOULD; It SHOULD be nothing at the end of a field.), ; unless an RFC 5322 "comment" is required.
- MUST; ; MDN parsers MUST parse it as "[CFWS]".
2.4 Use with the Message/Partial Media Type
- SHOULDWhen a message is segmented into two or more message/partial fragments, the three header fields mentioned in the above paragraph SHOULD be placed in the "inner" or "enclosed" message (using the terms of RFC-MIME-MEDIA [RFC2046]).
- MUST NOTAny occurrences of the three header fields defined here in the header fields of the initial enclosing message MUST NOT be copied to the reassembled message.
3 Format of a Message Disposition Notification
- MUSTHowever, in the case of encrypted messages requesting MDNs, if the original message or a portion thereof is returned, it MUST be in its original encrypted form.
- MUSTThe MDN MUST be addressed (in both the message header field and the transport envelope) to the address(es) from the Disposition- Notification-To header field from the original message for which the MDN is being generated.
- MUSTThe From header field of the MDN MUST contain the address of the person for whom the message disposition notification is being issued.
- MUSTThe envelope sender address (i.e., SMTP "MAIL FROM") of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages nor other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN.
- MUST NOTA message disposition notification MUST NOT itself request an MDN.
- MUST NOTThat is, it MUST NOT contain a Disposition-Notification-To header field.
- MUSTThe Message-ID header field (if present) for an MDN MUST be different from the Message-ID of the message for which the MDN is being issued.
3.1 The Message/Disposition-Notification Media Type
- MUSTEncoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
3.2.1 The Reporting-UA Field
- SHOULDAn MUA SHOULD send a "Reporting-UA" field unless specifically configured not to do so.
- SHOULDA reporting MUA SHOULD limit generated product identifiers to what is necessary to identify the product; a sender MUST NOT generate advertising or other nonessential information within the product identifier.
- SHOULD NOTA reporting MUA SHOULD NOT generate a "Reporting-UA" field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.
3.2.2 The MDN-Gateway Field
- MUSTThis field MUST appear in any MDN that was translated by a gateway from a foreign system into MDN format and MUST NOT appear otherwise.
3.2.3 Original-Recipient Field
- MUSTIf there is an Original-Recipient header field in the message, or if information about the original recipient is reliably available some other way, then the Original-Recipient field MUST be included.
- MUST NOTOtherwise, the Original-Recipient field MUST NOT be included.
3.2.4 Final-Recipient Field
- MUSTThis field MUST be present.
- SHOULDThe generic-address subfield of the Final-Recipient field SHOULD contain the mailbox address of the recipient (which will be the same as the From header field of the MDN) as it was when the MDN was generated by the MUA.
- MUSTSince mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved.
3.2.5 Original-Message-ID Field
- MUSTThis field MUST be present if and only if the original message contained a Message-ID header field.
3.2.6.1 Disposition Modes
- MUST(This might include the case when the user has manually configured her MUA to automatically respond to valid MDN requests.) Unless prescribed otherwise in a particular mail environment, in order to preserve the user's privacy, this MUST be the default for MUAs.
- MUSTOne or the other MUST be specified.
- MUSTUnless prescribed otherwise in a particular mail environment, in order to preserve the user's privacy, this MUST be the default for MUAs.
3.2.6.3 Disposition Modifiers
- MUSTMDN disposition value names MUST be registered with the Internet Assigned Numbers Authority (IANA) using the "Specification Required" registration policy.
- MAY(See Section 10 for a registration form.) MDNs with disposition modifier names not understood by the receiving MUA MAY be silently ignored or placed in the user's mailbox without special interpretation.
- MUST NOTThey MUST NOT cause any error message to be sent to the sender of the MDN.
- MAYHowever, if a message is forwarded, a "dispatched" MDN MAY be issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
3.3 Extension-Fields
- MUSTMDN field names MUST be registered with the Internet Assigned Numbers Authority (IANA) using the "Specification Required" registration policy.
5 Conformance and Usage Requirements
- MUST NOTMUAs and gateways MUST NOT generate the Original-Recipient field of an MDN unless the mail protocols provide the address originally specified by the sender at the time of submission.
- SHOULDSuccessful distribution of a message to a mailing list exploder or gateway to Usenet newsgroup SHOULD be considered the final disposition of the message.
- MAYA mailing list exploder MAY issue an MDN with a disposition type of "processed" and disposition modes of "automatic-action" and "MDN-sent-automatically" indicating that the message has been forwarded to the list.
6.4 Mail Bombing
- SHOULD NOTFor that reason, MDN's SHOULD NOT be sent automatically where the Disposition-Notification-To address is different from the SMTP "MAIL FROM" address (which is carried in the Return-Path header field).
8.1 Gatewaying from Other Mail Systems to MDNs
- MUSTFor MDNs produced from foreign disposition notifications, the name of the gateway MUST appear in the MDN-Gateway field of the MDN.
10 IANA Considerations
- MAYIANA MAY reject registrations because of incomplete registration forms or incomplete specifications.
10.1 Disposition-Notification-Options Header Field
- MUSTA registration for a Disposition-Notification-Options header field disposition-notification-parameter name MUST include the following information:
10.2 Disposition Modifier Names
- MUSTA registration for a disposition-modifier name (used in the Disposition field of a message/disposition-notification) MUST include the following information:
10.3 MDN Extension Field Names
- MUSTA registration for an MDN extension-field name MUST include the following information: