summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8098.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8098.txt')
-rw-r--r--doc/rfc/rfc8098.txt2075
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]
+