4. Timeline of Events The following timeline shows when various events in the processing of a message and generation of MDNs take place: -- User composes message. -- User tells MUA to send message. -- MUA passes message to Mail Submission Agent (MSA) and original recipient information is passed along. -- MSA sends message to next MTA. -- Final MTA receives message. -- Final MTA delivers message to recipient's mailbox (possibly generating a Delivery Status Notification (DSN)). -- (Recipient's) MUA discovers a new message in recipient's mailbox and decides whether an MDN should be generated. If the MUA has information that an MDN has already been generated for this message, no further MDN processing described below is performed. If MUA decides that no MDN can be generated, no further MDN processing described below is performed. -- MUA performs automatic processing and might generate corresponding MDNs ("dispatched", "processed", or "deleted" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes). The MUA remembers that an MDN was generated. -- MUA displays list of messages to user. -- User selects a message and requests that some action be performed on it. -- MUA performs requested action; if an automatic MDN has not already been generated, with user's permission, sends an appropriate MDN ("displayed", "dispatched", "processed", or "deleted" disposition type, with "manual-action" and "MDN-sent-manually" or "MDN-sent- automatically" disposition mode). The MUA remembers that an MDN was generated. -- User possibly performs other actions on message, but no further MDNs are generated.
5. Conformance and Usage Requirements An MUA or gateway conforms to this specification if it generates MDNs according to the protocol defined in this memo. It is not necessary to be able to generate all of the possible values of the Disposition field. MUAs 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. Ordinary SMTP does not make that guarantee, but the SMTP extension defined in RFC-- DSN-SMTP [RFC3461] permits such information to be carried in the envelope if it is available. The Original-Recipient header field defined in this document provides a way for the MTA to pass the original recipient address to the MUA. Each sender-specified recipient address may result in more than one MDN. If an MDN is requested for a recipient that is forwarded to multiple recipients of an "alias" (as defined in Section 220.127.116.11 of RFC-DSN-SMTP [RFC3461]), each of the recipients may issue an MDN. Successful distribution of a message to a mailing list exploder or gateway to Usenet newsgroup SHOULD be considered the final disposition of the message. A 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. In this case, the request for MDNs is not propagated to the members of the list. Alternatively (if successful distribution of a message to a mailing list exploder / Usenet newsgroup is not considered the final disposition of the message), the mailing list exploder can issue no MDN and propagate the request for MDNs to all members of the list. The latter behavior is not recommended for any but small, closely knit lists, as it might cause large numbers of MDNs to be generated and may cause confidential subscribers to the list to be revealed. The mailing list exploder can also direct MDNs to itself, correlate them, and produce a report to the original sender of the message. This specification places no restrictions on the processing of MDNs received by user agents or mailing lists.
6. Security Considerations The following security considerations apply when using MDNs. 6.1. Forgery MDNs can be (and are, in practice) forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of MDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged MDNs include the sending of: a. A falsified disposition notification when the indicated disposition of the message has not actually occurred, and b. Unsolicited MDNs. Similarly, a forged spam or phishing email message can contain Disposition-Notification-To header field that can trick the recipient to send an MDN. MDN processing should only be invoked once authenticity of an email message is verified. 6.2. Privacy Another dimension of security is privacy. There may be cases in which a message recipient does not wish the disposition of messages addressed to him to be known, or is concerned that the sending of MDNs may reveal other sensitive information (e.g., when the message was read, using which email client, and which OS was used). In this situation, it is acceptable for the MUA to silently ignore requests for MDNs. If the Disposition-Notification-To header field is passed on unmodified when a message is distributed to the subscribers of a mailing list, the subscribers to the list may be revealed to the sender of the original message by the generation of MDNs. Headers of the original message returned in part 3 of the multipart/ report, as well as content of the message/disposition-notification part, could reveal confidential information about host names and/or network topology inside a firewall. Disposition mode (Section 18.104.22.168) can leak information about recipient's MUA configuration, in particular, whether MDNs are
acknowledged manually or automatically. If this is a concern, MUAs can return "manual-action/MDN-sent-manually" disposition mode in generated MDNs. In general, any optional MDN field may be omitted if the Reporting MUA site or user determines that inclusion of the field would impose too great a compromise of site confidentiality. The need for such confidentiality must be balanced against the utility of the omitted information in MDNs. In some cases, someone with access to the message stream may use the MDN request mechanism to monitor the mail reading habits of a target. If the target is known to generate MDN reports, they could add a Disposition-Notification-To header field containing the envelope from address. This risk can be minimized by not sending MDN's automatically. 6.2.1. Disclosure of Product Information The "Reporting-UA" field (Section 3.2.1), User-Agent header field, and other header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used. Also note that the "Reporting-UA" field doesn't provide any new information in comparison to the "User-Agent" and/or (undocumented) "X-Mailer" header fields used by many MUAs. 6.2.2. MUA Fingerprinting The "Reporting-UA" field (Section 3.2.1) might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, such as the Accept-Language header fields. 6.3. Non-repudiation MDNs do not provide non-repudiation with proof of delivery. Within the framework of today's Internet Mail, the MDNs defined in this document provide valuable information to the mail user; however, MDNs cannot be relied upon as a guarantee that a message was or was not seen by the recipient. Even if MDNs are not actively forged, they may be lost in transit. The recipient may bypass the MDN issuing mechanism in some manner.
One possible solution for this purpose can be found in RFC-SEC- SERVICES [RFC2634]. 6.4. Mail Bombing The MDN request mechanism introduces an additional way of mail bombing a mailbox. The MDN request notification provides an address to which MDN's should be sent. It is possible for an attacking agent to send a potentially large set of messages to otherwise unsuspecting third party recipients with a false Disposition-Notification-To address. Automatic or simplistic processing of such requests would result in a flood of MDN notifications to the target of the attack. Additionally, as generated MDN notifications can include the full content of messages that caused them and thus they can be bigger than such messages, they can be used for bandwidth amplification attacks. Such an attack could overrun the storage capacity of the targeted mailbox and/or of the mail transport system, and deny service. For 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). See Section 2.1 for further discussion. 7. Collected ABNF Grammar NOTE: The following lexical tokens are defined in RFC-MSGFMT [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, comment, and word. The following lexical tokens are defined in RFC-SMTP [RFC5321]: Atom. (Note that RFC-MSGFMT [RFC5322] also defines "atom", but the version from RFC-SMTP [RFC5321] is more restrictive and this more restrictive version is used in this document.) The "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] is allowed everywhere where RFC-MSGFMT [RFC5322] "comment" is used, for example, in CFWS. OWS = [CFWS] ; Optional whitespace. ; MDN generators SHOULD use "*WSP" ; (Typically a single space or nothing. ; It SHOULD be nothing at the end of a field.), ; unless an RFC 5322 "comment" is required. ; ; MDN parsers MUST parse it as "[CFWS]". Message header fields: mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF
Disposition-Notification-Options = "Disposition-Notification-Options" ":" [FWS] disposition-notification-parameter-list CRLF disposition-notification-parameter-list = disposition-notification-parameter *([FWS] ";" [FWS] disposition-notification-parameter) disposition-notification-parameter = attribute [FWS] "=" [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) importance = "required" / "optional" attribute = Atom value = word original-recipient-header = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS CRLF Report content: disposition-notification-content = [ reporting-ua-field CRLF ] [ mdn-gateway-field CRLF ] [ original-recipient-field CRLF ] final-recipient-field CRLF [ original-message-id-field CRLF ] disposition-field CRLF *( error-field CRLF ) *( extension-field CRLF ) address-type = Atom mta-name-type = Atom reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] ua-name = *text-no-semi ua-product = *([FWS] text) text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name mta-name = *text original-recipient-field = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS generic-address = *text final-recipient-field = "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS original-message-id-field = "Original-Message-ID" ":" msg-id disposition-field = "Disposition" ":" OWS disposition-mode OWS ";" OWS disposition-type [ OWS "/" OWS disposition-modifier *( OWS "," OWS disposition-modifier ) ] OWS disposition-mode = action-mode OWS "/" OWS sending-mode action-mode = "manual-action" / "automatic-action" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" disposition-type = "displayed" / "deleted" / "dispatched" / "processed" disposition-modifier = "error" / disposition-modifier-extension disposition-modifier-extension = Atom error-field = "Error" ":" *([FWS] text) extension-field = extension-field-name ":" *([FWS] text) extension-field-name = field-name
8. Guidelines for Gatewaying MDNs NOTE: This section provides non-binding recommendations for the construction of mail gateways that wish to provide semi-transparent disposition notifications between the Internet and another electronic mail system. Specific MDN gateway requirements for a particular pair of mail systems may be defined by other documents. 8.1. Gatewaying from Other Mail Systems to MDNs A mail gateway may issue an MDN to convey the contents of a "foreign" disposition notification over Internet Mail. When there are appropriate mappings from the foreign notification elements to MDN fields, the information may be transmitted in those MDN fields. Additional information (such as what might be needed to tunnel the foreign notification through the Internet) may be defined in extension MDN fields. (Such fields should be given names that identify the foreign mail protocol, e.g., X400-* for X.400 protocol elements [X.400]). The gateway must attempt to supply reasonable values for the Reporting-UA, Final-Recipient, and Disposition fields. These will normally be obtained by translating the values from the foreign notification into their Internet-style equivalents. However, some loss of information is to be expected. The sender-specified recipient address and the original message-id, if present in the foreign notification, should be preserved in the Original-Recipient and Original-Message-ID fields. The gateway should also attempt to preserve the "final" recipient address from the foreign system. Whenever possible, foreign protocol elements should be encoded as meaningful printable ASCII strings. For MDNs produced from foreign disposition notifications, the name of the gateway MUST appear in the MDN-Gateway field of the MDN. 8.2. Gatewaying from MDNs to Other Mail Systems It may be possible to gateway MDNs from the Internet into a foreign mail system. The primary purpose of such gatewaying is to convey disposition information in a form that is usable by the destination system. A secondary purpose is to allow "tunneling" of MDNs through foreign mail systems in case the MDN may be gatewayed back into the Internet.
In general, the recipient of the MDN (i.e., the sender of the original message) will want to know, for each recipient: the closest available approximation to the original recipient address and the disposition (displayed, printed, etc.). If possible, the gateway should attempt to preserve the Original- Recipient address and Original-Message-ID (if present) in the resulting foreign disposition report. If it is possible to tunnel an MDN through the destination environment, the gateway specification may define a means of preserving the MDN information in the disposition reports used by that environment. 8.3. Gatewaying of MDN-Requests to Other Mail Systems By use of the separate Disposition-Notification-To request header field, this specification offers a richer functionality than most, if not all, other email systems. In most other email systems, the notification recipient is identical to the message sender as indicated in the "from" address. There are two interesting cases when gatewaying into such systems: 1. If the address in the Disposition-Notification-To header field is identical to the address in the SMTP "MAIL FROM", the expected behavior will result, even if the Disposition-Notification-To information is lost. Systems should propagate the MDN request. 2. If the address in the Disposition-Notification-To header field is different from the address in the SMTP "MAIL FROM", gatewaying into a foreign system without a separate notification address will result in unintended behavior. This is especially important when the message arrives via a mailing list expansion software that may specifically replace the SMTP "MAIL FROM" address with an alternate address. In such cases, the MDN request should not be gatewayed and should be silently dropped. This is consistent with other forms of non-support for MDN. 9. Example NOTE: This example is provided as illustration only and is not considered part of the MDN protocol specification. If the example conflicts with the protocol definition above, the example is wrong. Likewise, the use of *-type subfield names or extension fields in this example is not to be construed as a definition for those type names or extension fields.
This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent. Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 From: Joe Recipient <Joe_Recipient@example.com> Message-Id: <email@example.com> Subject: Disposition notification To: Jane Sender <Jane_Sender@example.org> MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615765/example.com" --RAA14128.773615765/example.com The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe Recipient <Joe_Recipient@example.com> with subject "First draft of report" has been displayed. This is no guarantee that the message has been read or understood. --RAA14128.773615765/example.com Content-Type: message/disposition-notification Reporting-UA: joes-pc.cs.example.com; Foomail 97.1 Original-Recipient: rfc822;Joe_Recipient@example.com Final-Recipient: rfc822;Joe_Recipient@example.com Original-Message-ID: <firstname.lastname@example.org> Disposition: manual-action/MDN-sent-manually; displayed --RAA14128.773615765/example.com Content-Type: message/rfc822 [original message optionally goes here] --RAA14128.773615765/example.com-- 10. IANA Considerations IANA has completed the following actions: 1. IANA has updated the registration template for the message/ disposition-notification media type to match what appears in Section 3.1 of this document and updated the reference for the media type to point to this document (instead of to RFC 3798). 2. The registries specified here already exist; this section updates their documentation. IANA has changed the reference document for the three Message Disposition Notification Parameters registries to point to this document (instead of to RFC 3798).
This document specifies three types of parameters that must be registered with the Internet Assigned Numbers Authority (IANA). All of them use the "Specification Required" IANA registration policy [RFC5226]. The forms below are for use when registering a new disposition- notification-parameter name for the Disposition-Notification-Options header field, a new disposition modifier name, or a new MDN extension field. Each piece of information required by a registration form may be satisfied either by providing the information on the form itself or by including a reference to a published and publicly available specification that includes the necessary information. IANA MAY reject registrations because of incomplete registration forms or incomplete specifications. To register, complete the following applicable form and send it via electronic mail to <IANA@IANA.ORG>. 10.1. Disposition-Notification-Options Header Field disposition-notification-parameter Names A registration for a Disposition-Notification-Options header field disposition-notification-parameter name MUST include the following information: a. The proposed disposition-notification-parameter name. b. The syntax for disposition-notification-parameter values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language. c. If disposition-notification-parameter values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a Disposition-Notification-Options header field. d. A reference to a permanent and readily available public specification that describes the semantics of the disposition- notification-parameter values.
10.2. Disposition Modifier Names A registration for a disposition-modifier name (used in the Disposition field of a message/disposition-notification) MUST include the following information: a. The proposed disposition-modifier name. b. A reference to a permanent and readily available public specification that describes the semantics of the disposition modifier. 10.3. MDN Extension Field Names A registration for an MDN extension-field name MUST include the following information: a. The proposed extension field name. b. The syntax for extension values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language. c. If extension-field values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a Disposition-Notification-Options header field. d. A reference to a permanent and readily available public specification that describes the semantics of the extension field. 11. References 11.1. Normative References [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <http://www.rfc-editor.org/info/rfc2047>. [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <http://www.rfc-editor.org/info/rfc6522>. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, <http://www.rfc-editor.org/info/rfc3461>. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)", RFC 3503, DOI 10.17487/RFC3503, March 2003, <http://www.rfc-editor.org/info/rfc3503>. 11.2. Informative References [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, <http://www.rfc-editor.org/info/rfc2634>. [RFC3249] Cancio, V., Moldovan, M., Tamura, H., and D. Wing, "Implementers Guide for Facsimile Using Internet Mail", RFC 3249, DOI 10.17487/RFC3249, September 2002, <http://www.rfc-editor.org/info/rfc3249>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>. [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, DOI 10.17487/RFC3801, June 2004, <http://www.rfc-editor.org/info/rfc3801>. [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, <http://www.rfc-editor.org/info/rfc5233>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and Extended Reject Extensions", RFC 5429, DOI 10.17487/RFC5429, March 2009, <http://www.rfc-editor.org/info/rfc5429>. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>. [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <http://www.rfc-editor.org/info/rfc6533>. [X.400] International Telecommunications Union, "Message handling system and service overview", ITU-T Recommendation F.400/X.400, June 1999.
Appendix A. Changes from RFC 3798 Changed IANA registration for different subregistries to "Specification Required" to match what is already used by IANA. Updated IANA registration template for message/disposition- notification. "X-" fields no longer reserved for experimental use and can now be registered in compliance with RFC 6648. Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns". Strengthen requirements on obtaining user consent in order to protect user privacy. Removed discussion of using source routes with MDNs, as source route is a deprecated Email feature. The values of "dispatched" and "processed" were lost from the ABNF for "disposition-type". (Erratum #691) Because the warning disposition modifier was previously removed, the warning-field has also been removed. (Erratum #692) Because the failed disposition type was previously removed, the failure-field has also been removed. The ABNF for ua-name and ua-product included a semi-colon, which could not be distinguished from *text in the production. The ua-name was restricted to not include semi-colon. Semi-colon can still appear in the ua-product. Removed recommendation to include the MUA DNS host name in the "Reporting-UA" MDN field. The ABNF did not indicate all places that whitespace was allowable, in particular folding whitespace, although all implementations allow whitespace and folding in the header fields just like any other header field formatted as described in RFC-MSGFMT [RFC5322]. There were also a number of places in the ABNF that inconsistently permitted comments and whitespace in one leg of the production and not another. The ABNF now specifies FWS and CFWS in several places that should have already been specified by the grammar. Extension-field was defined in the collected grammar but not in the main text.
The comparison of mailboxes in Disposition-Notification-To to the Return-Path addr-spec was clarified. The use of the grammar production "parameter" was confusing with the RFC 2045 [RFC2045] production of the same name, as well as other uses of the same term. These have been clarified. A clarification was added on the extent of the 7bit nature of MDNs. Uses of the terms "may" and "might" were clarified. A clarification was added on the order of the fields in the message/ disposition-notification content. Acknowledgements The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben Campbell, Pete Resnick, Donald Eastlake, and Alissa Cooper are gratefully acknowledged for this revision. The contributions of Roger Fajman and Greg Vaudreuil to earlier draft versions of this document are also gratefully acknowledged. Authors' Addresses Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 United States of America Email: email@example.com Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom Email: Alexey.Melnikov@isode.com