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 126.96.36.199 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.
Section 188.8.131.52) 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. 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. 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.
One possible solution for this purpose can be found in RFC-SEC- SERVICES [RFC2634]. Section 2.1 for further discussion. 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
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.
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.
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-- 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>.
[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>. [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.
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.