idnits 2.17.1 draft-ietf-appsawg-mdn-3798bis-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 16 characters in excess of 72. -- The draft header indicates that this document updates RFC3461, but the abstract doesn't seem to directly say this. It does mention RFC3461 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2046, updated by this document, for RFC5378 checks: 1995-04-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2016) is 2747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FWS' is mentioned on line 1113, but not defined == Missing Reference: 'CFWS' is mentioned on line 378, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 534, but not defined -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen, Ed. 3 Internet-Draft AT&T Laboratories 4 Obsoletes: 3798 (if approved) A. Melnikov, Ed. 5 Updates: 2046, 3461 (if approved) Isode Ltd 6 Intended status: Standards Track October 16, 2016 7 Expires: April 19, 2017 9 Message Disposition Notification 10 draft-ietf-appsawg-mdn-3798bis-13.txt 12 Abstract 14 This memo defines a MIME content-type that may be used by a mail user 15 agent (MUA) or electronic mail gateway to report the disposition of a 16 message after it has been successfully delivered to a recipient. 17 This content-type is intended to be machine-processable. Additional 18 message header fields are also defined to permit Message Disposition 19 Notifications (MDNs) to be requested by the sender of a message. The 20 purpose is to extend Internet Mail to support functionality often 21 found in other messaging systems, such as X.400 and the proprietary 22 "LAN-based" systems, and often referred to as "read receipts," 23 "acknowledgements", or "receipt notifications." The intention is to 24 do this while respecting privacy concerns, which have often been 25 expressed when such functions have been discussed in the past. 27 Because many messages are sent between the Internet and other 28 messaging systems (such as X.400 or the proprietary "LAN-based" 29 systems), the MDN protocol is designed to be useful in a multi- 30 protocol messaging environment. To this end, the protocol described 31 in this memo provides for the carriage of "foreign" addresses, in 32 addition to those normally used in Internet Mail. Additional 33 attributes may also be defined to support "tunneling" of foreign 34 notifications through Internet Mail. 36 This document obsoletes RFC 3798, moving it to Internet Standard. It 37 also updates RFC 2046 (message/partial Media Type handling) and RFC 38 3461 (Original-Recipient header field generation requirement). 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 19, 2017. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 77 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Requesting Message Disposition Notifications . . . . . . . . 5 79 2.1. The Disposition-Notification-To Header . . . . . . . . . 5 80 2.2. The Disposition-Notification-Options Header . . . . . . . 7 81 2.3. The Original-Recipient Header Field . . . . . . . . . . . 8 82 2.4. Use with the Message/Partial Media Type . . . . . . . . . 9 83 3. Format of a Message Disposition Notification . . . . . . . . 10 84 3.1. The message/disposition-notification Media Type . . . . . 11 85 3.2. Message/disposition-notification Content Fields . . . . . 14 86 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 20 87 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 21 88 5. Conformance and Usage Requirements . . . . . . . . . . . . . 22 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 24 93 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 24 94 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 25 95 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 27 96 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 27 97 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 28 98 8.3. Gatewaying of MDN-requests to other mail systems . . . . 28 99 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 101 10.1. Disposition-Notification-Options header field 102 disposition-notification-parameter names . . . . . . . . 31 103 10.2. Disposition modifier names . . . . . . . . . . . . . . . 32 104 10.3. MDN extension field names . . . . . . . . . . . . . . . 32 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 108 12.2. Informative References . . . . . . . . . . . . . . . . . 34 109 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 35 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 112 1. Introduction 114 This memo defines a media type [RFC2046] for message disposition 115 notifications (MDNs). An MDN can be used to notify the sender of a 116 message of any of several conditions that may occur after successful 117 delivery, such as display of the message contents, printing of the 118 message, deletion (without display) of the message, or the 119 recipient's refusal to provide MDNs. The "message/disposition- 120 notification" content-type defined herein is intended for use within 121 the framework of the "multipart/report" content type defined in RFC- 122 REPORT [RFC6522]. 124 This memo defines the format of the notifications and the RFC-MSGFMT 125 [RFC5322] header fields used to request them. 127 This memo is an update to RFC 3798 and is intended to be published at 128 Internet Standard Level. 130 1.1. Purposes 132 The MDNs defined in this memo are expected to serve several purposes: 134 a. Inform human beings of the disposition of messages after 135 successful delivery, in a manner that is largely independent of 136 human language; 138 b. Allow mail user agents to keep track of the disposition of 139 messages sent, by associating returned MDNs with earlier message 140 transmissions; 142 c. Convey disposition notification requests and disposition 143 notifications between Internet Mail and "foreign" mail systems 144 via a gateway; 146 d. Allow "foreign" notifications to be tunneled through a MIME- 147 capable message system and back into the original messaging 148 system that issued the original notification, or even to a third 149 messaging system; 151 e. Allow language-independent, yet reasonably precise, indications 152 of the disposition of a message to be delivered. 154 1.2. Requirements 156 These purposes place the following constraints on the notification 157 protocol: 159 a. It must be readable by humans, and must be machine-parsable. 161 b. It must provide enough information to allow message senders (or 162 their user agents) to unambiguously associate an MDN with the 163 message that was sent and the original recipient address for 164 which the MDN was issued (if such information is available), even 165 if the message was forwarded to another recipient address. 167 c. It must also be able to describe the disposition of a message 168 independent of any particular human language or of the 169 terminology of any particular mail system. 171 d. The specification must be extensible in order to accommodate 172 future requirements. 174 1.3. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC-KEYWORDS 179 [RFC2119]. 181 All syntax descriptions use the ABNF specified by RFC-MSGFMT 182 [RFC5322], in which the lexical tokens (used below) are defined: 183 "CRLF", "FWS", "CFWS", "field-name", "mailbox-list", "msg-id", and 184 "text". The following lexical tokens are defined in RFC-SMTP 185 [RFC5321]: "atom". 187 2. Requesting Message Disposition Notifications 189 Message disposition notifications are requested by including a 190 Disposition-Notification-To header field in the message containing 191 one or more addresses specifying where dispositions should be sent. 192 Further information to be used by the recipient's Mail User Agent 193 (MUA) [RFC5598] in generating the MDN may be provided by also 194 including Original-Recipient and/or Disposition-Notification-Options 195 header fields in the message. 197 2.1. The Disposition-Notification-To Header 199 A request for the receiving user agent to issue message disposition 200 notifications is made by placing a Disposition-Notification-To header 201 field into the message. The syntax of the header field is 203 mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF 205 A Disposition-Notification-To header field can appear at most once in 206 a message. 208 The presence of a Disposition-Notification-To header field in a 209 message is merely a request for an MDN. The recipients' user agents 210 are always free to silently ignore such a request. 212 An MDN MUST NOT itself have a Disposition-Notification-To header 213 field. An MDN MUST NOT be generated in response to an MDN. 215 A user agent MUST NOT issue more than one MDN on behalf of each 216 particular recipient. That is, once an MDN has been issued on behalf 217 of a recipient, no further MDNs may be issued on behalf of that 218 recipient by the same user agent, even if another disposition is 219 performed on the message. However, if a message is forwarded, an MDN 220 may have been issued for the recipient doing the forwarding and the 221 recipient of the forwarded message may also cause an MDN to be 222 generated. 224 It is also possible that if the same message is being accessed by 225 multiple user agents (for example using POP3), then multiple 226 dispositions might be generated for the same recipient. User agents 227 SHOULD leverage support in the underlying message access protocol to 228 prevent multiple MDNs from being generated. In particular, when the 229 user agent is accessing the message using RFC-IMAP [RFC3501], it 230 SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503]. 232 While Internet standards normally do not specify the behavior of user 233 interfaces, it is strongly recommended that the user agent obtain the 234 user's consent before sending an MDN. This consent could be obtained 235 for each message through some sort of prompt or dialog box, or 236 globally through the user's setting of a preference. The user might 237 also indicate globally that MDNs are to never be sent. The purpose 238 of obtaining user's consent is to protect user's privacy. The 239 default value should be not to send MDNs. 241 MDNs MUST NOT be sent automatically if the address in the 242 Disposition-Notification-To header field differs from the address in 243 the Return-Path header field (see RFC-MSGFMT [RFC5322]). In this 244 case, confirmation from the user MUST be obtained, if possible. If 245 obtaining consent is not possible (e.g., because the user is not 246 online at the time or the client is not an interactive email client), 247 then an MDN MUST NOT be sent. 249 Confirmation from the user MUST be obtained (or no MDN sent) if there 250 is no Return-Path header field in the message, or if there is more 251 than one distinct address in the Disposition-Notification-To header 252 field. 254 The comparison of the addresses is done using only the addr-spec 255 (local-part "@" domain) portion, excluding any angle brackets, phrase 256 and route. As prescribed by RFC 5322, the comparison is case- 257 sensitive for the local-part and case-insensitive for the domain 258 part. The local-part comparison SHOULD be done after performing 259 local-part canonicalization (i.e. after removing the surrounding 260 double-quote characters, if any, as well as any escaping "\" 261 characters. (See RFC-MSGFMT [RFC5322] for more details.) 262 Implementations MAY treat known domain aliases as equivalent for the 263 purpose of comparison. 265 Note that use of subaddressing (see [RFC5233]) can result in a 266 failure to match two local-parts and thus result in possible 267 suppression of the MDN. This document doesn't recommend special 268 handling for this case, as the receiving MUA can't reliably know 269 whether or not the sender is using subaddressing. 271 If the message contains more than one Return-Path header field, the 272 implementation may pick one to use for the comparison, or treat the 273 situation as a failure of the comparison. 275 The reason for not automatically sending an MDN if the comparison 276 fails or more than one address is specified is to reduce the 277 possibility of mail loops and of MDNs being used for mail bombing. 279 It's especially important that a message that contains a Disposition- 280 Notification-To header field also contain a Message-ID header field, 281 to permit user agents to automatically correlate MDNs with their 282 original messages. 284 If the request for message disposition notifications for some 285 recipients and not others is desired, two copies of the message 286 should be sent, one with a Disposition-Notification-To header field 287 and one without. Many of the other header fields of the message 288 (e.g., To, Cc) will be the same in both copies. The recipients in 289 the respective message envelopes determine from whom message 290 disposition notifications are requested and from whom they are not. 291 If desired, the Message-ID header field may be the same in both 292 copies of the message. Note that there are other situations (e.g., 293 Bcc) in which it is necessary to send multiple copies of a message 294 with slightly different header fields. The combination of such 295 situations and the need to request MDNs for a subset of all 296 recipients may result in more than two copies of a message being 297 sent, some with a Disposition-Notification-To header field and some 298 without. 300 If it is possible to determine that a recipient is a newsgroup, do 301 not include a Disposition-Notification-To header field for that 302 recipient. Similarly, if an existing message is resent or gatewayed 303 to a newsgroup, the agent doing resending/gatewaying SHOULD strip the 304 Disposition-Notification-To header field. See Section 5 for more 305 discussion. Clients that see an otherwise valid Disposition- 306 Notification-To header field in a newsgroup message SHOULD NOT 307 generate an MDN. 309 2.2. The Disposition-Notification-Options Header 311 Extensions to this specification may require that information be 312 supplied to the recipient's MUA for additional control over how and 313 what MDNs are generated. The Disposition-Notification-Options header 314 field provides an extensible mechanism for such information. The 315 syntax of this header field is as follows: 317 Disposition-Notification-Options = 318 "Disposition-Notification-Options" ":" [FWS] 319 disposition-notification-parameter-list CRLF 321 disposition-notification-parameter-list = 322 disposition-notification-parameter 323 *([FWS] ";" [FWS] disposition-notification-parameter) 325 disposition-notification-parameter = attribute [FWS] "=" 326 [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) 328 importance = "required" / "optional" 330 attribute = atom 332 value = word 334 A Disposition-Notification-Options header field can appear at most 335 once in a message. 337 An importance of "required" indicates that interpretation of the 338 disposition-notification-parameter is necessary for proper generation 339 of an MDN in response to this request. An importance of "optional" 340 indicates that an MUA that does not understand the meaning of this 341 disposition-notification-parameter MAY generate an MDN in response 342 anyway, ignoring the value of the disposition-notification-parameter. 344 No disposition-notification-parameter attribute names are defined in 345 this specification. Attribute names may be defined in the future by 346 later revisions or extensions to this specification. disposition- 347 notification-parameter attribute names MUST be registered with the 348 Internet Assigned Numbers Authority (IANA) using "Specification 349 required" registration policy. The "X-" prefix has historically been 350 used to denote unregistered "experimental" protocol elements, that 351 are assumed not to become common use. Deployment experience of this 352 and other protocols have shown that this assumption is often false. 353 This document allows the use of the "X-" prefix primarily to allow 354 the registration of attributes that are already in common use. The 355 prefix has no meaning for new attributes. Its use in substantially 356 new attributes may cause confusion and is therefore discouraged. 357 (See Section 10 for a registration form.) 359 2.3. The Original-Recipient Header Field 361 Since electronic mail addresses may be rewritten while the message is 362 in transit, it is useful for the original recipient address to be 363 made available by the delivering Message Transfer Agent (MTA) 364 [RFC5598]. The delivering MTA may be able to obtain this information 365 from the ORCPT parameter of the SMTP RCPT TO command, as defined in 366 RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461]. 368 RFC-DSN-SMTP [RFC3461] is amended as follows: If the ORCPT 369 information is available, the delivering MTA SHOULD insert an 370 Original-Recipient header field at the beginning of the message 371 (along with the Return-Path header field). The delivering MTA MAY 372 delete any other Original-Recipient header fields that occur in the 373 message. The syntax of this header field is as follows: 375 original-recipient-header = 376 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 378 OWS = [CFWS] 379 ; Optional whitespace. 380 ; MDN generators SHOULD use "*WSP" 381 ; (typically a single space or nothing. 382 ; It SHOULD be nothing at the end of a field), 383 ; unless an RFC 5322 "comment" is required. 384 ; 385 ; MDN parsers MUST parse it as "[CFWS]". 387 The address-type and generic-address token are as specified in the 388 description of the Original-Recipient field in Section 3.2.3. 390 The purpose of carrying the original recipient information and 391 returning it in the MDN is to permit automatic correlation of MDNs 392 with the original message on a per-recipient basis. 394 2.4. Use with the Message/Partial Media Type 396 The use of the header fields Disposition-Notification-To, 397 Disposition-Notification-Options, and Original-Recipient with the 398 MIME message/partial content type (RFC-MIME-MEDIA [RFC2046]]) 399 requires further definition. 401 When a message is segmented into two or more message/partial 402 fragments, the three header fields mentioned in the above paragraph 403 SHOULD be placed in the "inner" or "enclosed" message (using the 404 terms of RFC-MIME-MEDIA [RFC2046]). If these header fields are found 405 in the header fields of any of the fragments, they are ignored. 407 When the multiple message/partial fragments are reassembled, the 408 following applies. If these header fields occur along with the other 409 header fields of a message/partial fragment message, they pertain to 410 an MDN that will be generated for the fragment. If these header 411 fields occur in the header fields of the "inner" or "enclosed" 412 message (using the terms of RFC-MIME-MEDIA [RFC2046]), they pertain 413 to an MDN that will be generated for the reassembled message. 414 Section 5.2.2.1 of RFC-MIME-MEDIA [RFC2046]) is amended to specify 415 that, in addition to the header fields specified there, the three 416 header fields described in this specification are to be appended, in 417 order, to the header fields of the reassembled message. Any 418 occurrences of the three header fields defined here in the header 419 fields of the initial enclosing message MUST NOT be copied to the 420 reassembled message. 422 3. Format of a Message Disposition Notification 424 A message disposition notification is a MIME message with a top-level 425 content-type of multipart/report (defined in RFC-REPORT [RFC6522]). 426 When multipart/report content is used to transmit an MDN: 428 a. The report-type parameter of the multipart/report content is 429 "disposition-notification". 431 b. The first component of the multipart/report contains a human- 432 readable explanation of the MDN, as described in RFC-REPORT 433 [RFC6522]. 435 c. The second component of the multipart/report is of content-type 436 message/disposition-notification, described in Section 3.1 of 437 this document. 439 d. If the original message or a portion of the message is to be 440 returned to the sender, it appears as the third component of the 441 multipart/report. The decision of whether or not to return the 442 message or part of the message is up to the MUA generating the 443 MDN. However, in the case of encrypted messages requesting MDNs, 444 encrypted message text MUST be returned, if it is returned at 445 all, only in its original encrypted form. 447 NOTE: For message disposition notifications gatewayed from foreign 448 systems, the header fields of the original message may not be 449 available. In this case, the third component of the MDN may be 450 omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header 451 fields that contain equivalent information. In particular, it is 452 very desirable to preserve the subject and date fields from the 453 original message. 455 The MDN MUST be addressed (in both the message header field and the 456 transport envelope) to the address(es) from the Disposition- 457 Notification-To header field from the original message for which the 458 MDN is being generated. 460 The From header field of the MDN MUST contain the address of the 461 person for whom the message disposition notification is being issued. 463 The envelope sender address (i.e., SMTP "MAIL FROM") of the MDN MUST 464 be null (<>), specifying that no Delivery Status Notification 465 messages nor other messages indicating successful or unsuccessful 466 delivery are to be sent in response to an MDN. 468 A message disposition notification MUST NOT itself request an MDN. 469 That is, it MUST NOT contain a Disposition-Notification-To header 470 field. 472 The Message-ID header field (if present) for an MDN MUST be different 473 from the Message-ID of the message for which the MDN is being issued. 475 A particular MDN describes the disposition of exactly one message for 476 exactly one recipient. Multiple MDNs may be generated as a result of 477 one message submission, one per recipient. However, due to the 478 circumstances described in Section 2.1, it's possible that some of 479 the recipients for whom MDNs were requested will not generate MDNs. 481 3.1. The message/disposition-notification Media Type 483 The message/disposition-notification Media Type is defined as 484 follows: 486 Type name: message 488 Subtype name: disposition-notification 490 Required parameters: none 492 Optional parameters: none 494 Encoding considerations: "7bit" encoding is sufficient and MUST be 495 used to maintain readability when viewed by non- 496 MIME mail readers. 498 Security considerations: discussed in Section 6 of [RFCXXXX]. 500 Interoperability considerations: none 502 Published specification: [RFCXXXX] 504 Applications that use this media type: Mail Transfer Agents and 505 email clients that support multipart/report 506 generation and/or parsing. 508 Fragment identifier considerations: N/A 510 Additional information: 512 Deprecated alias names for this type: N/A 514 Magic number(s): none 516 File extension(s): .disposition-notification 518 Macintosh file type code(s): The 'TEXT' type 519 code is suggested as files of this type are 520 typically used for diagnostic purposes and 521 suitable for analysis in a text editor. A 522 uniform type identifier (UTI) of "public.utf8- 523 email-message-header" is suggested. This type 524 conforms to "public.plain-text". 526 Person & email address to contact for further information: See the 527 Authors' Addresses section of [RFCXXXX] 529 Intended usage: COMMON 531 Restrictions on usage: This media type contains textual data in the 532 US-ASCII charset, which is always 7-bit. 534 Author: See the Authors' Addresses section of [RFCXXXX] 536 Change controller: IETF 538 Provisional registration? no 539 (While the 7bit restriction applies to the message/disposition- 540 notification portion of the multipart/report content, it does not 541 apply to the optional third portion of the multipart/report content.) 543 The message/disposition-notification report type for use in the 544 multipart/report is "disposition-notification". 546 The body of a message/disposition-notification consists of one or 547 more "fields" formatted according to the ABNF of RFC-MSGFMT [RFC5322] 548 header "fields". The syntax of the message/disposition-notification 549 content is as follows: 551 disposition-notification-content = [ reporting-ua-field CRLF ] 552 [ mdn-gateway-field CRLF ] 553 [ original-recipient-field CRLF ] 554 final-recipient-field CRLF 555 [ original-message-id-field CRLF ] 556 disposition-field CRLF 557 *( failure-field CRLF ) 558 *( error-field CRLF ) 559 *( extension-field CRLF ) 561 extension-field = extension-field-name ":" *([FWS] text) 563 extension-field-name = field-name 565 Note that the order of the above fields is recommended, but not 566 fixed. Extension fields can appear anywhere. 568 3.1.1. General conventions for fields 570 Since these fields are defined according to the rules of RFC-MSGFMT 571 [RFC5322], the same conventions for continuation lines and comments 572 apply. Notification fields may be continued onto multiple lines by 573 beginning each additional line with a SPACE or HTAB. Text that 574 appears in parentheses is considered a comment and not part of the 575 contents of that notification field. Field names are case- 576 insensitive, so the names of notification fields may be spelled in 577 any combination of upper and lower case letters. [RFC5322] comments 578 in notification fields may use the "encoded-word" construct defined 579 in RFC-MIME-HEADER [RFC2047]. 581 3.1.2. "*-type" subfields 583 Several fields consist of a "-type" subfield, followed by a semi- 584 colon, followed by "*text". 586 For these fields, the keyword used in the address-type or MTA-type 587 subfield indicates the expected format of the address or MTA-name 588 that follows. 590 The "-type" subfields are defined as follows: 592 a. An "address-type" specifies the format of a mailbox address. For 593 example, Internet Mail addresses use the "rfc822" address-type. 594 Other values can appear in this field as specified in the 595 "Address Types" IANA subregistry established by RFC-DSN-FORMAT 596 [RFC3464]. 598 address-type = atom 600 atom = 602 b. An "MTA-name-type" specifies the format of a mail transfer agent 603 name. For example, for an SMTP server on an Internet host, the 604 MTA name is the domain name of that host, and the "dns" MTA-name- 605 type is used. Other values can appear in this field as specified 606 in the "MTA Name Types" IANA subregistry established by RFC-DSN- 607 FORMAT [RFC3464]. 609 mta-name-type = atom 611 Values for address-type and mta-name-type are case-insensitive. 612 Thus, address-type values of "RFC822" and "rfc822" are equivalent. 614 The Internet Assigned Numbers Authority (IANA) maintains a registry 615 of address-type and mta-name-type values, along with descriptions of 616 the meanings of each, or a reference to one or more specifications 617 that provide such descriptions. (The "rfc822" address-type is 618 defined in RFC-DSN-SMTP [RFC3461].) Registration forms for address- 619 type and mta-name-type appear in RFC-DSN-FORMAT [RFC3464]. 621 3.2. Message/disposition-notification Content Fields 623 3.2.1. The Reporting-UA field 624 reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] 626 ua-name = *text-no-semi 628 ua-product = *([FWS] text) 630 text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, 631 %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon 633 The Reporting-UA field is defined as follows: 635 An MDN describes the disposition of a message after it has been 636 delivered to a recipient. In all cases, the Reporting-UA is the MUA 637 that performed the disposition described in the MDN. 639 If the reporting MUA consists of more than one component (e.g., a 640 base program and plug-ins), this may be indicated by including a list 641 of product names. 643 Example: 645 Reporting-UA: Foomail 97.1 647 This field is optional, but recommended. 649 3.2.2. The MDN-Gateway field 651 The MDN-Gateway field indicates the name of the gateway or MTA that 652 translated a foreign (non-Internet) message disposition notification 653 into this MDN. This field MUST appear in any MDN that was translated 654 by a gateway from a foreign system into MDN format, and MUST NOT 655 appear otherwise. 657 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name OWS 659 mta-name = *text 661 For gateways into Internet Mail, the MTA-name-type will normally be 662 "dns", and the mta-name will be the Internet domain name of the 663 gateway. 665 3.2.3. Original-Recipient field 667 The Original-Recipient field indicates the original recipient address 668 as specified by the sender of the message for which the MDN is being 669 issued. For Internet Mail messages, the value of the Original- 670 Recipient field is obtained from the Original-Recipient header field 671 from the message for which the MDN is being generated. If there is 672 an Original-Recipient header field in the message, or if information 673 about the original recipient is reliably available some other way, 674 then the Original-Recipient field MUST be included. Otherwise, the 675 Original-Recipient field MUST NOT be included. If there is more than 676 one Original-Recipient header field in the message, the MUA may 677 choose the one to use, or act as if no Original-Recipient header 678 field is present. 680 original-recipient-field = 681 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 683 generic-address = *text 685 The address-type field indicates the type of the original recipient 686 address. If the message originated within the Internet, the address- 687 type field will normally be "rfc822", and the address will be 688 according to the syntax specified in RFC-MSGFMT [RFC5322]. The value 689 "unknown" should be used if the Reporting MUA cannot determine the 690 type of the original recipient address from the message envelope. 691 This address is the same as that provided by the sender and can be 692 used to automatically correlate MDN reports with original messages on 693 a per recipient basis. 695 3.2.4. Final-Recipient field 697 The Final-Recipient field indicates the recipient for which the MDN 698 is being issued. This field MUST be present. 700 The syntax of the field is as follows: 702 final-recipient-field = 703 "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 705 The generic-address subfield of the Final-Recipient field MUST 706 contain the mailbox address of the recipient (from the From header 707 field of the MDN) as it was when the MDN was generated by the MUA. 709 The Final-Recipient address may differ from the address originally 710 provided by the sender, because it may have been transformed during 711 forwarding and gatewaying into a totally unrecognizable mess. 712 However, in the absence of the optional Original-Recipient field, the 713 Final-Recipient field and any returned content may be the only 714 information available with which to correlate the MDN with a 715 particular message recipient. 717 The address-type subfield indicates the type of address expected by 718 the reporting MTA in that context. Recipient addresses obtained via 719 SMTP will normally be of address-type "rfc822", but can be other 720 values from the "Address Types" subregistry of the "Delivery Status 721 Notification (DSN) Types" IANA registry. 723 Since mailbox addresses (including those used in the Internet) may be 724 case sensitive, the case of alphabetic characters in the address MUST 725 be preserved. 727 3.2.5. Original-Message-ID field 729 The Original-Message-ID field indicates the message-ID of the message 730 for which the MDN is being issued. It is obtained from the Message- 731 ID header field of the message for which the MDN is issued. This 732 field MUST be present if and only if the original message contained a 733 Message-ID header field. The syntax of the field is as follows: 735 original-message-id-field = 736 "Original-Message-ID" ":" msg-id 738 The msg-id token is as specified in RFC-MSGFMT [RFC5322]. 740 3.2.6. Disposition field 742 The Disposition field indicates the action performed by the 743 Reporting-MUA on behalf of the user. This field MUST be present. 745 The syntax for the Disposition field is: 747 disposition-field = 748 "Disposition" ":" OWS disposition-mode OWS ";" 749 OWS disposition-type 750 [ OWS "/" OWS disposition-modifier 751 *( OWS "," OWS disposition-modifier ) ] OWS 753 disposition-mode = action-mode OWS "/" OWS sending-mode 755 action-mode = "manual-action" / "automatic-action" 757 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 759 disposition-type = "displayed" / "deleted" / "dispatched" / 760 "processed" 762 disposition-modifier = "error" / disposition-modifier-extension 764 disposition-modifier-extension = atom 765 The disposition-mode, disposition-type, and disposition-modifier 766 values may be spelled in any combination of upper and lower case US- 767 ASCII characters. 769 3.2.6.1. Disposition modes 771 Disposition mode consists of 2 parts: action mode and sending mode. 773 The following action modes are defined: 775 "manual-action" The disposition described by the disposition type 776 was a result of an explicit instruction by the 777 user rather than some sort of automatically 778 performed action. (This might include the case 779 when the user has manually configured her MUA to 780 automatically respond to valid MDN requests.) 781 Unless prescribed otherwise in a particular mail 782 environment, in order to preserve user's privacy, 783 this MUST be the default for MUAs. 785 "automatic-action" The disposition described by the disposition type 786 was a result of an automatic action, rather than 787 an explicit instruction by the user for this 788 message. This is typically generated by a Mail 789 Delivery Agent (e.g. MDN generations by Sieve 790 reject action [RFC5429], Fax-over-Email 791 [RFC3249], Voice Messaging System (VPIM) 792 [RFC3801] or upon delivery to a mailing list). 794 "Manual-action" and "automatic-action" are mutually exclusive. One 795 or the other MUST be specified. 797 The following sending modes are defined: 799 "MDN-sent-manually" The user explicitly gave permission for this 800 particular MDN to be sent. Unless prescribed 801 otherwise in a particular mail environment, in 802 order to preserve user's privacy, this MUST be 803 the default for MUAs. 805 "MDN-sent-automatically" The MDN was sent because the MUA had 806 previously been configured to do so 807 automatically. 809 "MDN-sent-manually" and "MDN-sent-automatically" are mutually 810 exclusive. One or the other MUST be specified. 812 3.2.6.2. Disposition types 814 The following disposition-types are defined: 816 "displayed" The message has been displayed by the MUA to 817 someone reading the recipient's mailbox. There 818 is no guarantee that the content has been read or 819 understood. 821 "dispatched" The message has been sent somewhere in some 822 manner (e.g., printed, faxed, forwarded) without 823 necessarily having been previously displayed to 824 the user. The user may or may not see the 825 message later. 827 "processed" The message has been processed in some manner 828 (i.e., by some sort of rules or server) without 829 being displayed to the user. The user may or may 830 not see the message later, or there may not even 831 be a human user associated with the mailbox. 833 "deleted" The message has been deleted. The recipient may 834 or may not have seen the message. The recipient 835 might "undelete" the message at a later time and 836 read the message. 838 3.2.6.3. Disposition modifiers 840 Only the extension disposition modifiers is defined: 842 disposition-modifier-extension 843 Disposition modifiers may be defined in the 844 future by later revisions or extensions to this 845 specification. MDN disposition value names MUST 846 be registered with the Internet Assigned Numbers 847 Authority (IANA) using "Specification required" 848 registration policy. (See Section 10 for a 849 registration form.) MDNs with disposition 850 modifier names not understood by the receiving 851 MUA MAY be silently ignored or placed in the 852 user's mailbox without special interpretation. 853 They MUST NOT cause any error message to be sent 854 to the sender of the MDN. 856 It is not required that an MUA be able to generate all of the 857 possible values of the Disposition field. 859 A user agent MUST NOT issue more than one MDN on behalf of each 860 particular recipient. That is, once an MDN has been issued on behalf 861 of a recipient, no further MDNs may be issued on behalf of that 862 recipient, even if another disposition is performed on the message. 863 However, if a message is forwarded, a "dispatched" MDN MAY be issued 864 for the recipient doing the forwarding and the recipient of the 865 forwarded message may also cause an MDN to be generated. 867 3.2.7. Error Field 869 The Error field is used to supply additional information in the form 870 of text messages when the "error" disposition modifier appear. The 871 syntax is as follows: 873 error-field = "Error" ":" *([FWS] text) 875 Note that syntax of these header fields doesn't include comments, so 876 "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't 877 be used to convey non ASCII text. Application that need to convey 878 non ASCII text in these fields should consider implementing message/ 879 global-disposition-notification media type specified in [RFC6533] 880 instead of this specification. 882 3.3. Extension-fields 884 Additional MDN fields may be defined in the future by later revisions 885 or extensions to this specification. MDN field names MUST be 886 registered with the Internet Assigned Numbers Authority (IANA) using 887 "Specification required" registration policy. (See Section 10 for a 888 registration form.) MDN Extension-fields may be defined for the 889 following reasons: 891 a. To allow additional information from foreign disposition reports 892 to be tunneled through Internet MDNs. The names of such MDN 893 fields should begin with an indication of the foreign environment 894 name (e.g., X400-Physical-Forwarding-Address). 896 b. To allow transmission of diagnostic information that is specific 897 to a particular mail user agent (MUA). The names of such MDN 898 fields should begin with an indication of the MUA implementation 899 that produced the MDN (e.g., Foomail-information). 901 4. Timeline of events 903 The following timeline shows when various events in the processing of 904 a message and generation of MDNs take place: 906 -- User composes message 908 -- User tells MUA to send message. 910 -- MUA passes message to Mail Submission Agent (MSA), original 911 recipient information passed along. 913 -- MSA sends message to next MTA. 915 -- Final MTA receives message. 917 -- Final MTA delivers message to recipient's mailbox (possibly 918 generating a Delivery Status Notification (DSN)). 920 -- (Recipient's) MUA discovers a new message in recipient's mailbox 921 and decides whether an MDN should be generated. If the MUA has 922 information that an MDN has already been generated for this 923 message, no further MDN processing described below is performed. 924 If MUA decides that no MDN can be generated, no further MDN 925 processing described below is performed. 927 -- MUA performs automatic processing and might generate corresponding 928 MDNs ("dispatched", "processed" or "deleted" disposition type with 929 "automatic-action" and "MDN-sent-automatically" disposition 930 modes). The MUA remembers that an MDN was generated. 932 -- MUA displays list of messages to user. 934 -- User selects a message and requests that some action be performed 935 on it. 937 -- MUA performs requested action; if an automatic MDN has not already 938 been generated, with user's permission, sends an appropriate MDN 939 ("displayed", "dispatched", "processed", or "deleted" disposition 940 type, with "manual-action" and "MDN-sent-manually" or "MDN-sent- 941 automatically" disposition mode). The MUA remembers that an MDN 942 was generated. 944 -- User possibly performs other actions on message, but no further 945 MDNs are generated. 947 5. Conformance and Usage Requirements 949 An MUA or gateway conforms to this specification if it generates MDNs 950 according to the protocol defined in this memo. It is not necessary 951 to be able to generate all of the possible values of the Disposition 952 field. 954 MUAs and gateways MUST NOT generate the Original-Recipient field of 955 an MDN unless the mail protocols provide the address originally 956 specified by the sender at the time of submission. Ordinary SMTP 957 does not make that guarantee, but the SMTP extension defined in RFC- 958 DSN-SMTP [RFC3461] permits such information to be carried in the 959 envelope if it is available. The Original-Recipient header field 960 defined in this document provides a way for the MTA to pass the 961 original recipient address to the MUA. 963 Each sender-specified recipient address may result in more than one 964 MDN. If an MDN is requested for a recipient that is forwarded to 965 multiple recipients of an "alias" (as defined in RFC-DSN-SMTP 966 [RFC3461], section 6.2.7.3), each of the recipients may issue an MDN. 968 Successful distribution of a message to a mailing list exploder or 969 gateway to Usenet newsgroup SHOULD be considered the final 970 disposition of the message. A mailing list exploder MAY issue an MDN 971 with a disposition type of "processed" and disposition modes of 972 "automatic-action" and "MDN-sent-automatically" indicating that the 973 message has been forwarded to the list. In this case, the request 974 for MDNs is not propagated to the members of the list. 976 Alternatively (if successful distribution of a message to a mailing 977 list exploder/Usenet newsgroup is not considered the final 978 disposition of the message), the mailing list exploder can issue no 979 MDN and propagate the request for MDNs to all members of the list. 980 The latter behavior is not recommended for any but small, closely 981 knit lists, as it might cause large numbers of MDNs to be generated 982 and may cause confidential subscribers to the list to be revealed. 984 The mailing list exploder can also direct MDNs to itself, correlate 985 them, and produce a report to the original sender of the message. 987 This specification places no restrictions on the processing of MDNs 988 received by user agents or mailing lists. 990 6. Security Considerations 992 The following security considerations apply when using MDNs: 994 6.1. Forgery 996 MDNs can be (and are, in practice) forged as easily as ordinary 997 Internet electronic mail. User agents and automatic mail handling 998 facilities (such as mail distribution list exploders) that wish to 999 make automatic use of MDNs should take appropriate precautions to 1000 minimize the potential damage from denial-of-service attacks. 1002 Security threats related to forged MDNs include the sending of: 1004 a. A falsified disposition notification when the indicated 1005 disposition of the message has not actually occurred, 1007 b. Unsolicited MDNs 1009 Similarly, a forged spam or phishing email message can contain 1010 Disposition-Notification-To header field that can trick the recipient 1011 to send an MDN. MDN processing should only be invoked once 1012 authenticity of email message is verified. 1014 6.2. Privacy 1016 Another dimension of security is privacy. There may be cases in 1017 which a message recipient does not wish the disposition of messages 1018 addressed to him to be known, or is concerned that the sending of 1019 MDNs may reveal other sensitive information (e.g., when the message 1020 was read). In this situation, it is acceptable for the MUA to 1021 silently ignore requests for MDNs. 1023 If the Disposition-Notification-To header field is passed on 1024 unmodified when a message is distributed to the subscribers of a 1025 mailing list, the subscribers to the list may be revealed to the 1026 sender of the original message by the generation of MDNs. 1028 Headers of the original message returned in part 3 of the multipart/ 1029 report, as well as content of the message/disposition-notification 1030 part could reveal confidential information about host names and/or 1031 network topology inside a firewall. 1033 Disposition mode (Section 3.2.6.1) can leak information about 1034 recipient's MUA configuration, in particular whether MDNs are 1035 acknowledged manually or automatically. If this is a concern, MUAs 1036 can return "manual-action/MDN-sent-manually" disposition mode in 1037 generated MDNs. 1039 In general, any optional MDN field may be omitted if the Reporting 1040 MUA site or user determines that inclusion of the field would impose 1041 too great a compromise of site confidentiality. The need for such 1042 confidentiality must be balanced against the utility of the omitted 1043 information in MDNs. 1045 In some cases, someone with access to the message stream may use the 1046 MDN request mechanism to monitor the mail reading habits of a target. 1047 If the target is known to generate MDN reports, they could add a 1048 disposition-notification-to field containing the envelope from 1049 address. This risk can be minimized by not sending MDN's 1050 automatically. 1052 6.3. Non-Repudiation 1054 MDNs do not provide non-repudiation with proof of delivery. Within 1055 the framework of today's Internet Mail, the MDNs defined in this 1056 document provide valuable information to the mail user; however, MDNs 1057 cannot be relied upon as a guarantee that a message was or was not 1058 seen by the recipient. Even if MDNs are not actively forged, they 1059 may be lost in transit. The recipient may bypass the MDN issuing 1060 mechanism in some manner. 1062 One possible solution for this purpose can be found in RFC-SEC- 1063 SERVICES [RFC2634]. 1065 6.4. Mail Bombing 1067 The MDN request mechanism introduces an additional way of mailbombing 1068 a mailbox. The MDN request notification provides an address to which 1069 MDN's should be sent. It is possible for an attacking agent to send 1070 a potentially large set of messages to otherwise unsuspecting third 1071 party recipients with a false "disposition-notification-to:" address. 1072 Automatic, or simplistic processing of such requests would result in 1073 a flood of MDN notifications to the target of the attack. Such an 1074 attack could overrun the capacity of the targeted mailbox and deny 1075 service. 1077 For that reason, MDN's SHOULD NOT be sent automatically where the 1078 "disposition-notification-to:" address is different from the SMTP 1079 "MAIL FROM" address (which is carried in the Return-Path header 1080 field). See Section 2.1 for further discussion. 1082 7. Collected ABNF Grammar 1084 NOTE: The following lexical tokens are defined in RFC-MSGFMT 1085 [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, 1086 comment, word. The following lexical tokens are defined in RFC-SMTP 1087 [RFC5321]: atom. (Note that RFC-MSGFMT [RFC5322] also defines 1088 "atom", but the version from RFC-SMTP [RFC5321] is more restrictive 1089 and this more restrictive version is used in this document.) 1090 "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] is 1091 allowed everywhere where RFC-MSGFMT [RFC5322] "comment" is used, for 1092 example in CFWS. 1094 OWS = [CFWS] 1095 ; Optional whitespace. 1096 ; MDN generators SHOULD use "*WSP" 1097 ; (typically a single space or nothing. 1098 ; It SHOULD be nothing at the end of a field), 1099 ; unless an RFC 5322 "comment" is required. 1100 ; 1101 ; MDN parsers MUST parse it as "[CFWS]". 1103 Message header fields: 1104 mdn-request-header = 1105 "Disposition-Notification-To" ":" mailbox-list CRLF 1107 Disposition-Notification-Options = 1108 "Disposition-Notification-Options" ":" [FWS] 1109 disposition-notification-parameter-list CRLF 1111 disposition-notification-parameter-list = 1112 disposition-notification-parameter 1113 *([FWS] ";" [FWS] disposition-notification-parameter) 1115 disposition-notification-parameter = attribute [FWS] "=" [FWS] 1116 importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) 1118 importance = "required" / "optional" 1120 attribute = atom 1122 value = word 1124 original-recipient-header = 1125 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS CRLF 1127 Report content: 1128 disposition-notification-content = 1129 [ reporting-ua-field CRLF ] 1130 [ mdn-gateway-field CRLF ] 1131 [ original-recipient-field CRLF ] 1132 final-recipient-field CRLF 1133 [ original-message-id-field CRLF ] 1134 disposition-field CRLF 1135 *( failure-field CRLF ) 1136 *( error-field CRLF ) 1137 *( extension-field CRLF ) 1139 address-type = atom 1141 mta-name-type = atom 1143 reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] 1145 ua-name = *text-no-semi 1147 ua-product = *([FWS] text) 1149 text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, 1150 %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon 1152 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name 1154 mta-name = *text 1156 original-recipient-field = 1157 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 1159 generic-address = *text 1161 final-recipient-field = 1162 "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 1164 original-message-id-field = "Original-Message-ID" ":" msg-id 1166 disposition-field = 1167 "Disposition" ":" OWS disposition-mode OWS ";" 1168 OWS disposition-type 1169 [ OWS "/" OWS disposition-modifier 1170 *( OWS "," OWS disposition-modifier ) ] OWS 1172 disposition-mode = action-mode OWS "/" OWS sending-mode 1173 action-mode = "manual-action" / "automatic-action" 1175 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 1177 disposition-type = "displayed" / "deleted" / "dispatched" / 1178 "processed" 1180 disposition-modifier = "error" / disposition-modifier-extension 1182 disposition-modifier-extension = atom 1184 error-field = "Error" ":" *([FWS] text) 1186 extension-field = extension-field-name ":" *([FWS] text) 1188 extension-field-name = field-name 1190 8. Guidelines for Gatewaying MDNs 1192 NOTE: This section provides non-binding recommendations for the 1193 construction of mail gateways that wish to provide semi-transparent 1194 disposition notifications between the Internet and another electronic 1195 mail system. Specific MDN gateway requirements for a particular pair 1196 of mail systems may be defined by other documents. 1198 8.1. Gatewaying from other mail systems to MDNs 1200 A mail gateway may issue an MDN to convey the contents of a "foreign" 1201 disposition notification over Internet Mail. When there are 1202 appropriate mappings from the foreign notification elements to MDN 1203 fields, the information may be transmitted in those MDN fields. 1204 Additional information (such as might be needed to tunnel the foreign 1205 notification through the Internet) may be defined in extension MDN 1206 fields. (Such fields should be given names that identify the foreign 1207 mail protocol, e.g., X400-* for X.400 protocol elements). 1209 The gateway must attempt to supply reasonable values for the 1210 Reporting-UA, Final-Recipient, and Disposition fields. These will 1211 normally be obtained by translating the values from the foreign 1212 notification into their Internet-style equivalents. However, some 1213 loss of information is to be expected. 1215 The sender-specified recipient address and the original message-id, 1216 if present in the foreign notification, should be preserved in the 1217 Original-Recipient and Original-Message-ID fields. 1219 The gateway should also attempt to preserve the "final" recipient 1220 address from the foreign system. Whenever possible, foreign protocol 1221 elements should be encoded as meaningful printable ASCII strings. 1223 For MDNs produced from foreign disposition notifications, the name of 1224 the gateway MUST appear in the MDN-Gateway field of the MDN. 1226 8.2. Gatewaying from MDNs to other mail systems 1228 It may be possible to gateway MDNs from the Internet into a foreign 1229 mail system. The primary purpose of such gatewaying is to convey 1230 disposition information in a form that is usable by the destination 1231 system. A secondary purpose is to allow "tunneling" of MDNs through 1232 foreign mail systems in case the MDN may be gatewayed back into the 1233 Internet. 1235 In general, the recipient of the MDN (i.e., the sender of the 1236 original message) will want to know, for each recipient: the closest 1237 available approximation to the original recipient address, and the 1238 disposition (displayed, printed, etc.). 1240 If possible, the gateway should attempt to preserve the Original- 1241 Recipient address and Original-Message-ID (if present) in the 1242 resulting foreign disposition report. 1244 If it is possible to tunnel an MDN through the destination 1245 environment, the gateway specification may define a means of 1246 preserving the MDN information in the disposition reports used by 1247 that environment. 1249 8.3. Gatewaying of MDN-requests to other mail systems 1251 By use of the separate disposition-notification-to request header 1252 field, this specification offers a richer functionality than most, if 1253 not all, other email systems. In most other email systems, the 1254 notification recipient is identical to the message sender as 1255 indicated in the "from" address. There are two interesting cases 1256 when gatewaying into such systems: 1258 1. If the address in the disposition-notification-to header field is 1259 identical to the address in the SMTP "MAIL FROM", the expected 1260 behavior will result, even if the disposition-notification-to 1261 information is lost. Systems should propagate the MDN request. 1263 2. If the address in the disposition-notification-to header field is 1264 different from the address in the SMTP "MAIL FROM", gatewaying 1265 into a foreign system without a separate notification address 1266 will result in unintended behavior. This is especially important 1267 when the message arrives via a mailing list expansion software 1268 that may specifically replace the SMTP "MAIL FROM" address with 1269 an alternate address. In such cases, the MDN request should not 1270 be gatewayed and should be silently dropped. This is consistent 1271 with other forms of non-support for MDN. 1273 9. Example 1275 NOTE: This example is provided as illustration only, and is not 1276 considered part of the MDN protocol specification. If the example 1277 conflicts with the protocol definition above, the example is wrong. 1279 Likewise, the use of *-type subfield names or extension fields in 1280 this example is not to be construed as a definition for those type 1281 names or extension fields. 1283 This is an MDN issued after a message has been displayed to the user 1284 of an Internet Mail user agent. 1286 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 1287 From: Joe Recipient 1288 Message-Id: <199509200019.12345@example.com> 1289 Subject: Disposition notification 1290 To: Jane Sender 1291 MIME-Version: 1.0 1292 Content-Type: multipart/report; report-type=disposition-notification; 1293 boundary="RAA14128.773615765/example.com" 1295 --RAA14128.773615765/example.com 1297 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe 1298 Recipient with subject "First draft of 1299 report" has been displayed. 1300 This is no guarantee that the message has been read or understood. 1302 --RAA14128.773615765/example.com 1303 content-type: message/disposition-notification 1305 Reporting-UA: joes-pc.cs.example.com; Foomail 97.1 1306 Original-Recipient: rfc822;Joe_Recipient@example.com 1307 Final-Recipient: rfc822;Joe_Recipient@example.com 1308 Original-Message-ID: <199509192301.23456@example.org> 1309 Disposition: manual-action/MDN-sent-manually; displayed 1311 --RAA14128.773615765/example.com 1312 content-type: message/rfc822 1314 [original message optionally goes here] 1316 --RAA14128.773615765/example.com-- 1318 10. IANA Considerations 1320 There are two actions for IANA: 1322 1. IANA is asked to update the registration template for the 1323 message/disposition-notification media type to the one in 1324 Section 3.1 of this document, and to update the reference for 1325 that media type to point to this document instead of to RFC 3798. 1327 2. The registries specified here already exist, and this section is 1328 updating their documentation. IANA is asked to change the 1329 reference document for the three Message Disposition Notification 1330 Parameters registries to point to this document instead of to RFC 1331 3798. 1333 This document specifies three types of parameters that must be 1334 registered with the Internet Assigned Numbers Authority (IANA). All 1335 of them use [RFC5226] "Specification required" IANA registration 1336 policy. 1338 The forms below are for use when registering a new disposition- 1339 notification-parameter name for the Disposition-Notification-Options 1340 header field, a new disposition modifier name, or a new MDN extension 1341 field. Each piece of information required by a registration form may 1342 be satisfied either by providing the information on the form itself, 1343 or by including a reference to a published, publicly available 1344 specification that includes the necessary information. IANA MAY 1345 reject registrations because of incomplete registration forms or 1346 incomplete specifications. 1348 To register, complete the following applicable form and send it via 1349 electronic mail to . 1351 10.1. Disposition-Notification-Options header field disposition- 1352 notification-parameter names 1354 A registration for a Disposition-Notification-Options header field 1355 disposition-notification-parameter name MUST include the following 1356 information: 1358 a. The proposed disposition-notification-parameter name. 1360 b. The syntax for disposition-notification-parameter values, 1361 specified using BNF, ABNF, regular expressions, or other non- 1362 ambiguous language. 1364 c. If disposition-notification-parameter values are not composed 1365 entirely of graphic characters from the US-ASCII repertoire, a 1366 specification for how they are to be encoded as graphic US-ASCII 1367 characters in a Disposition-Notification-Options header field. 1369 d. A reference to a permanent and readily available public 1370 specification that describes the semantics of the disposition- 1371 notification-parameter values. 1373 10.2. Disposition modifier names 1375 A registration for a disposition-modifier name (used in the 1376 Disposition field of a message/disposition-notification) MUST include 1377 the following information: 1379 a. The proposed disposition-modifier name. 1381 b. A reference to a permanent and readily available public 1382 specification that describes the semantics of the disposition 1383 modifier. 1385 10.3. MDN extension field names 1387 A registration for an MDN extension-field name MUST include the 1388 following information: 1390 a. The proposed extension field name. 1392 b. The syntax for extension values, specified using BNF, ABNF, 1393 regular expressions, or other non-ambiguous language. 1395 c. If extension-field values are not composed entirely of graphic 1396 characters from the US-ASCII repertoire, a specification for how 1397 they are to be encoded as graphic US-ASCII characters in a 1398 Disposition-Notification-Options header field. 1400 d. A reference to a permanent and readily available public 1401 specification that describes the semantics of the extension 1402 field. 1404 11. Acknowledgements 1406 The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben 1407 Campbell and Pete Resnick are gratefully acknowledged for this 1408 revision. 1410 The contributions of Roger Fajman and Greg Vaudreuil to earlier 1411 versions of this document are also gratefully acknowledged. 1413 12. References 1415 12.1. Normative References 1417 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1418 DOI 10.17487/RFC5321, October 2008, 1419 . 1421 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1422 DOI 10.17487/RFC5322, October 2008, 1423 . 1425 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1426 Extensions (MIME) Part One: Format of Internet Message 1427 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1428 . 1430 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1431 Extensions (MIME) Part Two: Media Types", RFC 2046, 1432 DOI 10.17487/RFC2046, November 1996, 1433 . 1435 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1436 Part Three: Message Header Extensions for Non-ASCII Text", 1437 RFC 2047, DOI 10.17487/RFC2047, November 1996, 1438 . 1440 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 1441 the Reporting of Mail System Administrative Messages", 1442 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 1443 . 1445 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1446 Extension for Delivery Status Notifications (DSNs)", 1447 RFC 3461, DOI 10.17487/RFC3461, January 2003, 1448 . 1450 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1451 for Delivery Status Notifications", RFC 3464, 1452 DOI 10.17487/RFC3464, January 2003, 1453 . 1455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1456 Requirement Levels", BCP 14, RFC 2119, 1457 DOI 10.17487/RFC2119, March 1997, 1458 . 1460 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 1461 profile for Internet Message Access Protocol (IMAP)", 1462 RFC 3503, DOI 10.17487/RFC3503, March 2003, 1463 . 1465 12.2. Informative References 1467 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 1468 RFC 2634, DOI 10.17487/RFC2634, June 1999, 1469 . 1471 [RFC3249] Cancio, V., Moldovan, M., Tamura, H., and D. Wing, 1472 "Implementers Guide for Facsimile Using Internet Mail", 1473 RFC 3249, DOI 10.17487/RFC3249, September 2002, 1474 . 1476 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1477 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1478 . 1480 [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1481 Mail - version 2 (VPIMv2)", RFC 3801, 1482 DOI 10.17487/RFC3801, June 2004, 1483 . 1485 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 1486 Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, 1487 . 1489 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1490 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1491 DOI 10.17487/RFC5226, May 2008, 1492 . 1494 [RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and 1495 Extended Reject Extensions", RFC 5429, 1496 DOI 10.17487/RFC5429, March 2009, 1497 . 1499 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1500 DOI 10.17487/RFC5598, July 2009, 1501 . 1503 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, 1504 "Internationalized Delivery Status and Disposition 1505 Notifications", RFC 6533, DOI 10.17487/RFC6533, February 1506 2012, . 1508 Appendix A. Changes from RFC 3798 1510 Changed IANA registration for different subregistries to 1511 "Specification Required" to match what is already used by IANA. 1513 Updated IANA registration template for message/disposition- 1514 notification. 1516 "X-" fields no longer reserved for experimental use and can now be 1517 registered in compliance with RFC 6648. 1519 Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns". 1521 Strengthen requirements on obtaining user consent in order to protect 1522 user privacy. 1524 Removed discussion of using source routes with MDNs, as source route 1525 is a deprecated Email feature. 1527 The values of "dispatched" and "processed" were lost from the ABNF 1528 for "disposition-type". (Erratum #691) 1530 Because the warning disposition modifier was previously removed, 1531 warning-field has also been removed. (Erratum #692) 1533 The ABNF for ua-name and ua-product included semi-colon, which could 1534 not be distinguished from *text in the production. The ua-name was 1535 restricted to not include semi-colon. Semi-colon can still appear in 1536 the ua-product. 1538 Removed recommendation to include the MUA DNS host name in the 1539 "Reporting-UA" MDN field. 1541 The ABNF did not indicate all places that whitespace was allowable, 1542 in particular folding whitespace, although all implementations allow 1543 whitespace and folding in the header fields just like any other 1544 RFC5322 [RFC5322]-formatted header field. There were also a number 1545 of places in the ABNF that inconsistently permitted comments and 1546 whitespace in one leg of the production and not another. The ABNF 1547 now specifies FWS and CFWS in several places that should have already 1548 been specified by the grammar. 1550 Extension-field was defined in the collected grammar but not in the 1551 main text. 1553 The comparison of mailboxes in Disposition-Notification-To to the 1554 Return-Path addr-spec was clarified. 1556 The use of the grammar production "parameter" was confusing with the 1557 RFC2045 [RFC2045] production of the same name, as well as other uses 1558 of the same term. These have been clarified. 1560 A clarification was added on the extent of the 7bit nature of MDNs. 1562 Uses of the terms "may" and "might" were clarified. 1564 A clarification was added on the order of the fields in the message/ 1565 disposition-notification content. 1567 Authors' Addresses 1569 Tony Hansen (editor) 1570 AT&T Laboratories 1571 200 Laurel Ave. South 1572 Middletown, NJ 07748 1573 USA 1575 Email: tony@att.com 1577 Alexey Melnikov (editor) 1578 Isode Ltd 1579 14 Castle Mews 1580 Hampton, Middlesex TW12 2NP 1581 UK 1583 Email: Alexey.Melnikov@isode.com