7Internet Engineering Task Force (IETF) T. Hansen, Ed.
8Request for Comments: 8098 AT&T Laboratories
9STD: 85 A. Melnikov, Ed.
10Obsoletes: 3798 Isode Ltd
11Updates: 2046, 3461 February 2017
12Category: Standards Track
16 Message Disposition Notification
20 This memo defines a MIME content type that may be used by a Mail User
21 Agent (MUA) or electronic mail gateway to report the disposition of a
22 message after it has been successfully delivered to a recipient.
23 This content type is intended to be machine processable. Additional
24 message header fields are also defined to permit Message Disposition
25 Notifications (MDNs) to be requested by the sender of a message. The
26 purpose is to extend Internet Mail to support functionality often
27 found in other messaging systems, such as X.400 and the proprietary
28 "LAN-based" systems, and are often referred to as "read receipts,"
29 "acknowledgements," or "receipt notifications." The intention is to
30 do this while respecting privacy concerns, which have often been
31 expressed when such functions have been discussed in the past.
33 Because many messages are sent between the Internet and other
34 messaging systems (such as X.400 or the proprietary "LAN-based"
35 systems), the MDN protocol is designed to be useful in a
36 multiprotocol messaging environment. To this end, the protocol
37 described in this memo provides for the carriage of "foreign"
38 addresses, in addition to those normally used in Internet Mail.
39 Additional attributes may also be defined to support "tunneling" of
40 foreign notifications through Internet Mail.
42 This document is an Internet Standard. It obsoletes RFC 3798 and
43 updates RFC 2046 (message/partial media type handling) and RFC 3461
44 (Original-Recipient header field generation requirement).
58Hansen & Melnikov Standards Track [Page 1]
60RFC 8098 MDN February 2017
65 This is an Internet Standards Track document.
67 This document is a product of the Internet Engineering Task Force
68 (IETF). It represents the consensus of the IETF community. It has
69 received public review and has been approved for publication by the
70 Internet Engineering Steering Group (IESG). Further information on
71 Internet Standards is available in Section 2 of RFC 7841.
73 Information about the current status of this document, any errata,
74 and how to provide feedback on it may be obtained at
75 http://www.rfc-editor.org/info/rfc8098.
79 Copyright (c) 2017 IETF Trust and the persons identified as the
80 document authors. All rights reserved.
82 This document is subject to BCP 78 and the IETF Trust's Legal
83 Provisions Relating to IETF Documents
84 (http://trustee.ietf.org/license-info) in effect on the date of
85 publication of this document. Please review these documents
86 carefully, as they describe your rights and restrictions with respect
87 to this document. Code Components extracted from this document must
88 include Simplified BSD License text as described in Section 4.e of
89 the Trust Legal Provisions and are provided without warranty as
90 described in the Simplified BSD License.
114Hansen & Melnikov Standards Track [Page 2]
116RFC 8098 MDN February 2017
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
122 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 4
123 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
124 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
125 2. Requesting Message Disposition Notifications . . . . . . . . 5
126 2.1. The Disposition-Notification-To Header . . . . . . . . . 5
127 2.2. The Disposition-Notification-Options Header . . . . . . . 8
128 2.3. The Original-Recipient Header Field . . . . . . . . . . . 9
129 2.4. Use with the Message/Partial Media Type . . . . . . . . . 10
130 3. Format of a Message Disposition Notification . . . . . . . . 10
131 3.1. The Message/Disposition-Notification Media Type . . . . . 12
132 3.2. Message/Disposition-Notification Content Fields . . . . . 15
133 3.3. Extension-Fields . . . . . . . . . . . . . . . . . . . . 21
134 4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . 22
135 5. Conformance and Usage Requirements . . . . . . . . . . . . . 23
136 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
137 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 24
138 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24
139 6.2.1. Disclosure of Product Information . . . . . . . . . . 25
140 6.2.2. MUA Fingerprinting . . . . . . . . . . . . . . . . . 25
141 6.3. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 25
142 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 26
143 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 26
144 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 29
145 8.1. Gatewaying from Other Mail Systems to MDNs . . . . . . . 29
146 8.2. Gatewaying from MDNs to Other Mail Systems . . . . . . . 29
147 8.3. Gatewaying of MDN-Requests to Other Mail Systems . . . . 30
148 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
149 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
150 10.1. Disposition-Notification-Options Header Field
151 disposition-notification-parameter Names . . . . . . . . 32
152 10.2. Disposition Modifier Names . . . . . . . . . . . . . . . 33
153 10.3. MDN Extension Field Names . . . . . . . . . . . . . . . 33
154 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
155 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
156 11.2. Informative References . . . . . . . . . . . . . . . . . 34
157 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 36
158 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
170Hansen & Melnikov Standards Track [Page 3]
172RFC 8098 MDN February 2017
177 This memo defines a media type [RFC2046] for Message Disposition
178 Notifications (MDNs). An MDN can be used to notify the sender of a
179 message of any of several conditions that may occur after successful
180 delivery, such as display of the message contents, printing of the
181 message, deletion (without display) of the message, or the
182 recipient's refusal to provide MDNs. The "message/disposition-
183 notification" content type defined herein is intended for use within
184 the framework of the "multipart/report" content type defined in
185 RFC-REPORT [RFC6522].
187 This memo defines the format of the notifications and the RFC-MSGFMT
188 [RFC5322] header fields used to request them.
192 The MDNs defined in this memo are expected to serve several purposes:
194 a. Inform human beings of the disposition of messages after
195 successful delivery in a manner that is largely independent of
198 b. Allow mail user agents to keep track of the disposition of
199 messages sent by associating returned MDNs with earlier message
202 c. Convey disposition notification requests and disposition
203 notifications between Internet Mail and "foreign" mail systems
206 d. Allow "foreign" notifications to be tunneled through a MIME-
207 capable messaging system and back into the original messaging
208 system that issued the original notification, or even to a third
211 e. Allow language-independent, yet reasonably precise, indications
212 of the disposition of a message to be delivered.
216 These purposes place the following constraints on the notification
219 a. It must be readable by humans and must be machine parsable.
226Hansen & Melnikov Standards Track [Page 4]
228RFC 8098 MDN February 2017
231 b. It must provide enough information to allow message senders (or
232 their user agents) to unambiguously associate an MDN with the
233 message that was sent and the original recipient address for
234 which the MDN was issued (if such information is available), even
235 if the message was forwarded to another recipient address.
237 c. It must also be able to describe the disposition of a message
238 independent of any particular human language or of the
239 terminology of any particular mail system.
241 d. The specification must be extensible in order to accommodate
246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
248 document are to be interpreted as described in RFC-KEYWORDS
251 All syntax descriptions use the ABNF specified by RFC-MSGFMT
252 [RFC5322] in which the lexical tokens (used below) are defined:
253 "CRLF", "FWS", "CFWS", "field-name", "mailbox-list", "msg-id", and
254 "text". The following lexical token is defined in RFC-SMTP
2572. Requesting Message Disposition Notifications
259 Message disposition notifications are requested by including a
260 Disposition-Notification-To header field in the message containing
261 one or more addresses specifying where dispositions should be sent.
262 Further information to be used by the recipient's Mail User Agent
263 (MUA) [RFC5598] in generating the MDN may be provided by also
264 including Original-Recipient and/or Disposition-Notification-Options
265 header fields in the message.
2672.1. The Disposition-Notification-To Header
269 A request for the receiving user agent to issue message disposition
270 notifications is made by placing a Disposition-Notification-To header
271 field into the message. The syntax of the header field is
273 mdn-request-header = "Disposition-Notification-To" ":"
276 A Disposition-Notification-To header field can appear in a message at
282Hansen & Melnikov Standards Track [Page 5]
284RFC 8098 MDN February 2017
287 The presence of a Disposition-Notification-To header field in a
288 message is merely a request for an MDN. The recipients' user agents
289 are always free to silently ignore such a request.
291 An MDN MUST NOT itself have a Disposition-Notification-To header
292 field. An MDN MUST NOT be generated in response to an MDN.
294 A user agent MUST NOT issue more than one MDN on behalf of each
295 particular recipient. That is, once an MDN has been issued on behalf
296 of a recipient, no further MDNs may be issued on behalf of that
297 recipient by the same user agent, even if another disposition is
298 performed on the message. However, if a message is forwarded, an MDN
299 may have been issued for the recipient doing the forwarding, and the
300 recipient of the forwarded message may also cause an MDN to be
303 It is also possible that if the same message is being accessed by
304 multiple user agents (for example, using POP3), then multiple
305 dispositions might be generated for the same recipient. User agents
306 SHOULD leverage support in the underlying message access protocol to
307 prevent multiple MDNs from being generated. In particular, when the
308 user agent is accessing the message using RFC-IMAP [RFC3501], it
309 SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503].
311 While Internet standards normally do not specify the behavior of user
312 interfaces, it is strongly recommended that the user agent obtain the
313 user's consent before sending an MDN. This consent could be obtained
314 for each message through some sort of prompt or dialog box, or
315 globally through the user's setting of a preference. The user might
316 also indicate globally that MDNs are to never be sent. The purpose
317 of obtaining user's consent is to protect user's privacy. The
318 default value should be not to send MDNs.
320 MDNs MUST NOT be sent automatically if the address in the
321 Disposition-Notification-To header field differs from the address in
322 the Return-Path header field (see RFC-MSGFMT [RFC5322]). In this
323 case, confirmation from the user MUST be obtained, if possible. If
324 obtaining consent is not possible (e.g., because the user is not
325 online at the time or the client is not an interactive email client),
326 then an MDN MUST NOT be sent.
328 Confirmation from the user MUST be obtained (or no MDN sent) if there
329 is no Return-Path header field in the message or if there is more
330 than one distinct address in the Disposition-Notification-To header
338Hansen & Melnikov Standards Track [Page 6]
340RFC 8098 MDN February 2017
343 The comparison of the addresses is done using only the addr-spec
344 (local-part "@" domain) portion, excluding any angle brackets,
345 phrase, and route. As prescribed by RFC 5322, the comparison is case
346 sensitive for the local-part and case insensitive for the domain
347 part. The local-part comparison SHOULD be done after performing
348 local-part canonicalization, i.e., after removing the surrounding
349 double-quote characters, if any, as well as any escaping "\"
350 characters. (See RFC-MSGFMT [RFC5322] for more details.)
351 Implementations MAY treat known domain aliases as equivalent for the
352 purpose of comparison.
354 Note that use of subaddressing (see [RFC5233]) can result in a
355 failure to match two local-parts and thus result in possible
356 suppression of the MDN. This document doesn't recommend special
357 handling for this case, as the receiving MUA can't reliably know
358 whether or not the sender is using subaddressing.
360 If the message contains more than one Return-Path header field, the
361 implementation may pick one to use for the comparison or treat the
362 situation as a failure of the comparison.
364 The reason for not automatically sending an MDN if the comparison
365 fails or more than one address is specified is to reduce the
366 possibility of mail loops and of MDNs being used for mail bombing.
368 It's especially important that a message that contains a Disposition-
369 Notification-To header field also contain a Message-ID header field
370 to permit user agents to automatically correlate MDNs with their
373 If the request for message disposition notifications for some
374 recipients and not others is desired, two copies of the message
375 should be sent, one with a Disposition-Notification-To header field
376 and one without. Many of the other header fields of the message
377 (e.g., To, Cc) will be the same in both copies. The recipients in
378 the respective message envelopes determine from whom message
379 disposition notifications are requested and from whom they are not.
380 If desired, the Message-ID header field may be the same in both
381 copies of the message. Note that there are other situations (e.g.,
382 Bcc) in which it is necessary to send multiple copies of a message
383 with slightly different header fields. The combination of such
384 situations and the need to request MDNs for a subset of all
385 recipients may result in more than two copies of a message being
386 sent, some with a Disposition-Notification-To header field and some
394Hansen & Melnikov Standards Track [Page 7]
396RFC 8098 MDN February 2017
399 If it is possible to determine that a recipient is a newsgroup, do
400 not include a Disposition-Notification-To header field for that
401 recipient. Similarly, if an existing message is resent or gatewayed
402 to a newsgroup, the agent that is resending/gatewaying SHOULD strip
403 the Disposition-Notification-To header field. See Section 5 for more
404 discussion. Clients that see an otherwise valid Disposition-
405 Notification-To header field in a newsgroup message SHOULD NOT
4082.2. The Disposition-Notification-Options Header
410 Extensions to this specification may require that information be
411 supplied to the recipient's MUA for additional control over how and
412 what MDNs are generated. The Disposition-Notification-Options header
413 field provides an extensible mechanism for such information. The
414 syntax of this header field is as follows:
416 Disposition-Notification-Options =
417 "Disposition-Notification-Options" ":" [FWS]
418 disposition-notification-parameter-list CRLF
420 disposition-notification-parameter-list =
421 disposition-notification-parameter
422 *([FWS] ";" [FWS] disposition-notification-parameter)
424 disposition-notification-parameter = attribute [FWS] "="
425 [FWS] importance [FWS] "," [FWS] value
426 *([FWS] "," [FWS] value)
428 importance = "required" / "optional"
434 A Disposition-Notification-Options header field can appear in a
435 message at most once.
437 An importance of "required" indicates that interpretation of the
438 disposition-notification-parameter is necessary for proper generation
439 of an MDN in response to this request. An importance of "optional"
440 indicates that an MUA that does not understand the meaning of this
441 disposition-notification-parameter MAY generate an MDN in response
442 anyway, ignoring the value of the disposition-notification-parameter.
444 No disposition-notification-parameter attribute names are defined in
445 this specification. Attribute names may be defined in the future by
446 later revisions or extensions to this specification. Disposition-
450Hansen & Melnikov Standards Track [Page 8]
452RFC 8098 MDN February 2017
455 notification-parameter attribute names MUST be registered with the
456 Internet Assigned Numbers Authority (IANA) using the "Specification
457 Required" registration policy [RFC5226]. The "X-" prefix has
458 historically been used to denote unregistered "experimental" protocol
459 elements that are assumed not to become common use. Deployment
460 experience of this and other protocols has shown that this assumption
461 is often false. This document allows the use of the "X-" prefix
462 primarily to allow the registration of attributes that are already in
463 common use. The prefix has no meaning for new attributes. Its use
464 in substantially new attributes may cause confusion and is therefore
465 discouraged. (See Section 10 for a registration form.)
4672.3. The Original-Recipient Header Field
469 Since electronic mail addresses may be rewritten while the message is
470 in transit, it is useful for the original recipient address to be
471 made available by the delivering Message Transfer Agent (MTA)
472 [RFC5598]. The delivering MTA may be able to obtain this information
473 from the ORCPT parameter of the SMTP RCPT TO command, as defined in
474 RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461].
476 RFC-DSN-SMTP [RFC3461] is amended as follows: if the ORCPT
477 information is available, the delivering MTA SHOULD insert an
478 Original-Recipient header field at the beginning of the message
479 (along with the Return-Path header field). The delivering MTA MAY
480 delete any other Original-Recipient header fields that occur in the
481 message. The syntax of this header field is as follows:
483 original-recipient-header =
484 "Original-Recipient" ":" OWS address-type OWS
485 ";" OWS generic-address OWS
488 ; Optional whitespace.
489 ; MDN generators SHOULD use "*WSP"
490 ; (Typically a single space or nothing.
491 ; It SHOULD be nothing at the end of a field.),
492 ; unless an RFC 5322 "comment" is required.
494 ; MDN parsers MUST parse it as "[CFWS]".
496 The address-type and generic-address tokens are as specified in the
497 description of the Original-Recipient field in Section 3.2.3.
499 The purpose of carrying the original recipient information and
500 returning it in the MDN is to permit automatic correlation of MDNs
501 with the original message on a per-recipient basis.
506Hansen & Melnikov Standards Track [Page 9]
508RFC 8098 MDN February 2017
5112.4. Use with the Message/Partial Media Type
513 The use of the header fields Disposition-Notification-To,
514 Disposition-Notification-Options, and Original-Recipient with the
515 MIME message/partial content type (RFC-MIME-MEDIA [RFC2046]) requires
518 When a message is segmented into two or more message/partial
519 fragments, the three header fields mentioned in the above paragraph
520 SHOULD be placed in the "inner" or "enclosed" message (using the
521 terms of RFC-MIME-MEDIA [RFC2046]). If these header fields are found
522 in the header fields of any of the fragments, they are ignored.
524 When the multiple message/partial fragments are reassembled, the
525 following applies. If these header fields occur along with the other
526 header fields of a message/partial fragment message, they pertain to
527 an MDN that will be generated for the fragment. If these header
528 fields occur in the header fields of the "inner" or "enclosed"
529 message (using the terms of RFC-MIME-MEDIA [RFC2046]), they pertain
530 to an MDN that will be generated for the reassembled message.
531 Section 5.2.2.1 of RFC-MIME-MEDIA [RFC2046]) is amended to specify
532 that, in addition to the header fields specified there, the three
533 header fields described in this specification are to be appended, in
534 order, to the header fields of the reassembled message. Any
535 occurrences of the three header fields defined here in the header
536 fields of the initial enclosing message MUST NOT be copied to the
5393. Format of a Message Disposition Notification
541 A message disposition notification is a MIME message with a top-level
542 content type of multipart/report (defined in RFC-REPORT [RFC6522]).
543 When multipart/report content is used to transmit an MDN:
545 a. The report-type parameter of the multipart/report content is
546 "disposition-notification".
548 b. The first component of the multipart/report contains a human-
549 readable explanation of the MDN, as described in RFC-REPORT
552 c. The second component of the multipart/report is of content type
553 message/disposition-notification, described in Section 3.1 of
562Hansen & Melnikov Standards Track [Page 10]
564RFC 8098 MDN February 2017
567 d. If the original message or a portion of the message is to be
568 returned to the sender, it appears as the third component of the
569 multipart/report. The decision of whether or not to return the
570 message or part of the message is up to the MUA generating the
571 MDN. However, in the case of encrypted messages requesting MDNs,
572 if the original message or a portion thereof is returned, it MUST
573 be in its original encrypted form.
575 NOTE: For message disposition notifications gatewayed from foreign
576 systems, the header fields of the original message may not be
577 available. In this case, the third component of the MDN may be
578 omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header
579 fields that contain equivalent information. In particular, it is
580 very desirable to preserve the subject and date fields from the
583 The MDN MUST be addressed (in both the message header field and the
584 transport envelope) to the address(es) from the Disposition-
585 Notification-To header field from the original message for which the
586 MDN is being generated.
588 The From header field of the MDN MUST contain the address of the
589 person for whom the message disposition notification is being issued.
591 The envelope sender address (i.e., SMTP "MAIL FROM") of the MDN MUST
592 be null (<>), specifying that no Delivery Status Notification
593 messages nor other messages indicating successful or unsuccessful
594 delivery are to be sent in response to an MDN.
596 A message disposition notification MUST NOT itself request an MDN.
597 That is, it MUST NOT contain a Disposition-Notification-To header
600 The Message-ID header field (if present) for an MDN MUST be different
601 from the Message-ID of the message for which the MDN is being issued.
603 A particular MDN describes the disposition of exactly one message for
604 exactly one recipient. Multiple MDNs may be generated as a result of
605 one message submission, one per recipient. However, due to the
606 circumstances described in Section 2.1, it's possible that some of
607 the recipients for whom MDNs were requested will not generate MDNs.
618Hansen & Melnikov Standards Track [Page 11]
620RFC 8098 MDN February 2017
6233.1. The Message/Disposition-Notification Media Type
625 The message/disposition-notification media type is defined as
630 Subtype name: disposition-notification
632 Required parameters: none
634 Optional parameters: none
636 Encoding considerations: "7bit" encoding is sufficient and MUST be
637 used to maintain readability when viewed by
638 non-MIME mail readers.
640 Security considerations: discussed in Section 6 of RFC 8098.
642 Interoperability considerations: none
644 Published specification: RFC 8098
646 Applications that use this media type: Mail Transfer Agents and
647 email clients that support multipart/report
648 generation and/or parsing.
650 Fragment identifier considerations: N/A
652 Additional information:
654 Deprecated alias names for this type: N/A
656 Magic number(s): none
658 File extension(s): .disposition-notification
660 Macintosh file type code(s): The 'TEXT' type
661 code is suggested as files of this type are
662 typically used for diagnostic purposes and
663 suitable for analysis in a text editor. A
664 Uniform Type Identifier (UTI) of "public.utf8-
665 email-message-header" is suggested. This type
666 conforms to "public.plain-text".
668 Person & email address to contact for further information:
669 ART Area Mailing List <art@ietf.org>
674Hansen & Melnikov Standards Track [Page 12]
676RFC 8098 MDN February 2017
679 Intended usage: COMMON
681 Restrictions on usage: This media type contains textual data in the
682 US-ASCII charset, which is always 7bit.
684 Author: See the Authors' Addresses section of RFC 8098.
686 Change controller: IETF
688 Provisional registration? no
690 (While the 7bit restriction applies to the message/disposition-
691 notification portion of the multipart/report content, it does not
692 apply to the optional third portion of the multipart/report content.)
694 The message/disposition-notification report type for use in the
695 multipart/report is "disposition-notification".
697 The body of a message/disposition-notification consists of one or
698 more "fields" formatted according to the ABNF of RFC-MSGFMT [RFC5322]
699 header "fields". The syntax of the message/disposition-notification
700 content is as follows:
702 disposition-notification-content = [ reporting-ua-field CRLF ]
703 [ mdn-gateway-field CRLF ]
704 [ original-recipient-field CRLF ]
705 final-recipient-field CRLF
706 [ original-message-id-field CRLF ]
707 disposition-field CRLF
708 *( error-field CRLF )
709 *( extension-field CRLF )
711 extension-field = extension-field-name ":" *([FWS] text)
713 extension-field-name = field-name
715 Note that the order of the above fields is recommended but not fixed.
716 Extension fields can appear anywhere.
7183.1.1. General Conventions for Fields
720 Since these fields are defined according to the rules of RFC-MSGFMT
721 [RFC5322], the same conventions for continuation lines and comments
722 apply. Notification fields may be continued onto multiple lines by
723 beginning each additional line with a SPACE or HTAB. Text that
724 appears in parentheses is considered a comment and not part of the
725 contents of that notification field. Field names are case
726 insensitive, so the names of notification fields may be spelled in
730Hansen & Melnikov Standards Track [Page 13]
732RFC 8098 MDN February 2017
735 any combination of uppercase and lowercase letters. RFC-MSGFMT
736 [RFC5322] comments in notification fields may use the "encoded-word"
737 construct defined in RFC-MIME-HEADER [RFC2047].
7393.1.2. "*-type" Subfields
741 Several fields consist of a "-type" subfield, followed by a semi-
742 colon, followed by "*text". For these fields, the keyword used in
743 the address-type or MTA-type subfield indicates the expected format
744 of the address or MTA-name that follows.
746 The "-type" subfields are defined as follows:
748 a. An "address-type" specifies the format of a mailbox address. For
749 example, Internet Mail addresses use the "rfc822" address-type.
750 Other values can appear in this field as specified in the
751 "Address Types" IANA subregistry established by RFC-DSN-FORMAT
756 Atom = <The version from RFC 5321 (not from RFC 5322)
757 is used in this document.>
759 b. An "MTA-name-type" specifies the format of a mail transfer agent
760 name. For example, for an SMTP server on an Internet host, the
761 MTA name is the domain name of that host, and the "dns" MTA-name-
762 type is used. Other values can appear in this field as specified
763 in the "MTA Name Types" IANA subregistry established by RFC-DSN-
768 Values for address-type and mta-name-type are case insensitive.
769 Thus, address-type values of "RFC822" and "rfc822" are equivalent.
771 The Internet Assigned Numbers Authority (IANA) maintains a registry
772 of address-type and mta-name-type values, along with descriptions of
773 the meanings of each or a reference to one or more specifications
774 that provide such descriptions. (The "rfc822" address-type is
775 defined in RFC-DSN-SMTP [RFC3461].) Registration forms for address-
776 type and mta-name-type appear in RFC-DSN-FORMAT [RFC3464].
786Hansen & Melnikov Standards Track [Page 14]
788RFC 8098 MDN February 2017
7913.2. Message/Disposition-Notification Content Fields
7933.2.1. The Reporting-UA Field
795 reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS
796 [ ";" OWS ua-product OWS ]
798 ua-name = *text-no-semi
800 ua-product = *([FWS] text)
802 text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
803 %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
805 The Reporting-UA field is defined as follows:
807 An MDN describes the disposition of a message after it has been
808 delivered to a recipient. In all cases, the Reporting-UA is the MUA
809 that performed the disposition described in the MDN.
811 The "Reporting-UA" field contains information about the MUA that
812 generated the MDN, which is often used by servers to help identify
813 the scope of reported interoperability problems, to work around or
814 tailor responses to avoid particular MUA limitations, and for
815 analytics regarding MUA or operating system use. An MUA SHOULD send
816 a "Reporting-UA" field unless specifically configured not to do so.
818 If the reporting MUA consists of more than one component (e.g., a
819 base program and plug-ins), this may be indicated by including a list
822 A reporting MUA SHOULD limit generated product identifiers to what is
823 necessary to identify the product; a sender MUST NOT generate
824 advertising or other nonessential information within the product
827 A reporting MUA SHOULD NOT generate a "Reporting-UA" field containing
828 needlessly fine-grained detail and SHOULD limit the addition of
829 subproducts by third parties. Overly long and detailed "Reporting-
830 UA" field values increase the risk of a user being identified against
831 their wishes ("fingerprinting").
833 Likewise, implementations are encouraged not to use the product
834 tokens of other implementations in order to declare compatibility
835 with them, as this circumvents the purpose of the field. If an MUA
836 masquerades as a different MUA, recipients can assume that the user
842Hansen & Melnikov Standards Track [Page 15]
844RFC 8098 MDN February 2017
847 intentionally desires to see responses tailored for that identified
848 MUA, even if they might not work as well for the actual MUA being
853 Reporting-UA: Foomail 97.1
8553.2.2. The MDN-Gateway Field
857 The MDN-Gateway field indicates the name of the gateway or MTA that
858 translated a foreign (non-Internet) message disposition notification
859 into this MDN. This field MUST appear in any MDN that was translated
860 by a gateway from a foreign system into MDN format and MUST NOT
863 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS
868 For gateways into Internet Mail, the MTA-name-type will normally be
869 "dns", and the mta-name will be the Internet domain name of the
8723.2.3. Original-Recipient Field
874 The Original-Recipient field indicates the original recipient address
875 as specified by the sender of the message for which the MDN is being
876 issued. For Internet Mail messages, the value of the Original-
877 Recipient field is obtained from the Original-Recipient header field
878 from the message for which the MDN is being generated. If there is
879 an Original-Recipient header field in the message, or if information
880 about the original recipient is reliably available some other way,
881 then the Original-Recipient field MUST be included. Otherwise, the
882 Original-Recipient field MUST NOT be included. If there is more than
883 one Original-Recipient header field in the message, the MUA may
884 choose the one to use or act as if no Original-Recipient header field
887 original-recipient-field =
888 "Original-Recipient" ":" OWS address-type OWS
889 ";" OWS generic-address OWS
891 generic-address = *text
893 The address-type field indicates the type of the original recipient
894 address. If the message originated within the Internet, the address-
898Hansen & Melnikov Standards Track [Page 16]
900RFC 8098 MDN February 2017
903 type field will normally be "rfc822", and the address will be
904 according to the syntax specified in RFC-MSGFMT [RFC5322]. The value
905 "unknown" should be used if the Reporting MUA cannot determine the
906 type of the original recipient address from the message envelope.
907 This address is the same as that provided by the sender and can be
908 used to automatically correlate MDN reports with original messages on
909 a per-recipient basis.
9113.2.4. Final-Recipient Field
913 The Final-Recipient field indicates the recipient for which the MDN
914 is being issued. This field MUST be present.
916 The syntax of the field is as follows:
918 final-recipient-field = "Final-Recipient" ":" OWS address-type OWS
919 ";" OWS generic-address OWS
921 The generic-address subfield of the Final-Recipient field SHOULD
922 contain the mailbox address of the recipient (which will be the same
923 as the From header field of the MDN) as it was when the MDN was
924 generated by the MUA.
926 One example of when this field might not contain the final
927 recipient address of the message is when an alias (e.g.,
928 <customer-support@example.com>) forwards mail to a specific
929 personal address (e.g., <bob@example.com>). Bob might want to be
930 able to send MDNs but not give away his personal email address.
931 In this case, the Final-Recipient field can contain:
933 Final-Recipient: rfc822;customer-support@example.com
937 Final-Recipient: rfc822;bob@example.com
939 The Final-Recipient address may differ from the address originally
940 provided by the sender, because it may have been transformed during
941 forwarding and gatewaying into a totally unrecognizable mess.
942 However, in the absence of the optional Original-Recipient field, the
943 Final-Recipient field and any returned content may be the only
944 information available with which to correlate the MDN with a
945 particular message recipient.
947 The address-type subfield indicates the type of address expected by
948 the reporting MTA in that context. Recipient addresses obtained via
949 SMTP will normally be of address-type "rfc822", but can be other
954Hansen & Melnikov Standards Track [Page 17]
956RFC 8098 MDN February 2017
959 values from the "Address Types" subregistry of the "Delivery Status
960 Notification (DSN) Types" IANA registry.
962 Since mailbox addresses (including those used in the Internet) may be
963 case sensitive, the case of alphabetic characters in the address MUST
9663.2.5. Original-Message-ID Field
968 The Original-Message-ID field indicates the message-ID of the message
969 for which the MDN is being issued. It is obtained from the
970 Message-ID header field of the message for which the MDN is issued.
971 This field MUST be present if and only if the original message
972 contained a Message-ID header field. The syntax of the field is as
975 original-message-id-field =
976 "Original-Message-ID" ":" msg-id
978 The msg-id token is as specified in RFC-MSGFMT [RFC5322].
9803.2.6. Disposition Field
982 The Disposition field indicates the action performed by the Reporting
983 MUA on behalf of the user. This field MUST be present.
985 The syntax for the Disposition field is:
988 "Disposition" ":" OWS disposition-mode OWS ";"
990 [ OWS "/" OWS disposition-modifier
991 *( OWS "," OWS disposition-modifier ) ] OWS
993 disposition-mode = action-mode OWS "/" OWS sending-mode
995 action-mode = "manual-action" / "automatic-action"
997 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
999 disposition-type = "displayed" / "deleted" / "dispatched" /
1002 disposition-modifier = "error" / disposition-modifier-extension
1004 disposition-modifier-extension = Atom
1010Hansen & Melnikov Standards Track [Page 18]
1012RFC 8098 MDN February 2017
1015 The disposition-mode, disposition-type, and disposition-modifier
1016 values may be spelled in any combination of uppercase and lowercase
1017 US-ASCII characters.
10193.2.6.1. Disposition Modes
1021 Disposition mode consists of two parts: action mode and sending mode.
1023 The following action modes are defined:
1025 "manual-action" The disposition described by the disposition type
1026 was a result of an explicit instruction by the
1027 user rather than some sort of automatically
1028 performed action. (This might include the case
1029 when the user has manually configured her MUA to
1030 automatically respond to valid MDN requests.)
1031 Unless prescribed otherwise in a particular mail
1032 environment, in order to preserve the user's
1033 privacy, this MUST be the default for MUAs.
1035 "automatic-action" The disposition described by the disposition type
1036 was a result of an automatic action rather than
1037 an explicit instruction by the user for this
1038 message. This is typically generated by a Mail
1039 Delivery Agent (e.g., MDN generations by Sieve
1040 reject action [RFC5429], Fax-over-Email
1041 [RFC3249], voice message system (see Voice
1042 Profile for Internet Mail (VPIM) [RFC3801]), or
1043 upon delivery to a mailing list).
1045 "Manual-action" and "automatic-action" are mutually exclusive. One
1046 or the other MUST be specified.
1048 The following sending modes are defined:
1050 "MDN-sent-manually" The user explicitly gave permission for this
1051 particular MDN to be sent. Unless prescribed
1052 otherwise in a particular mail environment, in
1053 order to preserve the user's privacy, this MUST
1054 be the default for MUAs.
1056 "MDN-sent-automatically"
1057 The MDN was sent because the MUA had previously
1058 been configured to do so automatically.
1060 "MDN-sent-manually" and "MDN-sent-automatically" are mutually
1061 exclusive. One or the other MUST be specified.
1066Hansen & Melnikov Standards Track [Page 19]
1068RFC 8098 MDN February 2017
10713.2.6.2. Disposition Types
1073 The following disposition-types are defined:
1075 "displayed" The message has been displayed by the MUA to
1076 someone reading the recipient's mailbox. There
1077 is no guarantee that the content has been read or
1080 "dispatched" The message has been sent somewhere in some
1081 manner (e.g., printed, faxed, forwarded) without
1082 necessarily having been previously displayed to
1083 the user. The user may or may not see the
1086 "processed" The message has been processed in some manner
1087 (i.e., by some sort of rules or server) without
1088 being displayed to the user. The user may or may
1089 not see the message later, or there may not even
1090 be a human user associated with the mailbox.
1092 "deleted" The message has been deleted. The recipient may
1093 or may not have seen the message. The recipient
1094 might "undelete" the message at a later time and
10973.2.6.3. Disposition Modifiers
1099 Only the extension disposition modifiers are defined:
1101 disposition-modifier-extension
1102 Disposition modifiers may be defined in the
1103 future by later revisions or extensions to this
1104 specification. MDN disposition value names MUST
1105 be registered with the Internet Assigned Numbers
1106 Authority (IANA) using the "Specification
1107 Required" registration policy. (See Section 10
1108 for a registration form.) MDNs with disposition
1109 modifier names not understood by the receiving
1110 MUA MAY be silently ignored or placed in the
1111 user's mailbox without special interpretation.
1112 They MUST NOT cause any error message to be sent
1113 to the sender of the MDN.
1115 It is not required that an MUA be able to generate all of the
1116 possible values of the Disposition field.
1122Hansen & Melnikov Standards Track [Page 20]
1124RFC 8098 MDN February 2017
1127 A user agent MUST NOT issue more than one MDN on behalf of each
1128 particular recipient. That is, once an MDN has been issued on behalf
1129 of a recipient, no further MDNs may be issued on behalf of that
1130 recipient, even if another disposition is performed on the message.
1131 However, if a message is forwarded, a "dispatched" MDN MAY be issued
1132 for the recipient doing the forwarding and the recipient of the
1133 forwarded message may also cause an MDN to be generated.
1137 The Error field is used to supply additional information in the form
1138 of text messages when the "error" disposition modifier appears. The
1139 syntax is as follows:
1141 error-field = "Error" ":" *([FWS] text)
1143 Note that syntax of these header fields doesn't include comments, so
1144 the "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047]
1145 can't be used to convey non-ASCII text. Applications that need to
1146 convey non-ASCII text in these fields should consider implementing
1147 the message/global-disposition-notification media type specified in
1148 [RFC6533] instead of this specification.
11503.3. Extension-Fields
1152 Additional MDN fields may be defined in the future by later revisions
1153 or extensions to this specification. MDN field names MUST be
1154 registered with the Internet Assigned Numbers Authority (IANA) using
1155 the "Specification Required" registration policy. (See Section 10
1156 for a registration form.) MDN Extension-fields may be defined for
1157 the following reasons:
1159 a. To allow additional information from foreign disposition reports
1160 to be tunneled through Internet MDNs. The names of such MDN
1161 fields should begin with an indication of the foreign environment
1162 name (e.g., X400-Physical-Forwarding-Address).
1164 b. To allow transmission of diagnostic information that is specific
1165 to a particular Mail User Agent (MUA). The names of such MDN
1166 fields should begin with an indication of the MUA implementation
1167 that produced the MDN (e.g., Foomail-information).
1178Hansen & Melnikov Standards Track [Page 21]
1180RFC 8098 MDN February 2017
11834. Timeline of Events
1185 The following timeline shows when various events in the processing of
1186 a message and generation of MDNs take place:
1188 -- User composes message.
1190 -- User tells MUA to send message.
1192 -- MUA passes message to Mail Submission Agent (MSA) and original
1193 recipient information is passed along.
1195 -- MSA sends message to next MTA.
1197 -- Final MTA receives message.
1199 -- Final MTA delivers message to recipient's mailbox (possibly
1200 generating a Delivery Status Notification (DSN)).
1202 -- (Recipient's) MUA discovers a new message in recipient's mailbox
1203 and decides whether an MDN should be generated. If the MUA has
1204 information that an MDN has already been generated for this
1205 message, no further MDN processing described below is performed.
1206 If MUA decides that no MDN can be generated, no further MDN
1207 processing described below is performed.
1209 -- MUA performs automatic processing and might generate corresponding
1210 MDNs ("dispatched", "processed", or "deleted" disposition type
1211 with "automatic-action" and "MDN-sent-automatically" disposition
1212 modes). The MUA remembers that an MDN was generated.
1214 -- MUA displays list of messages to user.
1216 -- User selects a message and requests that some action be performed
1219 -- MUA performs requested action; if an automatic MDN has not already
1220 been generated, with user's permission, sends an appropriate MDN
1221 ("displayed", "dispatched", "processed", or "deleted" disposition
1222 type, with "manual-action" and "MDN-sent-manually" or "MDN-sent-
1223 automatically" disposition mode). The MUA remembers that an MDN
1226 -- User possibly performs other actions on message, but no further
1234Hansen & Melnikov Standards Track [Page 22]
1236RFC 8098 MDN February 2017
12395. Conformance and Usage Requirements
1241 An MUA or gateway conforms to this specification if it generates MDNs
1242 according to the protocol defined in this memo. It is not necessary
1243 to be able to generate all of the possible values of the Disposition
1246 MUAs and gateways MUST NOT generate the Original-Recipient field of
1247 an MDN unless the mail protocols provide the address originally
1248 specified by the sender at the time of submission. Ordinary SMTP
1249 does not make that guarantee, but the SMTP extension defined in RFC--
1250 DSN-SMTP [RFC3461] permits such information to be carried in the
1251 envelope if it is available. The Original-Recipient header field
1252 defined in this document provides a way for the MTA to pass the
1253 original recipient address to the MUA.
1255 Each sender-specified recipient address may result in more than one
1256 MDN. If an MDN is requested for a recipient that is forwarded to
1257 multiple recipients of an "alias" (as defined in Section 6.2.7.3 of
1258 RFC-DSN-SMTP [RFC3461]), each of the recipients may issue an MDN.
1260 Successful distribution of a message to a mailing list exploder or
1261 gateway to Usenet newsgroup SHOULD be considered the final
1262 disposition of the message. A mailing list exploder MAY issue an MDN
1263 with a disposition type of "processed" and disposition modes of
1264 "automatic-action" and "MDN-sent-automatically" indicating that the
1265 message has been forwarded to the list. In this case, the request
1266 for MDNs is not propagated to the members of the list.
1268 Alternatively (if successful distribution of a message to a mailing
1269 list exploder / Usenet newsgroup is not considered the final
1270 disposition of the message), the mailing list exploder can issue no
1271 MDN and propagate the request for MDNs to all members of the list.
1272 The latter behavior is not recommended for any but small, closely
1273 knit lists, as it might cause large numbers of MDNs to be generated
1274 and may cause confidential subscribers to the list to be revealed.
1275 The mailing list exploder can also direct MDNs to itself, correlate
1276 them, and produce a report to the original sender of the message.
1278 This specification places no restrictions on the processing of MDNs
1279 received by user agents or mailing lists.
1290Hansen & Melnikov Standards Track [Page 23]
1292RFC 8098 MDN February 2017
12956. Security Considerations
1297 The following security considerations apply when using MDNs.
1301 MDNs can be (and are, in practice) forged as easily as ordinary
1302 Internet electronic mail. User agents and automatic mail handling
1303 facilities (such as mail distribution list exploders) that wish to
1304 make automatic use of MDNs should take appropriate precautions to
1305 minimize the potential damage from denial-of-service attacks.
1307 Security threats related to forged MDNs include the sending of:
1309 a. A falsified disposition notification when the indicated
1310 disposition of the message has not actually occurred, and
1312 b. Unsolicited MDNs.
1314 Similarly, a forged spam or phishing email message can contain
1315 Disposition-Notification-To header field that can trick the recipient
1316 to send an MDN. MDN processing should only be invoked once
1317 authenticity of an email message is verified.
1321 Another dimension of security is privacy. There may be cases in
1322 which a message recipient does not wish the disposition of messages
1323 addressed to him to be known, or is concerned that the sending of
1324 MDNs may reveal other sensitive information (e.g., when the message
1325 was read, using which email client, and which OS was used). In this
1326 situation, it is acceptable for the MUA to silently ignore requests
1329 If the Disposition-Notification-To header field is passed on
1330 unmodified when a message is distributed to the subscribers of a
1331 mailing list, the subscribers to the list may be revealed to the
1332 sender of the original message by the generation of MDNs.
1334 Headers of the original message returned in part 3 of the multipart/
1335 report, as well as content of the message/disposition-notification
1336 part, could reveal confidential information about host names and/or
1337 network topology inside a firewall.
1339 Disposition mode (Section 3.2.6.1) can leak information about
1340 recipient's MUA configuration, in particular, whether MDNs are
1346Hansen & Melnikov Standards Track [Page 24]
1348RFC 8098 MDN February 2017
1351 acknowledged manually or automatically. If this is a concern, MUAs
1352 can return "manual-action/MDN-sent-manually" disposition mode in
1355 In general, any optional MDN field may be omitted if the Reporting
1356 MUA site or user determines that inclusion of the field would impose
1357 too great a compromise of site confidentiality. The need for such
1358 confidentiality must be balanced against the utility of the omitted
1359 information in MDNs.
1361 In some cases, someone with access to the message stream may use the
1362 MDN request mechanism to monitor the mail reading habits of a target.
1363 If the target is known to generate MDN reports, they could add a
1364 Disposition-Notification-To header field containing the envelope from
1365 address. This risk can be minimized by not sending MDN's
13686.2.1. Disclosure of Product Information
1370 The "Reporting-UA" field (Section 3.2.1), User-Agent header field,
1371 and other header fields often reveal information about the respective
1372 sender's software systems. In theory, this can make it easier for an
1373 attacker to exploit known security holes; in practice, attackers tend
1374 to try all potential holes regardless of the apparent software
1375 versions being used. Also note that the "Reporting-UA" field doesn't
1376 provide any new information in comparison to the "User-Agent" and/or
1377 (undocumented) "X-Mailer" header fields used by many MUAs.
13796.2.2. MUA Fingerprinting
1381 The "Reporting-UA" field (Section 3.2.1) might contain enough
1382 information to uniquely identify a specific device, usually when
1383 combined with other characteristics, particularly if the user agent
1384 sends excessive details about the user's system or extensions. Even
1385 when the guidance in Section 3.2.1 is followed to avoid
1386 fingerprinting, other sources of unique information may still be
1387 present, such as the Accept-Language header fields.
1391 MDNs do not provide non-repudiation with proof of delivery. Within
1392 the framework of today's Internet Mail, the MDNs defined in this
1393 document provide valuable information to the mail user; however, MDNs
1394 cannot be relied upon as a guarantee that a message was or was not
1395 seen by the recipient. Even if MDNs are not actively forged, they
1396 may be lost in transit. The recipient may bypass the MDN issuing
1397 mechanism in some manner.
1402Hansen & Melnikov Standards Track [Page 25]
1404RFC 8098 MDN February 2017
1407 One possible solution for this purpose can be found in RFC-SEC-
1412 The MDN request mechanism introduces an additional way of mail
1413 bombing a mailbox. The MDN request notification provides an address
1414 to which MDN's should be sent. It is possible for an attacking agent
1415 to send a potentially large set of messages to otherwise unsuspecting
1416 third party recipients with a false Disposition-Notification-To
1417 address. Automatic or simplistic processing of such requests would
1418 result in a flood of MDN notifications to the target of the attack.
1419 Additionally, as generated MDN notifications can include the full
1420 content of messages that caused them and thus they can be bigger than
1421 such messages, they can be used for bandwidth amplification attacks.
1422 Such an attack could overrun the storage capacity of the targeted
1423 mailbox and/or of the mail transport system, and deny service.
1425 For that reason, MDN's SHOULD NOT be sent automatically where the
1426 Disposition-Notification-To address is different from the SMTP "MAIL
1427 FROM" address (which is carried in the Return-Path header field).
1428 See Section 2.1 for further discussion.
14307. Collected ABNF Grammar
1432 NOTE: The following lexical tokens are defined in RFC-MSGFMT
1433 [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text,
1434 comment, and word. The following lexical tokens are defined in
1435 RFC-SMTP [RFC5321]: Atom. (Note that RFC-MSGFMT [RFC5322] also
1436 defines "atom", but the version from RFC-SMTP [RFC5321] is more
1437 restrictive and this more restrictive version is used in this
1438 document.) The "encoded-word" construct defined in RFC-MIME-HEADER
1439 [RFC2047] is allowed everywhere where RFC-MSGFMT [RFC5322] "comment"
1440 is used, for example, in CFWS.
1443 ; Optional whitespace.
1444 ; MDN generators SHOULD use "*WSP"
1445 ; (Typically a single space or nothing.
1446 ; It SHOULD be nothing at the end of a field.),
1447 ; unless an RFC 5322 "comment" is required.
1449 ; MDN parsers MUST parse it as "[CFWS]".
1451 Message header fields:
1452 mdn-request-header =
1453 "Disposition-Notification-To" ":" mailbox-list CRLF
1458Hansen & Melnikov Standards Track [Page 26]
1460RFC 8098 MDN February 2017
1463 Disposition-Notification-Options =
1464 "Disposition-Notification-Options" ":" [FWS]
1465 disposition-notification-parameter-list CRLF
1467 disposition-notification-parameter-list =
1468 disposition-notification-parameter
1470 disposition-notification-parameter)
1472 disposition-notification-parameter = attribute [FWS] "=" [FWS]
1473 importance [FWS] "," [FWS] value *([FWS] ","
1476 importance = "required" / "optional"
1482 original-recipient-header =
1483 "Original-Recipient" ":" OWS address-type OWS
1484 ";" OWS generic-address OWS CRLF
1487 disposition-notification-content =
1488 [ reporting-ua-field CRLF ]
1489 [ mdn-gateway-field CRLF ]
1490 [ original-recipient-field CRLF ]
1491 final-recipient-field CRLF
1492 [ original-message-id-field CRLF ]
1493 disposition-field CRLF
1494 *( error-field CRLF )
1495 *( extension-field CRLF )
1499 mta-name-type = Atom
1501 reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [
1502 ";" OWS ua-product OWS ]
1504 ua-name = *text-no-semi
1506 ua-product = *([FWS] text)
1508 text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
1509 %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
1514Hansen & Melnikov Standards Track [Page 27]
1516RFC 8098 MDN February 2017
1519 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS
1524 original-recipient-field =
1525 "Original-Recipient" ":" OWS address-type OWS
1526 ";" OWS generic-address OWS
1528 generic-address = *text
1530 final-recipient-field =
1531 "Final-Recipient" ":" OWS address-type OWS
1532 ";" OWS generic-address OWS
1534 original-message-id-field = "Original-Message-ID" ":" msg-id
1537 "Disposition" ":" OWS disposition-mode OWS ";"
1538 OWS disposition-type
1539 [ OWS "/" OWS disposition-modifier
1540 *( OWS "," OWS disposition-modifier ) ] OWS
1542 disposition-mode = action-mode OWS "/" OWS sending-mode
1544 action-mode = "manual-action" / "automatic-action"
1546 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
1548 disposition-type = "displayed" / "deleted" / "dispatched" /
1551 disposition-modifier = "error" / disposition-modifier-extension
1553 disposition-modifier-extension = Atom
1555 error-field = "Error" ":" *([FWS] text)
1557 extension-field = extension-field-name ":" *([FWS] text)
1559 extension-field-name = field-name
1570Hansen & Melnikov Standards Track [Page 28]
1572RFC 8098 MDN February 2017
15758. Guidelines for Gatewaying MDNs
1577 NOTE: This section provides non-binding recommendations for the
1578 construction of mail gateways that wish to provide semi-transparent
1579 disposition notifications between the Internet and another electronic
1580 mail system. Specific MDN gateway requirements for a particular pair
1581 of mail systems may be defined by other documents.
15838.1. Gatewaying from Other Mail Systems to MDNs
1585 A mail gateway may issue an MDN to convey the contents of a "foreign"
1586 disposition notification over Internet Mail. When there are
1587 appropriate mappings from the foreign notification elements to MDN
1588 fields, the information may be transmitted in those MDN fields.
1589 Additional information (such as what might be needed to tunnel the
1590 foreign notification through the Internet) may be defined in
1591 extension MDN fields. (Such fields should be given names that
1592 identify the foreign mail protocol, e.g., X400-* for X.400 protocol
1595 The gateway must attempt to supply reasonable values for the
1596 Reporting-UA, Final-Recipient, and Disposition fields. These will
1597 normally be obtained by translating the values from the foreign
1598 notification into their Internet-style equivalents. However, some
1599 loss of information is to be expected.
1601 The sender-specified recipient address and the original message-id,
1602 if present in the foreign notification, should be preserved in the
1603 Original-Recipient and Original-Message-ID fields.
1605 The gateway should also attempt to preserve the "final" recipient
1606 address from the foreign system. Whenever possible, foreign protocol
1607 elements should be encoded as meaningful printable ASCII strings.
1609 For MDNs produced from foreign disposition notifications, the name of
1610 the gateway MUST appear in the MDN-Gateway field of the MDN.
16128.2. Gatewaying from MDNs to Other Mail Systems
1614 It may be possible to gateway MDNs from the Internet into a foreign
1615 mail system. The primary purpose of such gatewaying is to convey
1616 disposition information in a form that is usable by the destination
1617 system. A secondary purpose is to allow "tunneling" of MDNs through
1618 foreign mail systems in case the MDN may be gatewayed back into the
1626Hansen & Melnikov Standards Track [Page 29]
1628RFC 8098 MDN February 2017
1631 In general, the recipient of the MDN (i.e., the sender of the
1632 original message) will want to know, for each recipient: the closest
1633 available approximation to the original recipient address and the
1634 disposition (displayed, printed, etc.).
1636 If possible, the gateway should attempt to preserve the Original-
1637 Recipient address and Original-Message-ID (if present) in the
1638 resulting foreign disposition report.
1640 If it is possible to tunnel an MDN through the destination
1641 environment, the gateway specification may define a means of
1642 preserving the MDN information in the disposition reports used by
16458.3. Gatewaying of MDN-Requests to Other Mail Systems
1647 By use of the separate Disposition-Notification-To request header
1648 field, this specification offers a richer functionality than most, if
1649 not all, other email systems. In most other email systems, the
1650 notification recipient is identical to the message sender as
1651 indicated in the "from" address. There are two interesting cases
1652 when gatewaying into such systems:
1654 1. If the address in the Disposition-Notification-To header field is
1655 identical to the address in the SMTP "MAIL FROM", the expected
1656 behavior will result, even if the Disposition-Notification-To
1657 information is lost. Systems should propagate the MDN request.
1659 2. If the address in the Disposition-Notification-To header field is
1660 different from the address in the SMTP "MAIL FROM", gatewaying
1661 into a foreign system without a separate notification address
1662 will result in unintended behavior. This is especially important
1663 when the message arrives via a mailing list expansion software
1664 that may specifically replace the SMTP "MAIL FROM" address with
1665 an alternate address. In such cases, the MDN request should not
1666 be gatewayed and should be silently dropped. This is consistent
1667 with other forms of non-support for MDN.
1671 NOTE: This example is provided as illustration only and is not
1672 considered part of the MDN protocol specification. If the example
1673 conflicts with the protocol definition above, the example is wrong.
1675 Likewise, the use of *-type subfield names or extension fields in
1676 this example is not to be construed as a definition for those type
1677 names or extension fields.
1682Hansen & Melnikov Standards Track [Page 30]
1684RFC 8098 MDN February 2017
1687 This is an MDN issued after a message has been displayed to the user
1688 of an Internet Mail user agent.
1690 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
1691 From: Joe Recipient <Joe_Recipient@example.com>
1692 Message-Id: <199509200019.12345@example.com>
1693 Subject: Disposition notification
1694 To: Jane Sender <Jane_Sender@example.org>
1696 Content-Type: multipart/report; report-type=disposition-notification;
1697 boundary="RAA14128.773615765/example.com"
1699 --RAA14128.773615765/example.com
1701 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
1702 Recipient <Joe_Recipient@example.com> with subject "First draft of
1703 report" has been displayed.
1704 This is no guarantee that the message has been read or understood.
1706 --RAA14128.773615765/example.com
1707 Content-Type: message/disposition-notification
1709 Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
1710 Original-Recipient: rfc822;Joe_Recipient@example.com
1711 Final-Recipient: rfc822;Joe_Recipient@example.com
1712 Original-Message-ID: <199509192301.23456@example.org>
1713 Disposition: manual-action/MDN-sent-manually; displayed
1715 --RAA14128.773615765/example.com
1716 Content-Type: message/rfc822
1718 [original message optionally goes here]
1720 --RAA14128.773615765/example.com--
172210. IANA Considerations
1724 IANA has completed the following actions:
1726 1. IANA has updated the registration template for the message/
1727 disposition-notification media type to match what appears in
1728 Section 3.1 of this document and updated the reference for the
1729 media type to point to this document (instead of to RFC 3798).
1731 2. The registries specified here already exist; this section updates
1732 their documentation. IANA has changed the reference document for
1733 the three Message Disposition Notification Parameters registries
1734 to point to this document (instead of to RFC 3798).
1738Hansen & Melnikov Standards Track [Page 31]
1740RFC 8098 MDN February 2017
1743 This document specifies three types of parameters that must be
1744 registered with the Internet Assigned Numbers Authority (IANA). All
1745 of them use the "Specification Required" IANA registration policy
1748 The forms below are for use when registering a new disposition-
1749 notification-parameter name for the Disposition-Notification-Options
1750 header field, a new disposition modifier name, or a new MDN extension
1751 field. Each piece of information required by a registration form may
1752 be satisfied either by providing the information on the form itself
1753 or by including a reference to a published and publicly available
1754 specification that includes the necessary information. IANA MAY
1755 reject registrations because of incomplete registration forms or
1756 incomplete specifications.
1758 To register, complete the following applicable form and send it via
1759 electronic mail to <IANA@IANA.ORG>.
176110.1. Disposition-Notification-Options Header Field
1762 disposition-notification-parameter Names
1764 A registration for a Disposition-Notification-Options header field
1765 disposition-notification-parameter name MUST include the following
1768 a. The proposed disposition-notification-parameter name.
1770 b. The syntax for disposition-notification-parameter values,
1771 specified using BNF, ABNF, regular expressions, or other
1772 non-ambiguous language.
1774 c. If disposition-notification-parameter values are not composed
1775 entirely of graphic characters from the US-ASCII repertoire, a
1776 specification for how they are to be encoded as graphic US-ASCII
1777 characters in a Disposition-Notification-Options header field.
1779 d. A reference to a permanent and readily available public
1780 specification that describes the semantics of the disposition-
1781 notification-parameter values.
1794Hansen & Melnikov Standards Track [Page 32]
1796RFC 8098 MDN February 2017
179910.2. Disposition Modifier Names
1801 A registration for a disposition-modifier name (used in the
1802 Disposition field of a message/disposition-notification) MUST include
1803 the following information:
1805 a. The proposed disposition-modifier name.
1807 b. A reference to a permanent and readily available public
1808 specification that describes the semantics of the disposition
181110.3. MDN Extension Field Names
1813 A registration for an MDN extension-field name MUST include the
1814 following information:
1816 a. The proposed extension field name.
1818 b. The syntax for extension values, specified using BNF, ABNF,
1819 regular expressions, or other non-ambiguous language.
1821 c. If extension-field values are not composed entirely of graphic
1822 characters from the US-ASCII repertoire, a specification for how
1823 they are to be encoded as graphic US-ASCII characters in a
1824 Disposition-Notification-Options header field.
1826 d. A reference to a permanent and readily available public
1827 specification that describes the semantics of the extension
183211.1. Normative References
1834 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1835 DOI 10.17487/RFC5321, October 2008,
1836 <http://www.rfc-editor.org/info/rfc5321>.
1838 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1839 DOI 10.17487/RFC5322, October 2008,
1840 <http://www.rfc-editor.org/info/rfc5322>.
1842 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1843 Extensions (MIME) Part One: Format of Internet Message
1844 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
1845 <http://www.rfc-editor.org/info/rfc2045>.
1850Hansen & Melnikov Standards Track [Page 33]
1852RFC 8098 MDN February 2017
1855 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1856 Extensions (MIME) Part Two: Media Types", RFC 2046,
1857 DOI 10.17487/RFC2046, November 1996,
1858 <http://www.rfc-editor.org/info/rfc2046>.
1860 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
1861 Part Three: Message Header Extensions for Non-ASCII Text",
1862 RFC 2047, DOI 10.17487/RFC2047, November 1996,
1863 <http://www.rfc-editor.org/info/rfc2047>.
1865 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
1866 the Reporting of Mail System Administrative Messages",
1867 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
1868 <http://www.rfc-editor.org/info/rfc6522>.
1870 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
1871 Extension for Delivery Status Notifications (DSNs)",
1872 RFC 3461, DOI 10.17487/RFC3461, January 2003,
1873 <http://www.rfc-editor.org/info/rfc3461>.
1875 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
1876 for Delivery Status Notifications", RFC 3464,
1877 DOI 10.17487/RFC3464, January 2003,
1878 <http://www.rfc-editor.org/info/rfc3464>.
1880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1881 Requirement Levels", BCP 14, RFC 2119,
1882 DOI 10.17487/RFC2119, March 1997,
1883 <http://www.rfc-editor.org/info/rfc2119>.
1885 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
1886 profile for Internet Message Access Protocol (IMAP)",
1887 RFC 3503, DOI 10.17487/RFC3503, March 2003,
1888 <http://www.rfc-editor.org/info/rfc3503>.
189011.2. Informative References
1892 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
1893 RFC 2634, DOI 10.17487/RFC2634, June 1999,
1894 <http://www.rfc-editor.org/info/rfc2634>.
1896 [RFC3249] Cancio, V., Moldovan, M., Tamura, H., and D. Wing,
1897 "Implementers Guide for Facsimile Using Internet Mail",
1898 RFC 3249, DOI 10.17487/RFC3249, September 2002,
1899 <http://www.rfc-editor.org/info/rfc3249>.
1906Hansen & Melnikov Standards Track [Page 34]
1908RFC 8098 MDN February 2017
1911 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1912 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
1913 <http://www.rfc-editor.org/info/rfc3501>.
1915 [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
1916 Mail - version 2 (VPIMv2)", RFC 3801,
1917 DOI 10.17487/RFC3801, June 2004,
1918 <http://www.rfc-editor.org/info/rfc3801>.
1920 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress
1921 Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008,
1922 <http://www.rfc-editor.org/info/rfc5233>.
1924 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1925 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1926 DOI 10.17487/RFC5226, May 2008,
1927 <http://www.rfc-editor.org/info/rfc5226>.
1929 [RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and
1930 Extended Reject Extensions", RFC 5429,
1931 DOI 10.17487/RFC5429, March 2009,
1932 <http://www.rfc-editor.org/info/rfc5429>.
1934 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1935 DOI 10.17487/RFC5598, July 2009,
1936 <http://www.rfc-editor.org/info/rfc5598>.
1938 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov,
1939 "Internationalized Delivery Status and Disposition
1940 Notifications", RFC 6533, DOI 10.17487/RFC6533, February
1941 2012, <http://www.rfc-editor.org/info/rfc6533>.
1943 [X.400] International Telecommunications Union, "Message handling
1944 system and service overview", ITU-T Recommendation
1945 F.400/X.400, June 1999.
1962Hansen & Melnikov Standards Track [Page 35]
1964RFC 8098 MDN February 2017
1967Appendix A. Changes from RFC 3798
1969 Changed IANA registration for different subregistries to
1970 "Specification Required" to match what is already used by IANA.
1972 Updated IANA registration template for message/disposition-
1975 "X-" fields no longer reserved for experimental use and can now be
1976 registered in compliance with RFC 6648.
1978 Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns".
1980 Strengthen requirements on obtaining user consent in order to protect
1983 Removed discussion of using source routes with MDNs, as source route
1984 is a deprecated Email feature.
1986 The values of "dispatched" and "processed" were lost from the ABNF
1987 for "disposition-type". (Erratum #691)
1989 Because the warning disposition modifier was previously removed, the
1990 warning-field has also been removed. (Erratum #692)
1992 Because the failed disposition type was previously removed, the
1993 failure-field has also been removed.
1995 The ABNF for ua-name and ua-product included a semi-colon, which
1996 could not be distinguished from *text in the production. The ua-name
1997 was restricted to not include semi-colon. Semi-colon can still
1998 appear in the ua-product.
2000 Removed recommendation to include the MUA DNS host name in the
2001 "Reporting-UA" MDN field.
2003 The ABNF did not indicate all places that whitespace was allowable,
2004 in particular folding whitespace, although all implementations allow
2005 whitespace and folding in the header fields just like any other
2006 header field formatted as described in RFC-MSGFMT [RFC5322]. There
2007 were also a number of places in the ABNF that inconsistently
2008 permitted comments and whitespace in one leg of the production and
2009 not another. The ABNF now specifies FWS and CFWS in several places
2010 that should have already been specified by the grammar.
2012 Extension-field was defined in the collected grammar but not in the
2018Hansen & Melnikov Standards Track [Page 36]
2020RFC 8098 MDN February 2017
2023 The comparison of mailboxes in Disposition-Notification-To to the
2024 Return-Path addr-spec was clarified.
2026 The use of the grammar production "parameter" was confusing with the
2027 RFC 2045 [RFC2045] production of the same name, as well as other uses
2028 of the same term. These have been clarified.
2030 A clarification was added on the extent of the 7bit nature of MDNs.
2032 Uses of the terms "may" and "might" were clarified.
2034 A clarification was added on the order of the fields in the message/
2035 disposition-notification content.
2039 The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben
2040 Campbell, Pete Resnick, Donald Eastlake, and Alissa Cooper are
2041 gratefully acknowledged for this revision.
2043 The contributions of Roger Fajman and Greg Vaudreuil to earlier draft
2044 versions of this document are also gratefully acknowledged.
2048 Tony Hansen (editor)
2050 200 Laurel Ave. South
2051 Middletown, NJ 07748
2052 United States of America
2057 Alexey Melnikov (editor)
2060 Hampton, Middlesex TW12 2NP
2063 Email: Alexey.Melnikov@isode.com
2074Hansen & Melnikov Standards Track [Page 37]