idnits 2.17.1 draft-ietf-appsawg-mdn-3798bis-07.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 obsoletes RFC3798, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3461, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2046, but the abstract doesn't seem to mention this, which it should. 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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (See Section 10 for a registration form.) MDNs with disposition modifier names not understood by the receiving MUA MAY be silently ignored or placed in the user's mailbox without special interpretation. They MUST not cause any error message to be sent to the sender of the MDN. (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 (May 1, 2016) is 2888 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 1070, but not defined == Missing Reference: 'CFWS' is mentioned on line 363, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 487, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 518, but not defined ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) -- 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: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 May 1, 2016 7 Expires: November 2, 2016 9 Message Disposition Notification 10 draft-ietf-appsawg-mdn-3798bis-07.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 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 2, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 73 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Requesting Message Disposition Notifications . . . . . . . . 5 75 2.1. The Disposition-Notification-To Header . . . . . . . . . 5 76 2.2. The Disposition-Notification-Options Header . . . . . . . 7 77 2.3. The Original-Recipient Header Field . . . . . . . . . . . 8 78 2.4. Use with the Message/Partial Media Type . . . . . . . . . 9 79 3. Format of a Message Disposition Notification . . . . . . . . 9 80 3.1. The message/disposition-notification Media Type . . . . . 11 81 3.2. Message/disposition-notification Content Fields . . . . . 14 82 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 19 83 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 20 84 5. Conformance and Usage Requirements . . . . . . . . . . . . . 21 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 23 89 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 23 90 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 24 91 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 25 92 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 26 93 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 26 94 8.3. Gatewaying of MDN-requests to other mail systems . . . . 27 95 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 97 10.1. Disposition-Notification-Options header field 98 disposition-notification-parameter names . . . . . . . . 29 99 10.2. Disposition modifier names . . . . . . . . . . . . . . . 30 100 10.3. MDN extension field names . . . . . . . . . . . . . . . 30 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 104 12.2. Informative References . . . . . . . . . . . . . . . . . 32 105 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 32 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 108 1. Introduction 110 This memo defines a media type [RFC2046] for message disposition 111 notifications (MDNs). An MDN can be used to notify the sender of a 112 message of any of several conditions that may occur after successful 113 delivery, such as display of the message contents, printing of the 114 message, deletion (without display) of the message, or the 115 recipient's refusal to provide MDNs. The "message/disposition- 116 notification" content-type defined herein is intended for use within 117 the framework of the "multipart/report" content type defined in RFC- 118 REPORT [RFC3462]. 120 This memo defines the format of the notifications and the RFC-MSGFMT 121 [RFC5322] header fields used to request them. 123 This memo is an update to RFC 3798 and is intended to be published at 124 Internet Standard Level. 126 This memo is currently marked with the 'pre5378Trust200902' IPR 127 statements until a release has been obtained from all previous 128 authors and editors of this text. 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 laverage 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 purpose of 237 obtaining user's consent is to protect user's privacy. If user's 238 consent is obtained through a preference, the default value should be 239 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 MUST be 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. 304 2.2. The Disposition-Notification-Options Header 306 Extensions to this specification may require that information be 307 supplied to the recipient's MUA for additional control over how and 308 what MDNs are generated. The Disposition-Notification-Options header 309 field provides an extensible mechanism for such information. The 310 syntax of this header field is as follows: 312 Disposition-Notification-Options = 313 "Disposition-Notification-Options" ":" [FWS] 314 disposition-notification-parameter-list CRLF 315 disposition-notification-parameter-list = 316 disposition-notification-parameter 317 *([FWS] ";" [FWS] disposition-notification-parameter) 318 disposition-notification-parameter = attribute [FWS] "=" 319 [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) 320 importance = "required" / "optional" 321 attribute = atom 322 value = word 324 A Disposition-Notification-Options header field can appear at most 325 once in a message. 327 An importance of "required" indicates that interpretation of the 328 disposition-notification-parameter is necessary for proper generation 329 of an MDN in response to this request. An importance of "optional" 330 indicates that an MUA that does not understand the meaning of this 331 disposition-notification-parameter MAY generate an MDN in response 332 anyway, ignoring the value of the disposition-notification-parameter. 334 No disposition-notification-parameter attribute names are defined in 335 this specification. Attribute names may be defined in the future by 336 later revisions or extensions to this specification. Disposition- 337 notification-parameter attribute names beginning with "X-" will never 338 be defined as standard names; such names are reserved for 339 experimental use. disposition-notification-parameter attribute names 340 not beginning with "X-" MUST be registered with the Internet Assigned 341 Numbers Authority (IANA) using "Specification required" registration 342 policy. 343 (See Section 10 for a registration form.) 345 2.3. The Original-Recipient Header Field 347 Since electronic mail addresses may be rewritten while the message is 348 in transit, it is useful for the original recipient address to be 349 made available by the delivering Message Transfer Agent (MTA) 350 [RFC5598]. The delivering MTA may be able to obtain this information 351 from the ORCPT parameter of the SMTP RCPT TO command, as defined in 352 RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461]. 354 RFC-DSN-SMTP [RFC3461] is amended as follows: If the ORCPT 355 information is available, the delivering MTA SHOULD insert an 356 Original-Recipient header field at the beginning of the message 357 (along with the Return-Path header field). The delivering MTA MAY 358 delete any other Original-Recipient header fields that occur in the 359 message. The syntax of this header field is as follows: 361 original-recipient-header = 362 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 363 OWS = [CFWS] 364 ; Optional whitespace. 365 ; MDN generators SHOULD use "*WSP" 366 ; (typically a single space or nothing. 367 ; It SHOULD be nothing at the end of a field), 368 ; unless an RFC 5322 "comment" is required. 369 ; 370 ; MDN parsers MUST parse it as "[CFWS]". 372 The address-type and generic-address token are as specified in the 373 description of the Original-Recipient field in Section 3.2.3. 375 The purpose of carrying the original recipient information and 376 returning it in the MDN is to permit automatic correlation of MDNs 377 with the original message on a per-recipient basis. 379 2.4. Use with the Message/Partial Media Type 381 The use of the header fields Disposition-Notification-To, 382 Disposition-Notification-Options, and Original-Recipient with the 383 MIME message/partial content type (RFC-MIME-MEDIA [RFC2046]]) 384 requires further definition. 386 When a message is segmented into two or more message/partial 387 fragments, the three header fields mentioned in the above paragraph 388 SHOULD be placed in the "inner" or "enclosed" message (using the 389 terms of RFC-MIME-MEDIA [RFC2046]). If these header fields are found 390 in the header fields of any of the fragments, they are ignored. 392 When the multiple message/partial fragments are reassembled, the 393 following applies. If these header fields occur along with the other 394 header fields of a message/partial fragment message, they pertain to 395 an MDN that will be generated for the fragment. If these header 396 fields occur in the header fields of the "inner" or "enclosed" 397 message (using the terms of RFC-MIME-MEDIA [RFC2046]), they pertain 398 to an MDN that will be generated for the reassembled message. 399 Section 5.2.2.1 of RFC-MIME-MEDIA [RFC2046]) is amended to specify 400 that, in addition to the header fields specified there, the three 401 header fields described in this specification are to be appended, in 402 order, to the header fields of the reassembled message. Any 403 occurrences of the three header fields defined here in the header 404 fields of the initial enclosing message MUST NOT be copied to the 405 reassembled message. 407 3. Format of a Message Disposition Notification 409 A message disposition notification is a MIME message with a top-level 410 content-type of multipart/report (defined in RFC-REPORT [RFC3462]). 411 When multipart/report content is used to transmit an MDN: 413 a. The report-type parameter of the multipart/report content is 414 "disposition-notification". 416 b. The first component of the multipart/report contains a human- 417 readable explanation of the MDN, as described in RFC-REPORT 418 [RFC3462]. 420 c. The second component of the multipart/report is of content-type 421 message/disposition-notification, described in Section 3.1 of 422 this document. 424 d. If the original message or a portion of the message is to be 425 returned to the sender, it appears as the third component of the 426 multipart/report. The decision of whether or not to return the 427 message or part of the message is up to the MUA generating the 428 MDN. However, in the case of encrypted messages requesting MDNs, 429 encrypted message text MUST be returned, if it is returned at 430 all, only in its original encrypted form. 432 NOTE: For message disposition notifications gatewayed from foreign 433 systems, the header fields of the original message may not be 434 available. In this case, the third component of the MDN may be 435 omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header 436 fields that contain equivalent information. In particular, it is 437 very desirable to preserve the subject and date fields from the 438 original message. 440 The MDN MUST be addressed (in both the message header field and the 441 transport envelope) to the address(es) from the Disposition- 442 Notification-To header field from the original message for which the 443 MDN is being generated. 445 The From header field of the MDN MUST contain the address of the 446 person for whom the message disposition notification is being issued. 448 The envelope sender address (i.e., SMTP "MAIL FROM") of the MDN MUST 449 be null (<>), specifying that no Delivery Status Notification 450 messages nor other messages indicating successful or unsuccessful 451 delivery are to be sent in response to an MDN. 453 A message disposition notification MUST NOT itself request an MDN. 454 That is, it MUST NOT contain a Disposition-Notification-To header 455 field. 457 The Message-ID header field (if present) for an MDN MUST be different 458 from the Message-ID of the message for which the MDN is being issued. 460 A particular MDN describes the disposition of exactly one message for 461 exactly one recipient. Multiple MDNs may be generated as a result of 462 one message submission, one per recipient. However, due to the 463 circumstances described in Section 2.1, it's possible that some of 464 the recipients for whom MDNs were requested will not generate MDNs. 466 3.1. The message/disposition-notification Media Type 468 The message/disposition-notification Media Type is defined as 469 follows: 471 Type name: message 473 Subtype name: disposition-notification 475 Required parameters: none 477 Optional parameters: none 479 Encoding considerations: "7bit" encoding is sufficient and MUST be 480 used to maintain readability when viewed by non- 481 MIME mail readers. 483 Security considerations: discussed in Section 6 of [RFCXXX]. 485 Interoperability considerations: none 487 Published specification: [RFCXXX] 489 Applications that use this media type: Mail Transfer Agents and 490 email clients that support multipart/report 491 generation and/or parsing. 493 Fragment identifier considerations: N/A 495 Additional information: 497 Deprecated alias names for this type: N/A 499 Magic number(s): none 501 File extension(s): .disposition-notification 502 Macintosh file type code(s): The 'TEXT' type 503 code is suggested as files of this type are 504 typically used for diagnostic purposes and 505 suitable for analysis in a text editor. A 506 uniform type identifier (UTI) of "public.utf8- 507 email-message-header" is suggested. This type 508 conforms to "public.plain-text". 510 Person & email address to contact for further information: See the 511 Authors' Addresses section of [RFCXXXX] 513 Intended usage: COMMON 515 Restrictions on usage: This media type contains textual data in the 516 US-ASCII charset, which is always 7-bit. 518 Author: See the Authors' Addresses section of [RFCXXXX] 520 Change controller: IETF 522 Provisional registration? no 524 (While the 7bit restriction applies to the message/disposition- 525 notification portion of the multipart/report content, it does not 526 apply to the optional third portion of the multipart/report content.) 528 The message/disposition-notification report type for use in the 529 multipart/report is "disposition-notification". 531 The body of a message/disposition-notification consists of one or 532 more "fields" formatted according to the ABNF of RFC-MSGFMT [RFC5322] 533 header "fields". The syntax of the message/disposition-notification 534 content is as follows: 536 disposition-notification-content = [ reporting-ua-field CRLF ] 537 [ mdn-gateway-field CRLF ] 538 [ original-recipient-field CRLF ] 539 final-recipient-field CRLF 540 [ original-message-id-field CRLF ] 541 disposition-field CRLF 542 *( failure-field CRLF ) 543 *( error-field CRLF ) 544 *( extension-field CRLF ) 545 extension-field = extension-field-name ":" *([FWS] text) 546 extension-field-name = field-name 548 Note that the order of the above fields is fixed, with the exception 549 of the extension fields. 551 3.1.1. General conventions for fields 553 Since these fields are defined according to the rules of RFC-MSGFMT 554 [RFC5322], the same conventions for continuation lines and comments 555 apply. Notification fields may be continued onto multiple lines by 556 beginning each additional line with a SPACE or HTAB. Text that 557 appears in parentheses is considered a comment and not part of the 558 contents of that notification field. Field names are case- 559 insensitive, so the names of notification fields may be spelled in 560 any combination of upper and lower case letters. [RFC5322] comments 561 in notification fields may use the "encoded-word" construct defined 562 in RFC-MIME-HEADER [RFC2047]. 564 3.1.2. "*-type" subfields 566 Several fields consist of a "-type" subfield, followed by a semi- 567 colon, followed by "*text". 568 For these fields, the keyword used in the address-type or MTA-type 569 subfield indicates the expected format of the address or MTA-name 570 that follows. 572 The "-type" subfields are defined as follows: 574 a. An "address-type" specifies the format of a mailbox address. For 575 example, Internet Mail addresses use the "rfc822" address-type. 577 address-type = atom 578 atom = 580 b. An "MTA-name-type" specifies the format of a mail transfer agent 581 name. For example, for an SMTP server on an Internet host, the 582 MTA name is the domain name of that host, and the "dns" MTA-name- 583 type is used. 585 mta-name-type = atom 587 Values for address-type and mta-name-type are case-insensitive. 588 Thus, address-type values of "RFC822" and "rfc822" are equivalent. 590 The Internet Assigned Numbers Authority (IANA) maintains a registry 591 of address-type and mta-name-type values, along with descriptions of 592 the meanings of each, or a reference to one or more specifications 593 that provide such descriptions. (The "rfc822" address-type is 594 defined in RFC-DSN-SMTP [RFC3461].) Registration forms for address- 595 type and mta-name-type appear in RFC-DSN-FORMAT [RFC3464]. 597 3.2. Message/disposition-notification Content Fields 599 3.2.1. The Reporting-UA field 601 reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] 602 ua-name = *text-no-semi 603 ua-product = *([FWS] text) 604 text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, 605 %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon 607 The Reporting-UA field is defined as follows: 609 An MDN describes the disposition of a message after it has been 610 delivered to a recipient. In all cases, the Reporting-UA is the MUA 611 that performed the disposition described in the MDN. This field is 612 optional, but recommended. For Internet Mail user agents, it is 613 recommended that this field contain both: the DNS name of the 614 particular instance of the MUA that generated the MDN, and the name 615 of the product. For example, 617 Reporting-UA: pc.example.com; Foomail 97.1 619 If the reporting MUA consists of more than one component (e.g., a 620 base program and plug-ins), this may be indicated by including a list 621 of product names. 623 3.2.2. The MDN-Gateway field 625 The MDN-Gateway field indicates the name of the gateway or MTA that 626 translated a foreign (non-Internet) message disposition notification 627 into this MDN. This field MUST appear in any MDN that was translated 628 by a gateway from a foreign system into MDN format, and MUST NOT 629 appear otherwise. 631 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name OWS 632 mta-name = *text 634 For gateways into Internet Mail, the MTA-name-type will normally be 635 "dns", and the mta-name will be the Internet domain name of the 636 gateway. 638 3.2.3. Original-Recipient field 640 The Original-Recipient field indicates the original recipient address 641 as specified by the sender of the message for which the MDN is being 642 issued. For Internet Mail messages, the value of the Original- 643 Recipient field is obtained from the Original-Recipient header field 644 from the message for which the MDN is being generated. If there is 645 an Original-Recipient header field in the message, or if information 646 about the original recipient is reliably available some other way, 647 then the Original-Recipient field MUST be included. Otherwise, the 648 Original-Recipient field MUST NOT be included. If there is more than 649 one Original-Recipient header field in the message, the MUA may 650 choose the one to use, or act as if no Original-Recipient header 651 field is present. 653 original-recipient-field = 654 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 655 generic-address = *text 657 The address-type field indicates the type of the original recipient 658 address. If the message originated within the Internet, the address- 659 type field will normally be "rfc822", and the address will be 660 according to the syntax specified in RFC-MSGFMT [RFC5322]. The value 661 "unknown" should be used if the Reporting MUA cannot determine the 662 type of the original recipient address from the message envelope. 663 This address is the same as that provided by the sender and can be 664 used to automatically correlate MDN reports with original messages on 665 a per recipient basis. 667 3.2.4. Final-Recipient field 669 The Final-Recipient field indicates the recipient for which the MDN 670 is being issued. This field MUST be present. 672 The syntax of the field is as follows: 674 final-recipient-field = 675 "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 677 The generic-address subfield of the Final-Recipient field MUST 678 contain the mailbox address of the recipient (from the From header 679 field of the MDN) as it was when the MDN was generated by the MUA. 681 The Final-Recipient address may differ from the address originally 682 provided by the sender, because it may have been transformed during 683 forwarding and gatewaying into a totally unrecognizable mess. 684 However, in the absence of the optional Original-Recipient field, the 685 Final-Recipient field and any returned content may be the only 686 information available with which to correlate the MDN with a 687 particular message recipient. 689 The address-type subfield indicates the type of address expected by 690 the reporting MTA in that context. Recipient addresses obtained via 691 SMTP will normally be of address-type "rfc822", but can be other 692 values from the "Address Types" subregistry of the "Delivery Status 693 Notification (DSN) Types" IANA registry. 695 Since mailbox addresses (including those used in the Internet) may be 696 case sensitive, the case of alphabetic characters in the address MUST 697 be preserved. 699 3.2.5. Original-Message-ID field 701 The Original-Message-ID field indicates the message-ID of the message 702 for which the MDN is being issued. It is obtained from the Message- 703 ID header field of the message for which the MDN is issued. This 704 field MUST be present if and only if the original message contained a 705 Message-ID header field. The syntax of the field is as follows: 707 original-message-id-field = 708 "Original-Message-ID" ":" msg-id 710 The msg-id token is as specified in RFC-MSGFMT [RFC5322]. 712 3.2.6. Disposition field 714 The Disposition field indicates the action performed by the 715 Reporting-MUA on behalf of the user. This field MUST be present. 717 The syntax for the Disposition field is: 719 disposition-field = 720 "Disposition" ":" OWS disposition-mode OWS ";" 721 OWS disposition-type 722 [ OWS "/" OWS disposition-modifier 723 *( OWS "," OWS disposition-modifier ) ] OWS 724 disposition-mode = action-mode OWS "/" OWS sending-mode 725 action-mode = "manual-action" / "automatic-action" 726 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 727 disposition-type = "displayed" / "deleted" / "dispatched" / 728 "processed" 729 disposition-modifier = "error" / disposition-modifier-extension 730 disposition-modifier-extension = atom 732 The disposition-mode, disposition-type, and disposition-modifier 733 values may be spelled in any combination of upper and lower case US- 734 ASCII characters. 736 3.2.6.1. Disposition modes 738 The following disposition modes are defined: 740 "manual-action" The disposition described by the disposition type 741 was a result of an explicit instruction by the 742 user rather than some sort of automatically 743 performed action. Unless prescribed otherwise in 744 a particular mail environment, in order to 745 preserve user's privacy, this is the default for 746 MUAs. 748 "automatic-action" The disposition described by the disposition type 749 was a result of an automatic action, rather than 750 an explicit instruction by the user for this 751 message. 753 "Manual-action" and "automatic-action" are mutually exclusive. One 754 or the other MUST be specified. 756 "MDN-sent-manually" The user explicitly gave permission for this 757 particular MDN to be sent. 759 "MDN-sent-automatically" The MDN was sent because the MUA had 760 previously been configured to do so 761 automatically. 763 "MDN-sent-manually" and "MDN-sent-automatically" are mutually 764 exclusive. One or the other MUST be specified. 766 3.2.6.2. Disposition types 768 The following disposition-types are defined: 770 "displayed" The message has been displayed by the MUA to 771 someone reading the recipient's mailbox. There 772 is no guarantee that the content has been read or 773 understood. 775 "dispatched" The message has been sent somewhere in some 776 manner (e.g., printed, faxed, forwarded) without 777 necessarily having been previously displayed to 778 the user. The user may or may not see the 779 message later. 781 "processed" The message has been processed in some manner 782 (i.e., by some sort of rules or server) without 783 being displayed to the user. The user may or may 784 not see the message later, or there may not even 785 be a human user associated with the mailbox. 787 "deleted" The message has been deleted. The recipient may 788 or may not have seen the message. The recipient 789 might "undelete" the message at a later time and 790 read the message. 792 3.2.6.3. Disposition modifiers 794 Only the extension disposition modifiers is defined: 796 disposition-modifier-extension 797 Disposition modifiers may be defined in the 798 future by later revisions or extensions to this 799 specification. Disposition value names beginning 800 with "X-" will never be defined as standard 801 values; such names are reserved for experimental 802 use. MDN disposition value names NOT beginning 803 with "X-" MUST be registered with the Internet 804 Assigned Numbers Authority (IANA) using 805 "Specification required" registration policy. 807 (See Section 10 for a registration form.) MDNs 808 with disposition modifier names not understood by 809 the receiving MUA MAY be silently ignored or 810 placed in the user's mailbox without special 811 interpretation. They MUST not cause any error 812 message to be sent to the sender of the MDN. 814 If an MUA developer does not wish to register the meanings of such 815 disposition modifier extensions, "X-" modifiers may be used for this 816 purpose. To avoid name collisions, the name of the MUA 817 implementation should follow the "X-", (e.g., "X-Foomail-"). 819 It is not required that an MUA be able to generate all of the 820 possible values of the Disposition field. 822 A user agent MUST NOT issue more than one MDN on behalf of each 823 particular recipient. That is, once an MDN has been issued on behalf 824 of a recipient, no further MDNs may be issued on behalf of that 825 recipient, even if another disposition is performed on the message. 826 However, if a message is forwarded, a "dispatched" MDN MAY be issued 827 for the recipient doing the forwarding and the recipient of the 828 forwarded message may also cause an MDN to be generated. 830 3.2.7. Failure and Error Fields 832 The Failure and Error fields are used to supply additional 833 information in the form of text messages when the "failure" 834 disposition type or "error" disposition modifier appear. The syntax 835 is as follows: 837 failure-field = "Failure" ":" *([FWS] text) 838 error-field = "Error" ":" *([FWS] text) 840 Note that syntax of these header fields doesn't include comments, so 841 "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't 842 be used to convey non ASCII text. Application that need to convey 843 non ASCII text in these fields should consider implementing message/ 844 global-disposition-notification media type specified in [RFC6533] 845 instead of this specification. 847 3.3. Extension-fields 849 Additional MDN fields may be defined in the future by later revisions 850 or extensions to this specification. Extension-field names beginning 851 with "X-" will never be defined as standard fields; such names are 852 reserved for experimental use. MDN field names NOT beginning with 853 "X-" MUST be registered with the Internet Assigned Numbers Authority 854 (IANA) using "Specification required" registration policy. (See 855 Section 10 for a registration form.) MDN Extension-fields may be 856 defined for the following reasons: 858 a. To allow additional information from foreign disposition reports 859 to be tunneled through Internet MDNs. The names of such MDN 860 fields should begin with an indication of the foreign environment 861 name (e.g., X400-Physical-Forwarding-Address). 863 b. To allow transmission of diagnostic information that is specific 864 to a particular mail user agent (MUA). The names of such MDN 865 fields should begin with an indication of the MUA implementation 866 that produced the MDN (e.g., Foomail-information). 868 If an application developer does not wish to register the meanings of 869 such extension fields, "X-" fields may be used for this purpose. To 870 avoid name collisions, the name of the application implementation 871 should follow the "X-", (e.g., "X-Foomail-Log-ID" or "X-Foomail-EDI- 872 info"). 874 4. Timeline of events 876 The following timeline shows when various events in the processing of 877 a message and generation of MDNs take place: 879 -- User composes message 881 -- User tells MUA to send message 883 -- MUA passes message to MTA (original recipient information passed 884 along) 886 -- MTA sends message to next MTA 888 -- Final MTA receives message 890 -- Final MTA delivers message to MUA (possibly generating a Delivery 891 Status Notification (DSN)) 893 -- MUA performs automatic processing and generates corresponding MDNs 894 ("dispatched", "processed" or "deleted" disposition type with 895 "automatic-action" and "MDN-sent-automatically" disposition modes) 897 -- MUA displays list of messages to user 899 -- User selects a message and requests that some action be performed 900 on it. 902 -- MUA performs requested action and, with user's permission, sends 903 an appropriate MDN ("displayed", "dispatched", "processed", or 904 "deleted" disposition type, with "manual-action" and "MDN-sent- 905 manually" or "MDN-sent-automatically" disposition mode). 907 -- User possibly performs other actions on message, but no further 908 MDNs are generated. 910 5. Conformance and Usage Requirements 912 An MUA or gateway conforms to this specification if it generates MDNs 913 according to the protocol defined in this memo. It is not necessary 914 to be able to generate all of the possible values of the Disposition 915 field. 917 MUAs and gateways MUST NOT generate the Original-Recipient field of 918 an MDN unless the mail protocols provide the address originally 919 specified by the sender at the time of submission. Ordinary SMTP 920 does not make that guarantee, but the SMTP extension defined in RFC- 921 DSN-SMTP [RFC3461] permits such information to be carried in the 922 envelope if it is available. The Original-Recipient header field 923 defined in this document provides a way for the MTA to pass the 924 original recipient address to the MUA. 926 Each sender-specified recipient address may result in more than one 927 MDN. If an MDN is requested for a recipient that is forwarded to 928 multiple recipients of an "alias" (as defined in RFC-DSN-SMTP 929 [RFC3461], section 6.2.7.3), each of the recipients may issue an MDN. 931 Successful distribution of a message to a mailing list exploder 932 SHOULD be considered the final disposition of the message. A mailing 933 list exploder MAY issue an MDN with a disposition type of "processed" 934 and disposition modes of "automatic-action" and "MDN-sent- 935 automatically" indicating that the message has been forwarded to the 936 list. In this case, the request for MDNs is not propagated to the 937 members of the list. 939 Alternatively (if successful distribution of a message to a mailing 940 list exploder is not considered the final disposition of the 941 message), the mailing list exploder MAY issue no MDN and propagate 942 the request for MDNs to all members of the list. The latter behavior 943 is not recommended for any but small, closely knit lists, as it might 944 cause large numbers of MDNs to be generated and may cause 945 confidential subscribers to the list to be revealed. The mailing 946 list exploder MAY also direct MDNs to itself, correlate them, and 947 produce a report to the original sender of the message. 949 This specification places no restrictions on the processing of MDNs 950 received by user agents or mailing lists. 952 6. Security Considerations 954 The following security considerations apply when using MDNs: 956 6.1. Forgery 958 MDNs can be (and are, in practice) forged as easily as ordinary 959 Internet electronic mail. User agents and automatic mail handling 960 facilities (such as mail distribution list exploders) that wish to 961 make automatic use of MDNs should take appropriate precautions to 962 minimize the potential damage from denial-of-service attacks. 964 Security threats related to forged MDNs include the sending of: 966 a. A falsified disposition notification when the indicated 967 disposition of the message has not actually occurred, 969 b. Unsolicited MDNs 971 6.2. Privacy 973 Another dimension of security is privacy. There may be cases in 974 which a message recipient does not wish the disposition of messages 975 addressed to him to be known, or is concerned that the sending of 976 MDNs may reveal other sensitive information (e.g., when the message 977 was read). In this situation, it is acceptable for the MUA to 978 silently ignore requests for MDNs. 980 If the Disposition-Notification-To header field is passed on 981 unmodified when a message is distributed to the subscribers of a 982 mailing list, the subscribers to the list may be revealed to the 983 sender of the original message by the generation of MDNs. 985 Headers of the original message returned in part 3 of the multipart/ 986 report could reveal confidential information about host names and/or 987 network topology inside a firewall. 989 An unencrypted MDN could reveal confidential information about an 990 encrypted message, especially if all or part of the original message 991 is returned in part 3 of the multipart/report. Encrypted MDNs are 992 not defined in this specification. 994 In general, any optional MDN field may be omitted if the Reporting 995 MUA site or user determines that inclusion of the field would impose 996 too great a compromise of site confidentiality. The need for such 997 confidentiality must be balanced against the utility of the omitted 998 information in MDNs. 1000 In some cases, someone with access to the message stream may use the 1001 MDN request mechanism to monitor the mail reading habits of a target. 1002 If the target is known to generate MDN reports, they could add a 1003 disposition-notification-to field containing the envelope from 1004 address along with a source route. The source route is ignored in 1005 the comparison so the addresses will always match. But if the source 1006 route is honored when the notification is sent, it could direct the 1007 message to some other destination. This risk can be minimized by not 1008 sending MDN's automatically. 1010 6.3. Non-Repudiation 1012 MDNs do not provide non-repudiation with proof of delivery. Within 1013 the framework of today's Internet Mail, the MDNs defined in this 1014 document provide valuable information to the mail user; however, MDNs 1015 cannot be relied upon as a guarantee that a message was or was not 1016 seen by the recipient. Even if MDNs are not actively forged, they 1017 may be lost in transit. The recipient may bypass the MDN issuing 1018 mechanism in some manner. 1020 One possible solution for this purpose can be found in RFC-SEC- 1021 SERVICES [RFC2634]. 1023 6.4. Mail Bombing 1025 The MDN request mechanism introduces an additional way of mailbombing 1026 a mailbox. The MDN request notification provides an address to which 1027 MDN's should be sent. It is possible for an attacking agent to send 1028 a potentially large set of messages to otherwise unsuspecting third 1029 party recipients with a false "disposition-notification-to:" address. 1031 Automatic, or simplistic processing of such requests would result in 1032 a flood of MDN notifications to the target of the attack. Such an 1033 attack could overrun the capacity of the targeted mailbox and deny 1034 service. 1036 For that reason, MDN's SHOULD NOT be sent automatically where the 1037 "disposition-notification-to:" address is different from the SMTP 1038 "MAIL FROM" address (which is carried in the Return-Path header 1039 field). See Section 2.1 for further discussion. 1041 7. Collected ABNF Grammar 1043 NOTE: The following lexical tokens are defined in RFC-MSGFMT 1044 [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, 1045 comment, word. The following lexical tokens are defined in RFC-SMTP 1046 [RFC5321]: atom. (Note that RFC-MSGFMT [RFC5322] also defines 1047 "atom", but the version from RFC-SMTP [RFC5321] is more restrictive 1048 and this more restrictive version is used in this document.) 1049 "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] is 1050 allowed everywhere where RFC-MSGFMT [RFC5322] "comment" is used, for 1051 example in CFWS. 1053 OWS = [CFWS] 1054 ; Optional whitespace. 1055 ; MDN generators SHOULD use "*WSP" 1056 ; (typically a single space or nothing. 1057 ; It SHOULD be nothing at the end of a field), 1058 ; unless an RFC 5322 "comment" is required. 1059 ; 1060 ; MDN parsers MUST parse it as "[CFWS]". 1062 Message header fields: 1063 mdn-request-header = 1064 "Disposition-Notification-To" ":" mailbox-list CRLF 1065 Disposition-Notification-Options = 1066 "Disposition-Notification-Options" ":" [FWS] 1067 disposition-notification-parameter-list CRLF 1068 disposition-notification-parameter-list = 1069 disposition-notification-parameter 1070 *([FWS] ";" [FWS] disposition-notification-parameter) 1071 disposition-notification-parameter = attribute [FWS] "=" [FWS] 1072 importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) 1073 importance = "required" / "optional" 1074 attribute = atom 1075 value = word 1076 original-recipient-header = 1077 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS CRLF 1079 Report content: 1080 disposition-notification-content = 1081 [ reporting-ua-field CRLF ] 1082 [ mdn-gateway-field CRLF ] 1083 [ original-recipient-field CRLF ] 1084 final-recipient-field CRLF 1085 [ original-message-id-field CRLF ] 1086 disposition-field CRLF 1087 *( failure-field CRLF ) 1088 *( error-field CRLF ) 1089 *( extension-field CRLF ) 1090 address-type = atom 1091 mta-name-type = atom 1092 reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] 1093 ua-name = *text-no-semi 1094 ua-product = *([FWS] text) 1095 text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, 1096 %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon 1097 mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name 1098 mta-name = *text 1099 original-recipient-field = 1100 "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 1101 generic-address = *text 1102 final-recipient-field = 1103 "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS 1104 original-message-id-field = "Original-Message-ID" ":" msg-id 1105 disposition-field = 1106 "Disposition" ":" OWS disposition-mode OWS ";" 1107 OWS disposition-type 1108 [ OWS "/" OWS disposition-modifier 1109 *( OWS "," OWS disposition-modifier ) ] OWS 1110 disposition-mode = action-mode OWS "/" OWS sending-mode 1111 action-mode = "manual-action" / "automatic-action" 1112 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 1113 disposition-type = "displayed" / "deleted" / "dispatched" / 1114 "processed" 1115 disposition-modifier = "error" / disposition-modifier-extension 1116 disposition-modifier-extension = atom 1117 failure-field = "Failure" ":" *([FWS] text) 1118 error-field = "Error" ":" *([FWS] text) 1119 extension-field = extension-field-name ":" *([FWS] text) 1120 extension-field-name = field-name 1122 8. Guidelines for Gatewaying MDNs 1124 NOTE: This section provides non-binding recommendations for the 1125 construction of mail gateways that wish to provide semi-transparent 1126 disposition notifications between the Internet and another electronic 1127 mail system. Specific MDN gateway requirements for a particular pair 1128 of mail systems may be defined by other documents. 1130 8.1. Gatewaying from other mail systems to MDNs 1132 A mail gateway may issue an MDN to convey the contents of a "foreign" 1133 disposition notification over Internet Mail. When there are 1134 appropriate mappings from the foreign notification elements to MDN 1135 fields, the information may be transmitted in those MDN fields. 1136 Additional information (such as might be needed to tunnel the foreign 1137 notification through the Internet) may be defined in extension MDN 1138 fields. (Such fields should be given names that identify the foreign 1139 mail protocol, e.g., X400-* for X.400 protocol elements). 1141 The gateway must attempt to supply reasonable values for the 1142 Reporting-UA, Final-Recipient, and Disposition fields. These will 1143 normally be obtained by translating the values from the foreign 1144 notification into their Internet-style equivalents. However, some 1145 loss of information is to be expected. 1147 The sender-specified recipient address and the original message-id, 1148 if present in the foreign notification, should be preserved in the 1149 Original-Recipient and Original-Message-ID fields. 1151 The gateway should also attempt to preserve the "final" recipient 1152 address from the foreign system. Whenever possible, foreign protocol 1153 elements should be encoded as meaningful printable ASCII strings. 1155 For MDNs produced from foreign disposition notifications, the name of 1156 the gateway MUST appear in the MDN-Gateway field of the MDN. 1158 8.2. Gatewaying from MDNs to other mail systems 1160 It may be possible to gateway MDNs from the Internet into a foreign 1161 mail system. The primary purpose of such gatewaying is to convey 1162 disposition information in a form that is usable by the destination 1163 system. A secondary purpose is to allow "tunneling" of MDNs through 1164 foreign mail systems in case the MDN may be gatewayed back into the 1165 Internet. 1167 In general, the recipient of the MDN (i.e., the sender of the 1168 original message) will want to know, for each recipient: the closest 1169 available approximation to the original recipient address, and the 1170 disposition (displayed, printed, etc.). 1172 If possible, the gateway should attempt to preserve the Original- 1173 Recipient address and Original-Message-ID (if present) in the 1174 resulting foreign disposition report. 1176 If it is possible to tunnel an MDN through the destination 1177 environment, the gateway specification may define a means of 1178 preserving the MDN information in the disposition reports used by 1179 that environment. 1181 8.3. Gatewaying of MDN-requests to other mail systems 1183 By use of the separate disposition-notification-to request header 1184 field, this specification offers a richer functionality than most, if 1185 not all, other email systems. In most other email systems, the 1186 notification recipient is identical to the message sender as 1187 indicated in the "from" address. There are two interesting cases 1188 when gatewaying into such systems: 1190 1. If the address in the disposition-notification-to header field is 1191 identical to the address in the SMTP "MAIL FROM", the expected 1192 behavior will result, even if the disposition-notification-to 1193 information is lost. Systems should propagate the MDN request. 1195 2. If the address in the disposition-notification-to header field is 1196 different from the address in the SMTP "MAIL FROM", gatewaying 1197 into a foreign system without a separate notification address 1198 will result in unintended behavior. This is especially important 1199 when the message arrives via a mailing list expansion software 1200 that may specifically replace the SMTP "MAIL FROM" address with 1201 an alternate address. In such cases, the MDN request should not 1202 be gatewayed and should be silently dropped. This is consistent 1203 with other forms of non-support for MDN. 1205 9. Example 1207 NOTE: This example is provided as illustration only, and is not 1208 considered part of the MDN protocol specification. If the example 1209 conflicts with the protocol definition above, the example is wrong. 1211 Likewise, the use of *-type subfield names or extension fields in 1212 this example is not to be construed as a definition for those type 1213 names or extension fields. 1215 This is an MDN issued after a message has been displayed to the user 1216 of an Internet Mail user agent. 1218 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 1219 From: Joe Recipient 1220 Message-Id: <199509200019.12345@example.com> 1221 Subject: Disposition notification 1222 To: Jane Sender 1223 MIME-Version: 1.0 1224 Content-Type: multipart/report; report-type=disposition-notification; 1225 boundary="RAA14128.773615765/example.com" 1227 --RAA14128.773615765/example.com 1229 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe 1230 Recipient with subject "First draft of 1231 report" has been displayed. 1232 This is no guarantee that the message has been read or understood. 1234 --RAA14128.773615765/example.com 1235 content-type: message/disposition-notification 1237 Reporting-UA: joes-pc.cs.example.com; Foomail 97.1 1238 Original-Recipient: rfc822;Joe_Recipient@example.com 1239 Final-Recipient: rfc822;Joe_Recipient@example.com 1240 Original-Message-ID: <199509192301.23456@example.org> 1241 Disposition: manual-action/MDN-sent-manually; displayed 1243 --RAA14128.773615765/example.com 1244 content-type: message/rfc822 1246 [original message optionally goes here] 1248 --RAA14128.773615765/example.com-- 1250 10. IANA Considerations 1252 There are two actions for IANA: 1254 1. IANA is asked to update the registration template for the 1255 message/disposition-notification media type to the one in 1256 Section 3.1 of this document, and to update the reference for 1257 that media type to point to this document instead of to RFC 3798. 1259 2. The registries specified here already exist, and this section is 1260 updating their documentation. IANA is asked to change the 1261 reference document for the three Message Disposition Notification 1262 Parameters registries to point to this document instead of to RFC 1263 3798. 1265 This document specifies three types of parameters that must be 1266 registered with the Internet Assigned Numbers Authority (IANA). All 1267 of them use [RFC5226] "Specification required" IANA registration 1268 policy. 1270 The forms below are for use when registering a new disposition- 1271 notification-parameter name for the Disposition-Notification-Options 1272 header field, a new disposition modifier name, or a new MDN extension 1273 field. Each piece of information required by a registration form may 1274 be satisfied either by providing the information on the form itself, 1275 or by including a reference to a published, publicly available 1276 specification that includes the necessary information. IANA MAY 1277 reject registrations because of incomplete registration forms or 1278 incomplete specifications. 1280 To register, complete the following applicable form and send it via 1281 electronic mail to . 1283 10.1. Disposition-Notification-Options header field disposition- 1284 notification-parameter names 1286 A registration for a Disposition-Notification-Options header field 1287 disposition-notification-parameter name MUST include the following 1288 information: 1290 a. The proposed disposition-notification-parameter name. 1292 b. The syntax for disposition-notification-parameter values, 1293 specified using BNF, ABNF, regular expressions, or other non- 1294 ambiguous language. 1296 c. If disposition-notification-parameter values are not composed 1297 entirely of graphic characters from the US-ASCII repertoire, a 1298 specification for how they are to be encoded as graphic US-ASCII 1299 characters in a Disposition-Notification-Options header field. 1301 d. A reference to a permanent and readily available public 1302 specification that describes the semantics of the disposition- 1303 notification-parameter values. 1305 10.2. Disposition modifier names 1307 A registration for a disposition-modifier name (used in the 1308 Disposition field of a message/disposition-notification) MUST include 1309 the following information: 1311 a. The proposed disposition-modifier name. 1313 b. A reference to a permanent and readily available public 1314 specification that describes the semantics of the disposition 1315 modifier. 1317 10.3. MDN extension field names 1319 A registration for an MDN extension-field name MUST include the 1320 following information: 1322 a. The proposed extension field name. 1324 b. The syntax for extension values, specified using BNF, ABNF, 1325 regular expressions, or other non-ambiguous language. 1327 c. If extension-field values are not composed entirely of graphic 1328 characters from the US-ASCII repertoire, a specification for how 1329 they are to be encoded as graphic US-ASCII characters in a 1330 Disposition-Notification-Options header field. 1332 d. A reference to a permanent and readily available public 1333 specification that describes the semantics of the extension 1334 field. 1336 11. Acknowledgements 1338 The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba and Pete 1339 Resnick are gratefully acknowledged for this revision. 1341 The contributions of Roger Fajman and Greg Vaudreuil to earlier 1342 versions of this document are also gratefully acknowledged. 1344 12. References 1346 12.1. Normative References 1348 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1349 DOI 10.17487/RFC5321, October 2008, 1350 . 1352 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1353 DOI 10.17487/RFC5322, October 2008, 1354 . 1356 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1357 Extensions (MIME) Part One: Format of Internet Message 1358 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1359 . 1361 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1362 Extensions (MIME) Part Two: Media Types", RFC 2046, 1363 DOI 10.17487/RFC2046, November 1996, 1364 . 1366 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1367 Part Three: Message Header Extensions for Non-ASCII Text", 1368 RFC 2047, DOI 10.17487/RFC2047, November 1996, 1369 . 1371 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 1372 Reporting of Mail System Administrative Messages", 1373 RFC 3462, DOI 10.17487/RFC3462, January 2003, 1374 . 1376 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1377 Extension for Delivery Status Notifications (DSNs)", 1378 RFC 3461, DOI 10.17487/RFC3461, January 2003, 1379 . 1381 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1382 for Delivery Status Notifications", RFC 3464, 1383 DOI 10.17487/RFC3464, January 2003, 1384 . 1386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1387 Requirement Levels", BCP 14, RFC 2119, 1388 DOI 10.17487/RFC2119, March 1997, 1389 . 1391 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 1392 profile for Internet Message Access Protocol (IMAP)", 1393 RFC 3503, DOI 10.17487/RFC3503, March 2003, 1394 . 1396 12.2. Informative References 1398 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 1399 RFC 2634, DOI 10.17487/RFC2634, June 1999, 1400 . 1402 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1403 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1404 . 1406 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 1407 Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, 1408 . 1410 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1411 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1412 DOI 10.17487/RFC5226, May 2008, 1413 . 1415 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1416 DOI 10.17487/RFC5598, July 2009, 1417 . 1419 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, 1420 "Internationalized Delivery Status and Disposition 1421 Notifications", RFC 6533, DOI 10.17487/RFC6533, February 1422 2012, . 1424 Appendix A. Changes from RFC 3798 1426 Changed IANA registration for different subregistries to 1427 "Specification Required" to match what is already used by IANA. 1429 The values of "dispatched" and "processed" were lost from the ABNF 1430 for "disposition-type". 1432 Because the warning disposition modifier was previously removed, 1433 warning-field has also been removed. 1435 The ABNF for ua-name and ua-product included semi-colon, which could 1436 not be distinguished from *text in the production. The ua-name was 1437 restricted to not include semi-colon. Semi-colon can still appear in 1438 the ua-product. 1440 The ABNF did not indicate all places that whitespace was allowable, 1441 in particular folding whitespace, although all implementations allow 1442 whitespace and folding in the header fields just like any other 1443 RFC5322 [RFC5322]-formatted header field. There were also a number 1444 of places in the ABNF that inconsistently permitted comments and 1445 whitespace in one leg of the production and not another. The ABNF 1446 now specifies FWS and CFWS in several places that should have already 1447 been specified by the grammar. 1449 Extension-field was defined in the collected grammar but not in the 1450 main text. 1452 The comparison of mailboxes in Disposition-Notification-To to the 1453 Return-Path addr-spec was clarified. 1455 The use of the grammar production "parameter" was confusing with the 1456 RFC2045 [RFC2045] production of the same name, as well as other uses 1457 of the same term. These have been clarified. 1459 A clarification was added on the extent of the 7bit nature of MDNs. 1461 Uses of the terms "may" and "might" were clarified. 1463 A clarification was added on the order of the fields in the message/ 1464 disposition-notification content. 1466 Authors' Addresses 1468 Tony Hansen (editor) 1469 AT&T Laboratories 1470 200 Laurel Ave. South 1471 Middletown, NJ 07748 1472 USA 1474 Email: tony+rfc3798@maillennium.att.com 1476 Alexey Melnikov (editor) 1477 Isode Ltd 1478 14 Castle Mews 1479 Hampton, Middlesex TW12 2NP 1480 UK 1482 Email: Alexey.Melnikov@isode.com