diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc8098.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc8098.txt')
-rw-r--r-- | doc/rfc/rfc8098.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc8098.txt b/doc/rfc/rfc8098.txt new file mode 100644 index 0000000..5906a55 --- /dev/null +++ b/doc/rfc/rfc8098.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Hansen, Ed. +Request for Comments: 8098 AT&T Laboratories +STD: 85 A. Melnikov, Ed. +Obsoletes: 3798 Isode Ltd +Updates: 2046, 3461 February 2017 +Category: Standards Track +ISSN: 2070-1721 + + + Message Disposition Notification + +Abstract + + 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.400 and the proprietary + "LAN-based" systems, and are often referred to as "read receipts," + "acknowledgements," or "receipt notifications." The intention is to + do this while respecting privacy concerns, which have often been + expressed when such functions have been discussed in the past. + + Because many messages are sent between the Internet and other + messaging systems (such as X.400 or the proprietary "LAN-based" + systems), the MDN protocol is designed to be useful in a + multiprotocol messaging environment. To this end, the protocol + described in this memo provides for the carriage of "foreign" + addresses, in addition to those normally used in Internet Mail. + Additional attributes may also be defined to support "tunneling" of + foreign notifications through Internet Mail. + + This document is an Internet Standard. It obsoletes RFC 3798 and + updates RFC 2046 (message/partial media type handling) and RFC 3461 + (Original-Recipient header field generation requirement). + + + + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 1] + +RFC 8098 MDN February 2017 + + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8098. + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 2] + +RFC 8098 MDN February 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Requesting Message Disposition Notifications . . . . . . . . 5 + 2.1. The Disposition-Notification-To Header . . . . . . . . . 5 + 2.2. The Disposition-Notification-Options Header . . . . . . . 8 + 2.3. The Original-Recipient Header Field . . . . . . . . . . . 9 + 2.4. Use with the Message/Partial Media Type . . . . . . . . . 10 + 3. Format of a Message Disposition Notification . . . . . . . . 10 + 3.1. The Message/Disposition-Notification Media Type . . . . . 12 + 3.2. Message/Disposition-Notification Content Fields . . . . . 15 + 3.3. Extension-Fields . . . . . . . . . . . . . . . . . . . . 21 + 4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . 22 + 5. Conformance and Usage Requirements . . . . . . . . . . . . . 23 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.2.1. Disclosure of Product Information . . . . . . . . . . 25 + 6.2.2. MUA Fingerprinting . . . . . . . . . . . . . . . . . 25 + 6.3. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 25 + 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 26 + 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 29 + 8.1. Gatewaying from Other Mail Systems to MDNs . . . . . . . 29 + 8.2. Gatewaying from MDNs to Other Mail Systems . . . . . . . 29 + 8.3. Gatewaying of MDN-Requests to Other Mail Systems . . . . 30 + 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 10.1. Disposition-Notification-Options Header Field + disposition-notification-parameter Names . . . . . . . . 32 + 10.2. Disposition Modifier Names . . . . . . . . . . . . . . . 33 + 10.3. MDN Extension Field Names . . . . . . . . . . . . . . . 33 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 11.2. Informative References . . . . . . . . . . . . . . . . . 34 + Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 36 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 3] + +RFC 8098 MDN February 2017 + + +1. Introduction + + This memo defines a media type [RFC2046] for Message Disposition + Notifications (MDNs). An MDN can be used to notify the sender of a + message of any of several conditions that may occur after successful + delivery, such as display of the message contents, printing of the + message, deletion (without display) of the message, or the + recipient's refusal to provide MDNs. The "message/disposition- + notification" content type defined herein is intended for use within + the framework of the "multipart/report" content type defined in + RFC-REPORT [RFC6522]. + + This memo defines the format of the notifications and the RFC-MSGFMT + [RFC5322] header fields used to request them. + +1.1. Purposes + + The MDNs defined in this memo are expected to serve several purposes: + + a. Inform human beings of the disposition of messages after + successful delivery in a manner that is largely independent of + human language; + + b. Allow mail user agents to keep track of the disposition of + messages sent by associating returned MDNs with earlier message + transmissions; + + c. Convey disposition notification requests and disposition + notifications between Internet Mail and "foreign" mail systems + via a gateway; + + d. Allow "foreign" notifications to be tunneled through a MIME- + capable messaging system and back into the original messaging + system that issued the original notification, or even to a third + messaging system; + + e. Allow language-independent, yet reasonably precise, indications + of the disposition of a message to be delivered. + +1.2. Requirements + + These purposes place the following constraints on the notification + protocol: + + a. It must be readable by humans and must be machine parsable. + + + + + + +Hansen & Melnikov Standards Track [Page 4] + +RFC 8098 MDN February 2017 + + + b. It must provide enough information to allow message senders (or + their user agents) to unambiguously associate an MDN with the + message that was sent and the original recipient address for + which the MDN was issued (if such information is available), even + if the message was forwarded to another recipient address. + + c. It must also be able to describe the disposition of a message + independent of any particular human language or of the + terminology of any particular mail system. + + d. The specification must be extensible in order to accommodate + future requirements. + +1.3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC-KEYWORDS + [RFC2119]. + + All syntax descriptions use the ABNF specified by RFC-MSGFMT + [RFC5322] in which the lexical tokens (used below) are defined: + "CRLF", "FWS", "CFWS", "field-name", "mailbox-list", "msg-id", and + "text". The following lexical token is defined in RFC-SMTP + [RFC5321]: "Atom". + +2. Requesting Message Disposition Notifications + + Message disposition notifications are requested by including a + Disposition-Notification-To header field in the message containing + one or more addresses specifying where dispositions should be sent. + Further information to be used by the recipient's Mail User Agent + (MUA) [RFC5598] in generating the MDN may be provided by also + including Original-Recipient and/or Disposition-Notification-Options + header fields in the message. + +2.1. The Disposition-Notification-To Header + + A request for the receiving user agent to issue message disposition + notifications is made by placing a Disposition-Notification-To header + field into the message. The syntax of the header field is + + mdn-request-header = "Disposition-Notification-To" ":" + mailbox-list CRLF + + A Disposition-Notification-To header field can appear in a message at + most once. + + + + +Hansen & Melnikov Standards Track [Page 5] + +RFC 8098 MDN February 2017 + + + The presence of a Disposition-Notification-To header field in a + message is merely a request for an MDN. The recipients' user agents + are always free to silently ignore such a request. + + An MDN MUST NOT itself have a Disposition-Notification-To header + field. An MDN MUST NOT be generated in response to an MDN. + + A user agent MUST NOT issue more than one MDN on behalf of each + particular recipient. That is, once an MDN has been issued on behalf + of a recipient, no further MDNs may be issued on behalf of that + recipient by the same user agent, even if another disposition is + performed on the message. However, if a message is forwarded, an MDN + may have been issued for the recipient doing the forwarding, and the + recipient of the forwarded message may also cause an MDN to be + generated. + + It is also possible that if the same message is being accessed by + multiple user agents (for example, using POP3), then multiple + dispositions might be generated for the same recipient. User agents + SHOULD leverage support in the underlying message access protocol to + prevent multiple MDNs from being generated. In particular, when the + user agent is accessing the message using RFC-IMAP [RFC3501], it + SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503]. + + While Internet standards normally do not specify the behavior of user + interfaces, it is strongly recommended that the user agent obtain the + user's consent before sending an MDN. This consent could be obtained + for each message through some sort of prompt or dialog box, or + globally through the user's setting of a preference. The user might + also indicate globally that MDNs are to never be sent. The purpose + of obtaining user's consent is to protect user's privacy. The + default value should be not to send MDNs. + + MDNs 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]). In this + case, confirmation from the user MUST be obtained, if possible. If + 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. + + Confirmation 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. + + + + + + +Hansen & Melnikov Standards Track [Page 6] + +RFC 8098 MDN February 2017 + + + The comparison of the addresses is done using only the addr-spec + (local-part "@" domain) portion, excluding any angle brackets, + phrase, and route. As prescribed by RFC 5322, the comparison is case + sensitive for the local-part and case insensitive for the domain + part. The 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. (See RFC-MSGFMT [RFC5322] for more details.) + Implementations MAY treat known domain aliases as equivalent for the + purpose of comparison. + + Note that use of subaddressing (see [RFC5233]) can result in a + failure to match two local-parts and thus result in possible + suppression of the MDN. This document doesn't recommend special + handling for this case, as the receiving MUA can't reliably know + whether or not the sender is using subaddressing. + + If the message contains more than one Return-Path header field, the + implementation may pick one to use for the comparison or treat the + situation as a failure of the comparison. + + The reason for not automatically sending an MDN if the comparison + fails or more than one address is specified is to reduce the + possibility of mail loops and of MDNs being used for mail bombing. + + It's especially important that a message that contains a Disposition- + Notification-To header field also contain a Message-ID header field + to permit user agents to automatically correlate MDNs with their + original messages. + + If the request for message disposition notifications for some + recipients and not others is desired, two copies of the message + should be sent, one with a Disposition-Notification-To header field + and one without. Many of the other header fields of the message + (e.g., To, Cc) will be the same in both copies. The recipients in + the respective message envelopes determine from whom message + disposition notifications are requested and from whom they are not. + If desired, the Message-ID header field may be the same in both + copies of the message. Note that there are other situations (e.g., + Bcc) in which it is necessary to send multiple copies of a message + with slightly different header fields. The combination of such + situations and the need to request MDNs for a subset of all + recipients may result in more than two copies of a message being + sent, some with a Disposition-Notification-To header field and some + without. + + + + + + +Hansen & Melnikov Standards Track [Page 7] + +RFC 8098 MDN February 2017 + + + If it is possible to determine that a recipient is a newsgroup, do + not include a Disposition-Notification-To header field for that + recipient. Similarly, 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. See Section 5 for more + discussion. Clients 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 + + Extensions to this specification may require that information be + supplied to the recipient's MUA for additional control over how and + what MDNs are generated. The Disposition-Notification-Options header + field provides an extensible mechanism for such information. The + syntax of this header field is as follows: + + 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 + + A Disposition-Notification-Options header field can appear in a + message at most once. + + An importance of "required" indicates that interpretation of the + disposition-notification-parameter is necessary for proper generation + of an MDN in response to this request. An 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. + + No disposition-notification-parameter attribute names are defined in + this specification. Attribute names may be defined in the future by + later revisions or extensions to this specification. Disposition- + + + +Hansen & Melnikov Standards Track [Page 8] + +RFC 8098 MDN February 2017 + + + notification-parameter attribute names MUST be registered with the + Internet Assigned Numbers Authority (IANA) using the "Specification + Required" registration policy [RFC5226]. The "X-" prefix has + historically been used to denote unregistered "experimental" protocol + elements that are assumed not to become common use. Deployment + experience of this and other protocols has shown that this assumption + is often false. This document allows the use of the "X-" prefix + primarily to allow the registration of attributes that are already in + common use. The prefix has no meaning for new attributes. Its use + in substantially new attributes may cause confusion and is therefore + discouraged. (See Section 10 for a registration form.) + +2.3. The Original-Recipient Header Field + + Since electronic mail addresses may be rewritten while the message is + in transit, it is useful for the original recipient address to be + made available by the delivering Message Transfer Agent (MTA) + [RFC5598]. The delivering MTA may be able to obtain this information + from the ORCPT parameter of the SMTP RCPT TO command, as defined in + RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461]. + + RFC-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). The delivering MTA MAY + delete any other Original-Recipient header fields that occur in the + message. The syntax of this header field is as follows: + + original-recipient-header = + "Original-Recipient" ":" OWS address-type OWS + ";" OWS generic-address OWS + + 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]". + + The address-type and generic-address tokens are as specified in the + description of the Original-Recipient field in Section 3.2.3. + + The purpose of carrying the original recipient information and + returning it in the MDN is to permit automatic correlation of MDNs + with the original message on a per-recipient basis. + + + + +Hansen & Melnikov Standards Track [Page 9] + +RFC 8098 MDN February 2017 + + +2.4. Use with the Message/Partial Media Type + + The use of the header fields Disposition-Notification-To, + Disposition-Notification-Options, and Original-Recipient with the + MIME message/partial content type (RFC-MIME-MEDIA [RFC2046]) requires + further definition. + + When 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]). If these header fields are found + in the header fields of any of the fragments, they are ignored. + + When the multiple message/partial fragments are reassembled, the + following applies. If these header fields occur along with the other + header fields of a message/partial fragment message, they pertain to + an MDN that will be generated for the fragment. If these header + fields occur in the header fields of the "inner" or "enclosed" + message (using the terms of RFC-MIME-MEDIA [RFC2046]), they pertain + to an MDN that will be generated for the reassembled message. + Section 5.2.2.1 of RFC-MIME-MEDIA [RFC2046]) is amended to specify + that, in addition to the header fields specified there, the three + header fields described in this specification are to be appended, in + order, to the header fields of the reassembled message. Any + 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 + + A message disposition notification is a MIME message with a top-level + content type of multipart/report (defined in RFC-REPORT [RFC6522]). + When multipart/report content is used to transmit an MDN: + + a. The report-type parameter of the multipart/report content is + "disposition-notification". + + b. The first component of the multipart/report contains a human- + readable explanation of the MDN, as described in RFC-REPORT + [RFC6522]. + + c. The second component of the multipart/report is of content type + message/disposition-notification, described in Section 3.1 of + this document. + + + + + + + +Hansen & Melnikov Standards Track [Page 10] + +RFC 8098 MDN February 2017 + + + d. If the original message or a portion of the message is to be + returned to the sender, it appears as the third component of the + multipart/report. The decision of whether or not to return the + message or part of the message is up to the MUA generating the + MDN. However, 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. + + NOTE: For message disposition notifications gatewayed from foreign + systems, the header fields of the original message may not be + available. In this case, the third component of the MDN may be + omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header + fields that contain equivalent information. In particular, it is + very desirable to preserve the subject and date fields from the + original message. + + The 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. + + The From header field of the MDN MUST contain the address of the + person for whom the message disposition notification is being issued. + + The 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. + + A message disposition notification MUST NOT itself request an MDN. + That is, it MUST NOT contain a Disposition-Notification-To header + field. + + The 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. + + A particular MDN describes the disposition of exactly one message for + exactly one recipient. Multiple MDNs may be generated as a result of + one message submission, one per recipient. However, due to the + circumstances described in Section 2.1, it's possible that some of + the recipients for whom MDNs were requested will not generate MDNs. + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 11] + +RFC 8098 MDN February 2017 + + +3.1. The Message/Disposition-Notification Media Type + + The message/disposition-notification media type is defined as + follows: + + Type name: message + + Subtype name: disposition-notification + + Required parameters: none + + Optional parameters: none + + Encoding considerations: "7bit" encoding is sufficient and MUST be + used to maintain readability when viewed by + non-MIME mail readers. + + Security considerations: discussed in Section 6 of RFC 8098. + + Interoperability considerations: none + + Published specification: RFC 8098 + + Applications that use this media type: Mail Transfer Agents and + email clients that support multipart/report + generation and/or parsing. + + Fragment identifier considerations: N/A + + Additional information: + + Deprecated alias names for this type: N/A + + Magic number(s): none + + File extension(s): .disposition-notification + + Macintosh file type code(s): The 'TEXT' type + code is suggested as files of this type are + typically used for diagnostic purposes and + suitable for analysis in a text editor. A + Uniform Type Identifier (UTI) of "public.utf8- + email-message-header" is suggested. This type + conforms to "public.plain-text". + + Person & email address to contact for further information: + ART Area Mailing List <art@ietf.org> + + + + +Hansen & Melnikov Standards Track [Page 12] + +RFC 8098 MDN February 2017 + + + Intended usage: COMMON + + Restrictions on usage: This media type contains textual data in the + US-ASCII charset, which is always 7bit. + + Author: See the Authors' Addresses section of RFC 8098. + + Change controller: IETF + + Provisional registration? no + + (While the 7bit restriction applies to the message/disposition- + notification portion of the multipart/report content, it does not + apply to the optional third portion of the multipart/report content.) + + The message/disposition-notification report type for use in the + multipart/report is "disposition-notification". + + The body of a message/disposition-notification consists of one or + more "fields" formatted according to the ABNF of RFC-MSGFMT [RFC5322] + header "fields". The syntax of the message/disposition-notification + content is as follows: + + 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 ) + + extension-field = extension-field-name ":" *([FWS] text) + + extension-field-name = field-name + + Note that the order of the above fields is recommended but not fixed. + Extension fields can appear anywhere. + +3.1.1. General Conventions for Fields + + Since these fields are defined according to the rules of RFC-MSGFMT + [RFC5322], the same conventions for continuation lines and comments + apply. Notification fields may be continued onto multiple lines by + beginning each additional line with a SPACE or HTAB. Text that + appears in parentheses is considered a comment and not part of the + contents of that notification field. Field names are case + insensitive, so the names of notification fields may be spelled in + + + +Hansen & Melnikov Standards Track [Page 13] + +RFC 8098 MDN February 2017 + + + any combination of uppercase and lowercase letters. RFC-MSGFMT + [RFC5322] comments in notification fields may use the "encoded-word" + construct defined in RFC-MIME-HEADER [RFC2047]. + +3.1.2. "*-type" Subfields + + Several fields consist of a "-type" subfield, followed by a semi- + colon, followed by "*text". For these fields, the keyword used in + the address-type or MTA-type subfield indicates the expected format + of the address or MTA-name that follows. + + The "-type" subfields are defined as follows: + + a. An "address-type" specifies the format of a mailbox address. For + example, Internet Mail addresses use the "rfc822" address-type. + Other values can appear in this field as specified in the + "Address Types" IANA subregistry established by RFC-DSN-FORMAT + [RFC3464]. + + address-type = Atom + + Atom = <The version from RFC 5321 (not from RFC 5322) + is used in this document.> + + b. An "MTA-name-type" specifies the format of a mail transfer agent + name. For example, for an SMTP server on an Internet host, the + MTA name is the domain name of that host, and the "dns" MTA-name- + type is used. Other values can appear in this field as specified + in the "MTA Name Types" IANA subregistry established by RFC-DSN- + FORMAT [RFC3464]. + + mta-name-type = Atom + + Values for address-type and mta-name-type are case insensitive. + Thus, address-type values of "RFC822" and "rfc822" are equivalent. + + The Internet Assigned Numbers Authority (IANA) maintains a registry + of address-type and mta-name-type values, along with descriptions of + the meanings of each or a reference to one or more specifications + that provide such descriptions. (The "rfc822" address-type is + defined in RFC-DSN-SMTP [RFC3461].) Registration forms for address- + type and mta-name-type appear in RFC-DSN-FORMAT [RFC3464]. + + + + + + + + + +Hansen & Melnikov Standards Track [Page 14] + +RFC 8098 MDN February 2017 + + +3.2. Message/Disposition-Notification Content Fields + +3.2.1. The Reporting-UA Field + + 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 + + The Reporting-UA field is defined as follows: + + An MDN describes the disposition of a message after it has been + delivered to a recipient. In all cases, the Reporting-UA is the MUA + that performed the disposition described in the MDN. + + The "Reporting-UA" field contains information about the MUA that + generated the MDN, which is often used by servers to help identify + the scope of reported interoperability problems, to work around or + tailor responses to avoid particular MUA limitations, and for + analytics regarding MUA or operating system use. An MUA SHOULD send + a "Reporting-UA" field unless specifically configured not to do so. + + If the reporting MUA consists of more than one component (e.g., a + base program and plug-ins), this may be indicated by including a list + of product names. + + A 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. + + A reporting MUA SHOULD NOT generate a "Reporting-UA" field containing + needlessly fine-grained detail and SHOULD limit the addition of + subproducts by third parties. Overly long and detailed "Reporting- + UA" field values increase the risk of a user being identified against + their wishes ("fingerprinting"). + + Likewise, implementations are encouraged not to use the product + tokens of other implementations in order to declare compatibility + with them, as this circumvents the purpose of the field. If an MUA + masquerades as a different MUA, recipients can assume that the user + + + + + +Hansen & Melnikov Standards Track [Page 15] + +RFC 8098 MDN February 2017 + + + intentionally desires to see responses tailored for that identified + MUA, even if they might not work as well for the actual MUA being + used. + + Example: + + Reporting-UA: Foomail 97.1 + +3.2.2. The MDN-Gateway Field + + The MDN-Gateway field indicates the name of the gateway or MTA that + translated a foreign (non-Internet) message disposition notification + into this MDN. This field MUST appear in any MDN that was translated + by a gateway from a foreign system into MDN format and MUST NOT + appear otherwise. + + mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS + ";" OWS mta-name OWS + + mta-name = *text + + For gateways into Internet Mail, the MTA-name-type will normally be + "dns", and the mta-name will be the Internet domain name of the + gateway. + +3.2.3. Original-Recipient Field + + The Original-Recipient field indicates the original recipient address + as specified by the sender of the message for which the MDN is being + issued. For Internet Mail messages, the value of the Original- + Recipient field is obtained from the Original-Recipient header field + from the message for which the MDN is being generated. If 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. Otherwise, the + Original-Recipient field MUST NOT be included. If there is more than + one Original-Recipient header field in the message, the MUA may + choose the one to use or act as if no Original-Recipient header field + is present. + + original-recipient-field = + "Original-Recipient" ":" OWS address-type OWS + ";" OWS generic-address OWS + + generic-address = *text + + The address-type field indicates the type of the original recipient + address. If the message originated within the Internet, the address- + + + +Hansen & Melnikov Standards Track [Page 16] + +RFC 8098 MDN February 2017 + + + type field will normally be "rfc822", and the address will be + according to the syntax specified in RFC-MSGFMT [RFC5322]. The value + "unknown" should be used if the Reporting MUA cannot determine the + type of the original recipient address from the message envelope. + This address is the same as that provided by the sender and can be + used to automatically correlate MDN reports with original messages on + a per-recipient basis. + +3.2.4. Final-Recipient Field + + The Final-Recipient field indicates the recipient for which the MDN + is being issued. This field MUST be present. + + The syntax of the field is as follows: + + final-recipient-field = "Final-Recipient" ":" OWS address-type OWS + ";" OWS generic-address OWS + + The 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. + + One example of when this field might not contain the final + recipient address of the message is when an alias (e.g., + <customer-support@example.com>) forwards mail to a specific + personal address (e.g., <bob@example.com>). Bob might want to be + able to send MDNs but not give away his personal email address. + In this case, the Final-Recipient field can contain: + + Final-Recipient: rfc822;customer-support@example.com + + in place of: + + Final-Recipient: rfc822;bob@example.com + + The Final-Recipient address may differ from the address originally + provided by the sender, because it may have been transformed during + forwarding and gatewaying into a totally unrecognizable mess. + However, in the absence of the optional Original-Recipient field, the + Final-Recipient field and any returned content may be the only + information available with which to correlate the MDN with a + particular message recipient. + + The address-type subfield indicates the type of address expected by + the reporting MTA in that context. Recipient addresses obtained via + SMTP will normally be of address-type "rfc822", but can be other + + + + +Hansen & Melnikov Standards Track [Page 17] + +RFC 8098 MDN February 2017 + + + values from the "Address Types" subregistry of the "Delivery Status + Notification (DSN) Types" IANA registry. + + Since 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 + + The Original-Message-ID field indicates the message-ID of the message + for which the MDN is being issued. It is obtained from the + Message-ID header field of the message for which the MDN is issued. + This field MUST be present if and only if the original message + contained a Message-ID header field. The syntax of the field is as + follows: + + original-message-id-field = + "Original-Message-ID" ":" msg-id + + The msg-id token is as specified in RFC-MSGFMT [RFC5322]. + +3.2.6. Disposition Field + + The Disposition field indicates the action performed by the Reporting + MUA on behalf of the user. This field MUST be present. + + The syntax for the Disposition field is: + + 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 + + + + + +Hansen & Melnikov Standards Track [Page 18] + +RFC 8098 MDN February 2017 + + + The disposition-mode, disposition-type, and disposition-modifier + values may be spelled in any combination of uppercase and lowercase + US-ASCII characters. + +3.2.6.1. Disposition Modes + + Disposition mode consists of two parts: action mode and sending mode. + + The following action modes are defined: + + "manual-action" The disposition described by the disposition type + was a result of an explicit instruction by the + user rather than some sort of automatically + performed action. (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. + + "automatic-action" The disposition described by the disposition type + was a result of an automatic action rather than + an explicit instruction by the user for this + message. This is typically generated by a Mail + Delivery Agent (e.g., MDN generations by Sieve + reject action [RFC5429], Fax-over-Email + [RFC3249], voice message system (see Voice + Profile for Internet Mail (VPIM) [RFC3801]), or + upon delivery to a mailing list). + + "Manual-action" and "automatic-action" are mutually exclusive. One + or the other MUST be specified. + + The following sending modes are defined: + + "MDN-sent-manually" The user explicitly gave permission for this + particular MDN to be sent. Unless prescribed + otherwise in a particular mail environment, in + order to preserve the user's privacy, this MUST + be the default for MUAs. + + "MDN-sent-automatically" + The MDN was sent because the MUA had previously + been configured to do so automatically. + + "MDN-sent-manually" and "MDN-sent-automatically" are mutually + exclusive. One or the other MUST be specified. + + + + +Hansen & Melnikov Standards Track [Page 19] + +RFC 8098 MDN February 2017 + + +3.2.6.2. Disposition Types + + The following disposition-types are defined: + + "displayed" The message has been displayed by the MUA to + someone reading the recipient's mailbox. There + is no guarantee that the content has been read or + understood. + + "dispatched" The message has been sent somewhere in some + manner (e.g., printed, faxed, forwarded) without + necessarily having been previously displayed to + the user. The user may or may not see the + message later. + + "processed" The message has been processed in some manner + (i.e., by some sort of rules or server) without + being displayed to the user. The user may or may + not see the message later, or there may not even + be a human user associated with the mailbox. + + "deleted" The message has been deleted. The recipient may + or may not have seen the message. The recipient + might "undelete" the message at a later time and + read the message. + +3.2.6.3. Disposition Modifiers + + Only the extension disposition modifiers are defined: + + disposition-modifier-extension + Disposition modifiers may be defined in the + future by later revisions or extensions to this + specification. MDN disposition value names MUST + be registered with the Internet Assigned Numbers + Authority (IANA) using the "Specification + Required" registration policy. (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. + They MUST NOT cause any error message to be sent + to the sender of the MDN. + + It is not required that an MUA be able to generate all of the + possible values of the Disposition field. + + + + + +Hansen & Melnikov Standards Track [Page 20] + +RFC 8098 MDN February 2017 + + + A user agent MUST NOT issue more than one MDN on behalf of each + particular recipient. That is, once an MDN has been issued on behalf + of a recipient, no further MDNs may be issued on behalf of that + recipient, even if another disposition is performed on the message. + However, 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.2.7. Error Field + + The Error field is used to supply additional information in the form + of text messages when the "error" disposition modifier appears. The + syntax is as follows: + + error-field = "Error" ":" *([FWS] text) + + Note that syntax of these header fields doesn't include comments, so + the "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] + can't be used to convey non-ASCII text. Applications that need to + convey non-ASCII text in these fields should consider implementing + the message/global-disposition-notification media type specified in + [RFC6533] instead of this specification. + +3.3. Extension-Fields + + Additional MDN fields may be defined in the future by later revisions + or extensions to this specification. MDN field names MUST be + registered with the Internet Assigned Numbers Authority (IANA) using + the "Specification Required" registration policy. (See Section 10 + for a registration form.) MDN Extension-fields may be defined for + the following reasons: + + a. To allow additional information from foreign disposition reports + to be tunneled through Internet MDNs. The names of such MDN + fields should begin with an indication of the foreign environment + name (e.g., X400-Physical-Forwarding-Address). + + b. To allow transmission of diagnostic information that is specific + to a particular Mail User Agent (MUA). The names of such MDN + fields should begin with an indication of the MUA implementation + that produced the MDN (e.g., Foomail-information). + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 21] + +RFC 8098 MDN February 2017 + + +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. + + + + + + +Hansen & Melnikov Standards Track [Page 22] + +RFC 8098 MDN February 2017 + + +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 6.2.7.3 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. + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 23] + +RFC 8098 MDN February 2017 + + +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 3.2.6.1) can leak information about + recipient's MUA configuration, in particular, whether MDNs are + + + + + +Hansen & Melnikov Standards Track [Page 24] + +RFC 8098 MDN February 2017 + + + 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. + + + + +Hansen & Melnikov Standards Track [Page 25] + +RFC 8098 MDN February 2017 + + + 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 + + + + +Hansen & Melnikov Standards Track [Page 26] + +RFC 8098 MDN February 2017 + + + 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 + + + + +Hansen & Melnikov Standards Track [Page 27] + +RFC 8098 MDN February 2017 + + + 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 + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 28] + +RFC 8098 MDN February 2017 + + +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. + + + + + + +Hansen & Melnikov Standards Track [Page 29] + +RFC 8098 MDN February 2017 + + + 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. + + + + +Hansen & Melnikov Standards Track [Page 30] + +RFC 8098 MDN February 2017 + + + 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: <199509200019.12345@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: <199509192301.23456@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). + + + +Hansen & Melnikov Standards Track [Page 31] + +RFC 8098 MDN February 2017 + + + 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. + + + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 32] + +RFC 8098 MDN February 2017 + + +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>. + + + + +Hansen & Melnikov Standards Track [Page 33] + +RFC 8098 MDN February 2017 + + + [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>. + + + + + + +Hansen & Melnikov Standards Track [Page 34] + +RFC 8098 MDN February 2017 + + + [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. + + + + + + + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 35] + +RFC 8098 MDN February 2017 + + +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. + + + + +Hansen & Melnikov Standards Track [Page 36] + +RFC 8098 MDN February 2017 + + + 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: tony@att.com + + + Alexey Melnikov (editor) + Isode Ltd + 14 Castle Mews + Hampton, Middlesex TW12 2NP + United Kingdom + + Email: Alexey.Melnikov@isode.com + + + + + + + + + + +Hansen & Melnikov Standards Track [Page 37] + |