idnits 2.17.1 draft-vaudreuil-mdnbis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 12) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 309 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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: disposition-modifier-extension Disposition modifiers may be defined in the future by later revisions of or extensions to this specification. Disposition value names beginning with "X-" will never be defined as standard values; such names are reserved for experimental use. MDN disposition value names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. (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. -- 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 (July 23, 2003) is 7554 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) == Unused Reference: 'RFC-SMTP' is defined on line 1245, but no explicit reference was found in the text == Unused Reference: 'RFC-HOST' is defined on line 1251, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. 'RFC-SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. 'RFC-MSGFMT') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 3462 (ref. 'RFC-REPORT') (Obsoleted by RFC 6522) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Tony Hansen, ed 3 Expires in six months AT&T Laboratories 4 Obsoletes: RFC 2298 Greg Vaudreuil, ed 5 Updates: RFC 1891bis, 2046 Lucent Technologies 6 July 23, 2003 8 Message Disposition Notification 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC 2026. 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are valid for a maximum of six months and may be 23 updated, replaced, or obsoleted by other documents at any time. It is 24 inappropriate to use Internet Drafts as reference material or to cite 25 them other than as a "work in progress". 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 This Internet-Draft is in conformance with Section 10 of RFC 2026. 39 ABSTRACT 41 This memo defines a MIME content-type that may be used by a mail user 42 agent (MUA) or electronic mail gateway to report the disposition of a 43 message after it has been successfully delivered to a recipient. This 44 content-type is intended to be machine-processable. Additional 45 message headers are also defined to permit Message Disposition 46 Notifications (MDNs) to be requested by the sender of a message. The 47 purpose is to extend Internet Mail to support functionality often 48 found in other messaging systems, such as X.400 and the proprietary 49 "LAN-based" systems, and often referred to as "read receipts," 50 "acknowledgements", or "receipt notifications." The intention is to 51 do this while respecting privacy concerns, which have often been 52 expressed when such functions have been discussed in the past. 54 Because many messages are sent between the Internet and other 55 messaging systems (such as X.400 or the proprietary "LAN-based" 56 systems), the MDN protocol is designed to be useful in a multi- 57 protocol messaging environment. To this end, the protocol described 58 in this memo provides for the carriage of "foreign" addresses, in 59 addition to those normally used in Internet Mail. Additional 60 attributes may also be defined to support "tunneling" of foreign 61 notifications through Internet Mail. 63 Working Group Summary 65 RFC 1893 was a product of the Receipt working group. This document is 66 an individual submission, revising that document providing 67 clarifications as necessary to advance to draft standard. 69 Table of Contents 71 1. INTRODUCTION ......................................................4 72 1.1 Purposes ........................................................4 73 1.2 Requirements ....................................................5 74 1.3 Terminology .....................................................5 75 2. REQUESTING MESSAGE DISPOSITION NOTIFICATIONS ......................6 76 2.1 The Disposition-Notification-To Header ..........................6 77 2.2 The Disposition-Notification-Options Header .....................7 78 2.3 The Original-Recipient Header ...................................8 79 2.4 Use with the Message/Partial Content Type .......................9 80 3. FORMAT OF A MESSAGE DISPOSITION NOTIFICATION .....................10 81 3.1 The message/disposition-notification content-type ..............11 82 3.2 Message/disposition-notification Fields ........................12 83 3.3 Extension-fields ...............................................18 84 4. TIMELINE OF EVENTS ...............................................19 85 5. CONFORMANCE AND USAGE REQUIREMENTS ...............................20 86 6. SECURITY CONSIDERATIONS ..........................................21 87 6.1 Forgery ........................................................21 88 6.2 Privacy ........................................................21 89 6.3 Non-Repudiation ................................................22 90 6.4 Mail Bombing ...................................................22 91 7. COLLECTED GRAMMAR ................................................23 92 8. GUIDELINES FOR GATEWAYING MDNS ...................................25 93 8.1 Gatewaying from other mail systems to MDNs .....................25 94 8.2 Gatewaying from MDNs to other mail systems .....................25 95 8.3 Gatewaying of MDN-requests to other mail systems ...............26 96 9. EXAMPLE ..........................................................27 97 10. IANA CONSIDERATIONS ..............................................28 98 10.1 Disposition-Notification-Options header parameter names .......28 99 10.2 Disposition modifier names ....................................28 100 10.3 MDN extension field names .....................................29 101 11. ACKNOWLEDGMENTS ..................................................30 102 12. NORMATIVE REFERENCES .............................................31 103 13. INFORMATIVE REFERENCES ...........................................31 104 14. INTELLECTUAL PROPERTY NOTICE .....................................32 105 15. COPYRIGHT NOTICE .................................................32 106 16. AUTHORS' ADDRESSES ...............................................33 107 17. APPENDIX A - CHANGES FROM RFC2298 ................................34 108 1. Introduction 110 This memo defines a [RFC-MIME-MEDIA] content-type for message 111 disposition notifications (MDNs). An MDN can be used to notify the 112 sender of a message of any of several conditions that may occur after 113 successful delivery, such as display of the message contents, printing 114 of the 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]. 120 This memo defines the format of the notifications and the [RFC-MSGFMT] 121 headers used to request them. 123 1.1 Purposes 125 The MDNs defined in this memo are expected to serve several purposes: 127 (a) Inform human beings of the disposition of messages after 128 successful delivery, in a manner that is largely independent of 129 human language; 131 (b) Allow mail user agents to keep track of the disposition of 132 messages sent, by associating returned MDNs with earlier message 133 transmissions; 135 (c) Convey disposition notification requests and disposition 136 notifications between Internet Mail and "foreign" mail systems 137 via a gateway; 139 (d) Allow "foreign" notifications to be tunneled through a MIME- 140 capable message system and back into the original messaging 141 system that issued the original notification, or even to a third 142 messaging system; 144 (e) Allow language-independent, yet reasonably precise, indications 145 of the disposition of a message to be delivered. 147 1.2 Requirements 149 These purposes place the following constraints on the notification 150 protocol: 152 (a) It must be readable by humans, as well as being machine-parsable. 154 (b) It must provide enough information to allow message senders (or 155 their user agents) to unambiguously associate an MDN with the 156 message that was sent and the original recipient address for 157 which the MDN was issued (if such information is available), 158 even if the message was forwarded to another recipient address. 160 (c) It must also be able to describe the disposition of a message 161 independent of any particular human language or of the 162 terminology of any particular mail system. 164 (d) The specification must be extensible in order to accommodate 165 future requirements. 167 1.3 Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC-KEYWORDS]. 173 All syntax descriptions use the ABNF specified by [RFC-MSGFMT], in 174 which the lexical tokens (used below) are defined: "atom", "CRLF", 175 "mailbox", "msg-id", and "text". The following lexical tokens are 176 defined in the definition of the Content-Type header in [RFC-MIME- 177 BODY]: "attribute" and "value". 179 2. Requesting Message Disposition Notifications 181 Message disposition notifications are requested by including a 182 Disposition-Notification-To header in the message. Further 183 information to be used by the recipient's MUA in generating the MDN 184 may be provided by also including Original-Recipient and/or 185 Disposition-Notification-Options headers in the message. 187 2.1 The Disposition-Notification-To Header 189 A request for the receiving user agent to issue message disposition 190 notifications is made by placing a Disposition-Notification-To header 191 into the message. The syntax of the header is 193 mdn-request-header = "Disposition-Notification-To" ":" 194 mailbox *("," mailbox) 196 The presence of a Disposition-Notification-To header in a message is 197 merely a request for an MDN. The recipients' user agents are always 198 free to silently ignore such a request. Alternatively, an explicit 199 denial of the request for information about the disposition of the 200 message may be sent using the "denied" disposition in an MDN. 202 An MDN MUST NOT itself have a Disposition-Notification-To header. An 203 MDN MUST NOT be generated in response to an MDN. 205 A user agent MUST NOT issue more than one MDN on behalf of each 206 particular recipient. That is, once an MDN has been issued on behalf 207 of a recipient, no further MDNs may be issued on behalf of that 208 recipient, even if another disposition is performed on the message. 209 However, if a message is forwarded, an MDN may have been issued for 210 the recipient doing the forwarding and the recipient of the forwarded 211 message may also cause an MDN to be generated. 213 While Internet standards normally do not specify the behavior of user 214 interfaces, it is strongly recommended that the user agent obtain the 215 user's consent before sending an MDN. This consent could be obtained 216 for each message through some sort of prompt or dialog box, or 217 globally through the user's setting of a preference. The user might 218 also indicate globally that MDNs are to never be sent or that a 219 "denied" MDN is always sent in response to a request for an MDN. 221 MDNs SHOULD NOT be sent automatically if the address in the 222 Disposition-Notification-To header differs from the address in the 223 Return-Path header (see [RFC-MSGFMT]). In this case, confirmation 224 from the user SHOULD be obtained, if possible. If obtaining consent 225 is not possible (e.g., because the user is not online at the time), 226 then an MDN SHOULD NOT be sent. 228 Confirmation from the user SHOULD be obtained (or no MDN sent) if 229 there is no Return-Path header in the message, or if there is more 230 than one distinct address in the Disposition-Notification-To header. 232 The comparison of the addresses should be done using only the addr- 233 spec (local-part "@" domain) portion, excluding any phrase and route. 234 The comparison MUST be case-sensitive for the local-part and case- 235 insensitive for the domain part. 237 If the message contains more than one Return-Path header, the 238 implementation may pick one to use for the comparison, or treat the 239 situation as a failure of the comparison. 241 The reason for not automatically sending an MDN if the comparison 242 fails or more than one address is specified is to reduce the 243 possibilities for mail loops and use of MDNs for mail bombing. 245 A message that contains a Disposition-Notification-To header SHOULD 246 also contain a Message-ID header as specified in [RFC-MSGFMT]. This 247 will permit automatic correlation of MDNs with their original messages 248 by user agents. 250 If it is desired to request message disposition notifications for some 251 recipients and not others, two copies of the message should be sent, 252 one with an Disposition-Notification-To header and one without. Many 253 of the other headers of the message (e.g., To, Cc) will be the same in 254 both copies. The recipients in the respective message envelopes 255 determine for whom message disposition notifications are requested and 256 for whom they are not. If desired, the Message-ID header may be the 257 same in both copies of the message. Note that there are other 258 situations (e.g., Bcc) in which it is necessary to send multiple 259 copies of a message with slightly different headers. The combination 260 of such situations and the need to request MDNs for a subset of all 261 recipients may result in more than two copies of a message being sent, 262 some with a Disposition-Notification-To header and some without. 264 Messages posted to newsgroups SHOULD NOT have a Disposition- 265 Notification-To header. 267 2.2 The Disposition-Notification-Options Header 269 Future extensions to this specification may require that information 270 be supplied to the recipient's MUA for additional control over how and 271 what MDNs are generated. The Disposition-Notification-Options header 272 provides an extensible mechanism for such information. The syntax of 273 this header is 275 Disposition-Notification-Options = 276 "Disposition-Notification-Options" ":" 277 disposition-notification-parameters 279 disposition-notification-parameters = parameter *(";" parameter) 281 parameter = attribute "=" importance "," value *("," value) 283 importance = "required" / "optional" 285 An importance of "required" indicates that interpretation of the 286 parameter is necessary for proper generation of an MDN in response to 287 this request. If a MUA does not understand the meaning of the 288 parameter, it MUST NOT generate an MDN with any disposition type other 289 than "failed" in response to the request. An importance of "optional" 290 indicates that a MUA that does not understand the meaning of this 291 parameter MAY generate an MDN in response anyway, ignoring the value 292 of the parameter. 294 No parameters are defined in this specification. Parameters may be 295 defined in the future by later revisions or extensions to this 296 specification. Parameter attribute names beginning with "X-" will 297 never be defined as standard names; such names are reserved for 298 experimental use. MDN parameter names not beginning with "X-" MUST be 299 registered with the Internet Assigned Numbers Authority (IANA) and 300 described in a standards-track RFC or an experimental RFC approved by 301 the IESG. (See Section 10 for a registration form.) 303 If a required parameter is not understood or contains some sort of 304 error, the receiving MUA SHOULD issue an MDN with a disposition type 305 of "failed" (see Section 3.2.6) and include a Failure field (see 306 Section 3.2.7) that further describes the problem. MDNs with the 307 disposition type of "failed" and a "Failure" field MAY also be 308 generated when other types of errors are detected in the parameters of 309 the Disposition-Notification-Options header. 311 However, an MDN with a disposition type of "failed" MUST NOT be 312 generated if the user has indicated a preference that MDNs are not to 313 be sent. If user consent would be required for an MDN of some other 314 disposition type to be sent, user consent SHOULD also be obtained 315 before sending an MDN with a disposition type of "failed". 317 2.3 The Original-Recipient Header 319 Since electronic mail addresses may be rewritten while the message is 320 in transit, it is useful for the original recipient address to be made 321 available by the delivering MTA. The delivering MTA may be able to 322 obtain this information from the ORCPT parameter of the SMTP RCPT TO 323 command, as defined in [RFC-DSN-SMTP]. 325 [RFC-DSN-SMTP] is amended as follows: If the ORCPT information is 326 available, the delivering MTA SHOULD insert an Original-Recipient 327 header at the beginning of the message (along with the Return-Path 328 header). The delivering MTA MAY delete any other Original-Recipient 329 headers that occur in the message. The syntax of this header is as 330 follows 332 original-recipient-header = 333 "Original-Recipient" ":" address-type ";" generic-address 335 The address-type and generic-address token are as specified in the 336 description of the Original-Recipient field in section 3.2.3. 338 The purpose of carrying the original recipient information and 339 returning it in the MDN is to permit automatic correlation of MDNs 340 with the original message on a per-recipient basis. 342 2.4 Use with the Message/Partial Content Type 344 The use of the headers Disposition-Notification-To, Disposition- 345 Notification-Options, and Original-Recipient with the MIME 346 message/partial content type ([RFC-MIME-MEDIA]) requires further 347 definition. 349 When a message is segmented into two or more message/partial 350 fragments, the three headers mentioned in the above paragraph SHOULD 351 be placed in the "inner" or "enclosed" message (using the terms of 352 [RFC-MIME-MEDIA]). These headers SHOULD NOT be used in the headers of 353 any of the fragments themselves. 355 When the multiple message/partial fragments are reassembled, the 356 following applies. If these headers occur along with the other 357 headers of a message/partial fragment message, they pertain to an MDN 358 to be generated for the fragment. If these headers occur in the 359 headers of the "inner" or "enclosed" message (using the terms of [RFC- 360 MIME-MEDIA]), they pertain to an MDN to be generated for the 361 reassembled message. Section 5.2.2.1 of [RFC-MIME-MEDIA]) is amended 362 to specify that, in addition to the headers specified there, the three 363 headers described in this specification are to be appended, in order, 364 to the headers of the reassembled message. Any occurrences of the 365 three headers defined here in the headers of the initial enclosing 366 message must not be copied to the reassembled message. 368 3. Format of a Message Disposition Notification 370 A message disposition notification is a MIME message with a top-level 371 content-type of multipart/report (defined in [RFC-REPORT]). When 372 multipart/report content is used to transmit an MDN: 374 (a) The report-type parameter of the multipart/report content is 375 "disposition-notification". 377 (b) The first component of the multipart/report contains a human- 378 readable explanation of the MDN, as described in [RFC-REPORT]. 380 (c) The second component of the multipart/report is of content-type 381 message/disposition-notification, described in section 3.1 of 382 this document. 384 (d) If the original message or a portion of the message is to be 385 returned to the sender, it appears as the third component of the 386 multipart/report. The decision of whether or not to return the 387 message or part of the message is up to the MUA generating the 388 MDN. However, in the case of encrypted messages requesting MDNs, 389 encrypted message text MUST be returned, if it is returned at 390 all, only in its original encrypted form. 392 NOTE: For message disposition notifications gatewayed from foreign 393 systems, the headers of the original message may not be available. 394 In this case the third component of the MDN may be omitted, or it 395 may contain "simulated" [RFC-MSGFMT] headers that contain 396 equivalent information. In particular, it is very desirable to 397 preserve the subject and date fields from the original message. 399 The MDN MUST be addressed (in both the message header and the 400 transport envelope) to the address(es) from the Disposition- 401 Notification-To header from the original message for which the MDN is 402 being generated. 404 The From field of the message header of the MDN MUST contain the 405 address of the person for whom the message disposition notification is 406 being issued. 408 The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be 409 null (<>), specifying that no Delivery Status Notification messages or 410 other messages indicating successful or unsuccessful delivery are to 411 be sent in response to an MDN. 413 A message disposition notification MUST NOT itself request an MDN. 414 That is, it MUST NOT contain a Disposition-Notification-To header. 416 The Message-ID header (if present) for an MDN MUST be different from 417 the Message-ID of the message for which the MDN is being issued. 419 A particular MDN describes the disposition of exactly one message for 420 exactly one recipient. Multiple MDNs may be generated as a result of 421 one message submission, one per recipient. However, due to the 422 circumstances described in Section 2.1, MDNs may not be generated for 423 some recipients for which MDNs were requested. 425 3.1 The message/disposition-notification content-type 427 The message/disposition-notification content-type is defined as 428 follows: 430 MIME type name: message 432 MIME subtype name: disposition-notification 434 Optional parameters: none 436 Encoding considerations: "7bit" encoding is sufficient and 437 MUST be used to maintain readability 438 when viewed by non-MIME mail readers. 440 Security considerations: discussed in section 6 of this memo. 442 The message/disposition-notification report type for use in the 443 multipart/report is "disposition-notification". 445 The body of a message/disposition-notification consists of one or more 446 "fields" formatted according to the ABNF of [RFC-MSGFMT] header 447 "fields". The syntax of the message/disposition-notification content 448 is as follows: 450 disposition-notification-content = [ reporting-ua-field CRLF ] 451 [ mdn-gateway-field CRLF ] 452 [ original-recipient-field CRLF ] 453 final-recipient-field CRLF 454 [ original-message-id-field CRLF ] 455 disposition-field CRLF 456 *( failure-field CRLF ) 457 *( error-field CRLF ) 458 *( warning-field CRLF ) 459 *( extension-field CRLF ) 461 3.1.1 General conventions for fields 463 Since these fields are defined according to the rules of [RFC-MSGFMT], 464 the same conventions for continuation lines and comments apply. 465 Notification fields may be continued onto multiple lines by beginning 466 each additional line with a SPACE or HTAB. Text that appears in 467 parentheses is considered a comment and not part of the contents of 468 that notification field. Field names are case-insensitive, so the 469 names of notification fields may be spelled in any combination of 470 upper and lower case letters. Comments in notification fields may use 471 the "encoded-word" construct defined in [RFC-MIME-HEADER]. 473 3.1.2 "*-type" subfields 475 Several fields consist of a "-type" subfield, followed by a semi- 476 colon, followed by "*text". For these fields, the keyword used in the 477 address-type or MTA-type subfield indicates the expected format of the 478 address or MTA-name that follows. 480 The "-type" subfields are defined as follows: 482 (a) An "address-type" specifies the format of a mailbox address. For 483 example, Internet Mail addresses use the "rfc822" address-type. 485 address-type = atom 487 (b) An "MTA-name-type" specifies the format of a mail transfer agent 488 name. For example, for an SMTP server on an Internet host, the 489 MTA name is the domain name of that host, and the "dns" MTA-name- 490 type is used. 492 mta-name-type = atom 494 Values for address-type and mta-name-type are case-insensitive. Thus 495 address-type values of "RFC822" and "rfc822" are equivalent. 497 The Internet Assigned Numbers Authority (IANA) maintains a registry of 498 address-type and mta-name-type values, along with descriptions of the 499 meanings of each, or a reference to one or more specifications that 500 provide such descriptions. (The "rfc822" address-type is defined in 501 [RFC-DSN-SMTP].) Registration forms for address-type and mta-name-type 502 appear in [RFC-DSN-FORMAT]. 504 3.2 Message/disposition-notification Fields 506 3.2.1 The Reporting-UA field 508 reporting-ua-field = "Reporting-UA" ":" ua-name 509 [ ";" ua-product ] 511 ua-name = *text 513 ua-product = *text 515 The Reporting-UA field is defined as follows: 517 A MDN describes the disposition of a message after it has been 518 delivered to a recipient. In all cases, the Reporting-UA is the MUA 519 that performed the disposition described in the MDN. This field is 520 optional, but recommended. For Internet Mail user agents, it is 521 recommended that this field contain both: the DNS name of the 522 particular instance of the MUA that generated the MDN, and the name of 523 the product. For example, 525 Reporting-UA: pc.example.com; Foomail 97.1 527 If the reporting MUA consists of more than one component (e.g., a base 528 program and plug-ins), this may be indicated by including a list of 529 product names. 531 3.2.2 The MDN-Gateway field 533 The MDN-Gateway field indicates the name of the gateway or MTA that 534 translated a foreign (non-Internet) message disposition notification 535 into this MDN. This field MUST appear in any MDN that was translated 536 by a gateway from a foreign system into MDN format, and MUST NOT 537 appear otherwise. 539 mdn-gateway field = "MDN-Gateway" ":" mta-name-type ";" mta-name 541 mta-name = *text 543 For gateways into Internet Mail, the MTA-name-type will normally be 544 "smtp", and the mta-name will be the Internet domain name of the 545 gateway. 547 3.2.3 Original-Recipient field 549 The Original-Recipient field indicates the original recipient address 550 as specified by the sender of the message for which the MDN is being 551 issued. For Internet Mail messages the value of the 552 Original-Recipient field is obtained from the Original-Recipient 553 header from the message for which the MDN is being generated. If 554 there is no Original-Recipient header in the message, then the 555 Original-Recipient field MUST be omitted, unless the same information 556 is reliably available some other way. If there is an Original- 557 Recipient header in the original message (or original recipient 558 information is reliably available some other way), then the Original- 559 Recipient field must be supplied. If there is more than one Original- 560 Recipient header in the message, the MUA may choose the one to use or 561 act as if no Original-Recipient header is present. 563 original-recipient-field = 564 "Original-Recipient" ":" address-type ";" 565 generic-address 567 generic-address = *text 569 The address-type field indicates the type of the original recipient 570 address. If the message originated within the Internet, the address- 571 type field will normally be "rfc822", and the address will be 572 according to the syntax specified in [RFC-MSGFMT]. The value 573 "unknown" should be used if the Reporting MUA cannot determine the 574 type of the original recipient address from the message envelope. This 575 address is the same as that provided by the sender and can be used to 576 automatically correlate MDN reports with original messages on a per 577 recipient basis. 579 3.2.4 Final-Recipient field 581 The Final-Recipient field indicates the recipient for which the MDN is 582 being issued. This field MUST be present. 584 The syntax of the field is as follows: 586 final-recipient-field = 587 "Final-Recipient" ":" address-type ";" generic-address 589 The generic-address subfield of the Final-Recipient field MUST contain 590 the mailbox address of the recipient (from the From header of the MDN) 591 as it was when the MDN was generated by the MUA. 593 The Final-Recipient address may differ from the address originally 594 provided by the sender, because it may have been transformed during 595 forwarding and gatewaying into a totally unrecognizable mess. However, 596 in the absence of the optional Original-Recipient field, the Final- 597 Recipient field and any returned content may be the only information 598 available with which to correlate the MDN with a particular message 599 recipient. 601 The address-type subfield indicates the type of address expected by 602 the reporting MTA in that context. Recipient addresses obtained via 603 SMTP will normally be of address-type "rfc822". 605 Since mailbox addresses (including those used in the Internet) may be 606 case sensitive, the case of alphabetic characters in the address MUST 607 be preserved. 609 3.2.5 Original-Message-ID field 611 The Original-Message-ID field indicates the message-ID of the message 612 for which the MDN is being issued. It is obtained from the Message-ID 613 header of the message for which the MDN is issued. This field MUST be 614 present if the original message contained a Message-ID header. The 615 syntax of the field is 617 original-message-id-field = 618 "Original-Message-ID" ":" msg-id 620 The msg-id token is as specified in [RFC-MSGFMT]. 622 3.2.6 Disposition field 624 The Disposition field indicates the action performed by the Reporting- 625 MUA on behalf of the user. This field MUST be present. 627 The syntax for the Disposition field is: 629 disposition-field = 630 "Disposition" ":" disposition-mode ";" 631 disposition-type 632 [ "/" disposition-modifier 633 *( "," disposition-modifier ) ] 635 disposition-mode = action-mode "/" sending-mode 637 action-mode = "manual-action" / "automatic-action" 639 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 641 disposition-type = "displayed" 642 / "deleted" 644 disposition-modifier = "error" 645 / disposition-modifier-extension 647 disposition-modifier-extension = atom 649 The disposition-mode, disposition-type and disposition-modifier may be 650 spelled in any combination of upper and lower case characters. 652 3.2.6.1 Disposition modes 654 The following disposition modes are defined: 656 "manual-action" The disposition described by the disposition 657 type was a result of an explicit instruction 658 by the user rather than some sort of 659 automatically performed action. 661 "automatic-action" The disposition described by the disposition 662 type was a result of an automatic action, 663 rather than an explicit instruction by the 664 user for this message. 666 "Manual-action" and "automatic-action" are mutually exclusive. One or 667 the other MUST be specified. 669 "MDN-sent-manually" The user explicitly gave permission for this 670 particular MDN to be sent. 672 "MDN-sent-automatically" 673 The MDN was sent because the MUA had 674 previously been configured to do so 675 automatically. 677 "MDN-sent-manually" and "MDN-sent-automatically" are mutually 678 exclusive. One or the other MUST be specified. 680 3.2.6.2 Disposition types 682 The following disposition-types are defined: 684 "displayed" The message has been displayed by the MUA 685 to someone reading the recipient's mailbox. 686 There is no guarantee that the content has 687 been read or understood. 689 "deleted" The message has been deleted. The 690 recipient may or may not have seen the 691 message. The recipient might "undelete" 692 the message at a later time and read the 693 message. 695 3.2.6.3 Disposition modifiers 697 Only the extension disposition modifiers is defined: 699 disposition-modifier-extension 700 Disposition modifiers may be defined 701 in the future by later revisions of 702 or extensions to this specification. 703 Disposition value names beginning with "X-" 704 will never be defined as standard values; 705 such names are reserved for experimental 706 use. MDN disposition value names NOT 707 beginning with "X-" MUST be registered with 708 the Internet Assigned Numbers Authority 709 (IANA) and described in a standards-track 710 RFC or an experimental RFC approved by the 711 IESG. (See Section 10 for a registration 712 form.) MDNs with disposition modifier 713 names not understood by the receiving MUA 714 MAY be silently ignored or placed in the 715 user's mailbox without special 716 interpretation. They MUST not cause any 717 error message to be sent to the sender of 718 the MDN. 720 If an MUA developer does not wish to register the meanings of such 721 disposition modifier extensions, "X-" modifiers may be used for this 722 purpose. To avoid name collisions, the name of the MUA implementation 723 should follow the "X-", (e.g. "X-Foomail-"). 725 It is not required that a MUA be able to generate all of the possible 726 values of the Disposition field. 728 A user agent MUST NOT issue more than one MDN on behalf of each 729 particular recipient. That is, once an MDN has been issued on 730 behalf of a recipient, no further MDNs may be issued on behalf of 731 that recipient, even if another disposition is performed on the 732 message. However, if a message is forwarded, a "dispatched" MDN may 733 be issued for the recipient doing the forwarding and the recipient of 734 the forwarded message may also cause an MDN to be generated. 736 3.2.7 Failure, Error and Warning fields 738 The Failure, Error and Warning fields are used to supply additional 739 information in the form of text messages when the "failure" 740 disposition type, "error" disposition modifier, and/or the "warning" 741 disposition modifier appear. The syntax is 743 failure-field = "Failure" ":" *text 745 error-field = "Error" ":" *text 747 warning-field = "Warning" ":" *text 749 3.3 Extension-fields 751 Additional MDN fields may be defined in the future by later revisions 752 or extensions to this specification. Extension-field names beginning 753 with "X-" will never be defined as standard fields; such names are 754 reserved for experimental use. MDN field names NOT beginning with 755 "X-" MUST be registered with the Internet Assigned Numbers Authority 756 (IANA) and described in a standards-track RFC or an experimental RFC 757 approved by the IESG. (See Section 10 for a registration form.) 759 MDN Extension-fields may be defined for the following reasons: 761 (a) To allow additional information from foreign disposition reports 762 to be tunneled through Internet MDNs. The names of such MDN 763 fields should begin with an indication of the foreign environment 764 name (e.g. X400-Physical-Forwarding-Address). 766 (b) To allow transmission of diagnostic information that is specific 767 to a particular mail user agent (MUA). The names of such MDN 768 fields should begin with an indication of the MUA implementation 769 that produced the MDN. (e.g. Foomail-information). 771 If an application developer does not wish to register the meanings of 772 such extension fields, "X-" fields may be used for this purpose. To 773 avoid name collisions, the name of the application implementation 774 should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-Foomail-EDI- 775 info"). 777 4. Timeline of events 779 The following timeline shows when various events in the processing of 780 a message and generation of MDNs take place: 782 -- User composes message 784 -- User tells MUA to send message 786 -- MUA passes message to MTA (original recipient information passed 787 along) 789 -- MTA sends message to next MTA 791 -- Final MTA receives message 793 -- Final MTA delivers message to MUA (possibly generating a DSN) 795 -- MUA performs automatic processing and generates corresponding MDNs 796 ("dispatched", "processed", "deleted", "denied" or "failed" 797 disposition type with "automatic-action" and "MDN-sent- 798 automatically" disposition modes) 800 -- MUA displays list of messages to user 802 -- User selects a message and requests that some action be performed 803 on it. 805 -- MUA performs requested action and, with user's permission, sends 806 an appropriate MDN ("displayed", "dispatched", "processed", 807 "deleted", "denied" or "failed" disposition type with "manual- 808 action" and "MDN-sent-manually" or "MDN-sent-automatically" 809 disposition mode). 811 -- User possibly performs other actions on message, but no further 812 MDNs are generated. 814 5. Conformance and Usage Requirements 816 A MUA or gateway conforms to this specification if it generates MDNs 817 according to the protocol defined in this memo. It is not necessary 818 to be able to generate all of the possible values of the Disposition 819 field. 821 MUAs and gateways MUST NOT generate the Original-Recipient field of an 822 MDN unless the mail protocols provide the address originally specified 823 by the sender at the time of submission. Ordinary SMTP does not make 824 that guarantee, but the SMTP extension defined in [RFC-DSN-SMTP] 825 permits such information to be carried in the envelope if it is 826 available. The Original-Recipient header defined in this document 827 provides a way for the MTA to pass the original recipient address to 828 the MUA. 830 Each sender-specified recipient address may result in more than one 831 MDN. If an MDN is requested for a recipient that is forwarded to 832 multiple recipients of an "alias" (as defined in [RFC-DSN-SMTP], 833 section 6.2.7.3), each of the recipients may issue an MDN. 835 Successful distribution of a message to a mailing list exploder SHOULD 836 be considered final disposition of the message. A mailing list 837 exploder MAY issue an MDN with a disposition type of "processed" and 838 disposition modes of "automatic-action" and "MDN-sent-automatically" 839 indicating that the message has been forwarded to the list. In this 840 case, the request for MDNs is not propagated to the members of the 841 list. 843 Alternatively, the mailing list exploder MAY issue no MDN and 844 propagate the request for MDNs to all members of the list. The latter 845 behavior is not recommended for any but small, closely knit lists, as 846 it might cause large numbers of MDNs to be generated and may cause 847 confidential subscribers to the list to be revealed. The mailing list 848 exploder MAY also direct MDNs to itself, correlate them, and produce a 849 report to the original sender of the message. 851 This specification places no restrictions on the processing of MDNs 852 received by user agents or mailing lists. 854 6. Security Considerations 856 The following security considerations apply when using MDNs: 858 6.1 Forgery 860 MDNs may be forged as easily as ordinary Internet electronic mail. 861 User agents and automatic mail handling facilities (such as mail 862 distribution list exploders) that wish to make automatic use of MDNs 863 should take appropriate precautions to minimize the potential damage 864 from denial-of-service attacks. 866 Security threats related to forged MDNs include the sending of: 868 (a) A falsified disposition notification when the indicated 869 disposition of the message has not actually occurred, 871 (b) Unsolicited MDNs 873 6.2 Privacy 875 Another dimension of security is privacy. There may be cases in which 876 a message recipient does not wish the disposition of messages 877 addressed to him to be known or is concerned that the sending of MDNs 878 may reveal other sensitive information (e.g., when the message was 879 read). In this situation, it is acceptable for the MUA to issue 880 "denied" MDNs or to silently ignore requests for MDNs. 882 If the Disposition-Notification-To header is passed on unmodified when 883 a message is distributed to the subscribers of a mailing list, the 884 subscribers to the list may be revealed to the sender of the original 885 message by the generation of MDNs. 887 Headers of the original message returned in part 3 of the 888 multipart/report could reveal confidential information about host 889 names and/or network topology inside a firewall. 891 An unencrypted MDN could reveal confidential information about an 892 encrypted message, especially if all or part of the original message 893 is returned in part 3 of the multipart/report. Encrypted MDNs are not 894 defined in this specification. 896 In general, any optional MDN field may be omitted if the Reporting MUA 897 site or user determines that inclusion of the field would impose too 898 great a compromise of site confidentiality. The need for such 899 confidentiality must be balanced against the utility of the omitted 900 information in MDNs. 902 In some cases, someone with access to the message stream may use the 903 MDN request mechanism to monitor the mail reading habits of a target. 904 If the target is known to generate MDN reports, they could add a 905 disposition-notification-to field containing the envelope from address 906 along with a source route. The source route is ignored in the 907 comparison so the addresses will always match. But if the source route 908 is honored when the notification is sent it could direct the message 909 to some other destination. This risk can be minimized by not sending 910 MDN's automatically. 912 6.3 Non-Repudiation 914 MDNs do not provide non-repudiation with proof of delivery. Within the 915 framework of today's Internet Mail, the MDNs defined in this document 916 provide valuable information to the mail user; however, MDNs can not 917 be relied upon as a guarantee that a message was or was not seen by 918 the recipient. Even if MDNs are not actively forged, they may be lost 919 in transit. The recipient may bypass the MDN issuing mechanism in 920 some manner. 922 One possible solution for this purpose can be found in RFC 2634. [SEC- 923 SERVICES] 925 6.4 Mail Bombing 927 The MDN request mechanism introduces an additional way of mailbombing 928 a mailbox. The MDN request notification provides an address to which 929 MDN's should be sent. It is possible for an attacking agent to send a 930 potentially large set of messages to otherwise unsuspecting third 931 party recipients with a false "disposition-notification-to:" address. 932 Automatic, or simplistic processing of such requests would result in a 933 flood of MDN notifications to the target of the attack. Such an 934 attack could overrun the capacity of the targeted mailbox and deny 935 service. 937 For that reason, MDN's SHOULD NOT be sent automatically where the 938 "disposition-notification-to:" address is different from the envelope 939 MAIL FROM address. See section 2.1 for further discussion. 941 7. Collected Grammar 943 NOTE: The following lexical tokens are defined in [RFC-MSGFMT]: 944 atom, CRLF, mailbox, msg-id, text. The definitions of attribute 945 and value are as in the definition of the Content-Type header in 946 [RFC-MIME-BODY]. 948 Message headers: 950 mdn-request-header = 951 "Disposition-Notification-To" ":" 952 mailbox *("," mailbox) 954 Disposition-Notification-Options = 955 "Disposition-Notification-Options" ":" 956 disposition-notification-parameters 958 disposition-notification-parameters = 959 parameter *(";" parameter) 961 parameter = attribute "=" importance "," value *("," value) 963 importance = "required" / "optional" 965 original-recipient-header = 966 "Original-Recipient" ":" address-type ";" generic-address 968 Report content: 970 disposition-notification-content = 971 [ reporting-ua-field CRLF ] 972 [ mdn-gateway-field CRLF ] 973 [ original-recipient-field CRLF ] 974 final-recipient-field CRLF 975 [ original-message-id-field CRLF ] 976 disposition-field CRLF 977 *( failure-field CRLF ) 978 *( error-field CRLF ) 979 *( warning-field CRLF ) 980 *( extension-field CRLF ) 982 address-type = atom 984 mta-name-type = atom 986 reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ] 988 ua-name = *text 990 ua-product = *text 992 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 994 mta-name = *text 995 original-recipient-field 996 = "Original-Recipient" ":" address-type ";" 997 generic-address 999 generic-address = *text 1001 final-recipient-field = 1002 "Final-Recipient" ":" address-type ";" generic-address 1004 disposition-field = 1005 "Disposition" ":" disposition-mode ";" 1006 disposition-type 1007 [ "/" disposition-modifier 1008 *( "," disposition-modifier ) ] 1010 disposition-mode = action-mode "/" sending-mode 1012 action-mode = "manual-action" / "automatic-action" 1014 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 1016 disposition-type = "displayed" 1017 / "deleted" 1019 disposition-modifier = "error" / disposition-modifier-extension 1021 disposition-modifier-extension = atom 1023 original-message-id-field = "Original-Message-ID" ":" msg-id 1025 failure-field = "Failure" ":" *text 1027 error-field = "Error" ":" *text 1029 warning-field = "Warning" ":" *text 1031 extension-field = extension-field-name ":" *text 1033 extension-field-name = atom 1035 8. Guidelines for Gatewaying MDNs 1037 NOTE: This section provides non-binding recommendations for the 1038 construction of mail gateways that wish to provide semi-transparent 1039 disposition notifications between the Internet and another electronic 1040 mail system. Specific MDN gateway requirements for a particular pair 1041 of mail systems may be defined by other documents. 1043 8.1 Gatewaying from other mail systems to MDNs 1045 A mail gateway may issue an MDN to convey the contents of a "foreign" 1046 disposition notification over Internet Mail. When there are 1047 appropriate mappings from the foreign notification elements to MDN 1048 fields, the information may be transmitted in those MDN fields. 1049 Additional information (such as might be needed to tunnel the foreign 1050 notification through the Internet) may be defined in extension MDN 1051 fields. (Such fields should be given names that identify the foreign 1052 mail protocol, e.g. X400-* for X.400 protocol elements) 1054 The gateway must attempt to supply reasonable values for the 1055 Reporting-UA, Final-Recipient, and Disposition fields. These will 1056 normally be obtained by translating the values from the foreign 1057 notification into their Internet-style equivalents. However, some 1058 loss of information is to be expected. 1060 The sender-specified recipient address, and the original message-id, 1061 if present in the foreign notification, should be preserved in the 1062 Original-Recipient and Original-Message-ID fields. 1064 The gateway should also attempt to preserve the "final" recipient 1065 address from the foreign system. Whenever possible, foreign protocol 1066 elements should be encoded as meaningful printable ASCII strings. 1068 For MDNs produced from foreign disposition notifications, the name of 1069 the gateway MUST appear in the MDN-Gateway field of the MDN. 1071 8.2 Gatewaying from MDNs to other mail systems 1073 It may be possible to gateway MDNs from the Internet into a foreign 1074 mail system. The primary purpose of such gatewaying is to convey 1075 disposition information in a form that is usable by the destination 1076 system. A secondary purpose is to allow "tunneling" of MDNs through 1077 foreign mail systems, in case the MDN may be gatewayed back into the 1078 Internet. 1080 In general, the recipient of the MDN (i.e., the sender of the original 1081 message) will want to know, for each recipient: the closest available 1082 approximation to the original recipient address, and the disposition 1083 (displayed, printed, etc.). 1085 If possible, the gateway should attempt to preserve the Original- 1086 Recipient address and Original-Message-ID (if present), in the 1087 resulting foreign disposition report. 1089 If it is possible to tunnel an MDN through the destination 1090 environment, the gateway specification may define a means of 1091 preserving the MDN information in the disposition reports used by that 1092 environment. 1094 8.3 Gatewaying of MDN-requests to other mail systems 1096 By use of the separate disposition-notification-to request header, 1097 this specification offers a richer functionality than most if not all 1098 other email systems. In other most email systems, the notification 1099 recipient is identical to the message sender as indicated in the 1100 "from" address. There are two interesting cases when gatewaying into 1101 such systems: 1103 1) If the address in the disposition-notification-to header is 1104 identical to the address in the SMTP "MAIL FROM", the expected 1105 behavior will result even if the disposition-notification-to 1106 information is lost. Systems should propagate the MDN 1107 request. 1109 2) If the address in the disposition-notification-to header is 1110 different to the address in the SMTP "MAIL FROM", gatewaying 1111 into a foreign system without a separate notification address 1112 will result in unintended behavior. This is especially 1113 important when the message arrive via mailing list expansion 1114 software that may specifically replace the SMTP "MAIL FROM" 1115 address to an alternate address. In such cases, the MDN 1116 request should not be gatewayed, and should be silently 1117 dropped. This is consistent with other forms of non-support 1118 for MDN. 1120 9. Example 1122 NOTE: This example is provided as illustration only, and is not 1123 considered part of the MDN protocol specification. If the example 1124 conflicts with the protocol definition above, the example is wrong. 1126 Likewise, the use of *-type subfield names or extension fields in this 1127 example is not to be construed as a definition for those type names or 1128 extension fields. 1130 This is an MDN issued after a message has been displayed to the user 1131 of an Internet Mail user agent. 1133 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 1134 From: Joe Recipient 1135 Message-Id: <199509200019.12345@example.com> 1136 Subject: Disposition notification 1137 To: Jane Sender 1138 MIME-Version: 1.0 1139 Content-Type: multipart/report; report-type=disposition-notification; 1140 boundary="RAA14128.773615765/example.com" 1142 --RAA14128.773615765/example.com 1144 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe 1145 Recipient with subject "First draft of 1146 report" has been displayed. This is no guarantee that the message has 1147 been read or understood. 1149 --RAA14128.773615765/example.com 1150 content-type: message/disposition-notification 1152 Reporting-UA: joes-pc.cs.example.com; Foomail 97.1 1153 Original-Recipient: rfc822;Joe_Recipient@example.com 1154 Final-Recipient: rfc822;Joe_Recipient@example.com 1155 Original-Message-ID: <199509192301.23456@example.org> 1156 Disposition: manual-action/MDN-sent-manually; displayed 1158 --RAA14128.773615765/example.com 1159 content-type: message/rfc822 1161 [original message optionally goes here] 1163 --RAA14128.773615765/example.com-- 1165 10. IANA Considerations 1167 This document specifies three types of parameters that must be 1168 registered with the Internet Assigned Numbers Authority (IANA). 1170 The forms below are for use when registering a new parameter name for 1171 the Disposition-Notification-Options header, a new disposition 1172 modifier name, or a new MDN extension field. Each piece of 1173 information required by a registration form may be satisfied either by 1174 providing the information on the form itself, or by including a 1175 reference to a published, publicly available specification that 1176 includes the necessary information. IANA MAY reject registrations 1177 because of incomplete registration forms or incomplete specifications. 1179 To register, complete the applicable form below and send it via 1180 electronic mail to . 1182 10.1 Disposition-Notification-Options header parameter names 1184 A registration for a Disposition-Notification-Options header parameter 1185 name MUST include the following information: 1187 (a) The proposed parameter name. 1189 (b) The syntax for parameter values, specified using BNF, ABNF, 1190 regular expressions, or other non-ambiguous language. 1192 (c) If parameter values are not composed entirely of graphic 1193 characters from the US-ASCII repertoire, a specification for how 1194 they are to be encoded as graphic US-ASCII characters in a 1195 Disposition-Notification-Options header. 1197 (d) A reference to a standards track RFC or experimental RFC approved 1198 by the IESG that describes the semantics of the parameter values. 1200 10.2 Disposition modifier names 1202 A registration for a disposition-modifier name (used in the 1203 Disposition field of a message/disposition-notification) MUST include 1204 the following information: 1206 (a) The proposed disposition-modifier name. 1208 (b) A reference to a standards track RFC or experimental RFC approved 1209 by the IESG that describes the semantics of the disposition 1210 modifier. 1212 10.3 MDN extension field names 1214 A registration for an MDN extension-field name MUST include the 1215 following information: 1217 (a) The proposed extension field name. 1219 (b) The syntax for extension values, specified using BNF, ABNF, 1220 regular expressions, or other non-ambiguous language. 1222 (c) If extension-field values are not composed entirely of graphic 1223 characters from the US-ASCII repertoire, a specification for how 1224 they are to be encoded as graphic US-ASCII characters in a 1225 Disposition-Notification-Options header. 1227 (d) A reference to a standards track RFC or experimental RFC approved 1228 by the IESG that describes the semantics of the extension field. 1230 11. Acknowledgments 1232 This document is an updated version of the original document written 1233 by Roger Fajman. His contributions to the definition of Message 1234 Disposition Notifications are greatly appreciated. 1236 RFC 2298 was based on the Delivery Status Notifications document, 1237 [RFC-DSN-FORMAT], by Keith Moore and Greg Vaudreuil. Contributions 1238 were made by members of the IETF Receipt Working Group, including 1239 Harald Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, 1240 Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul 1241 Overell, Pete Resnick, and Chuck Shih. 1243 12. Normative References 1245 [RFC-SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1246 821, August 1982. 1248 [RFC-MSGFMT] Crocker, D., "Standard for the Format of ARPA Internet 1249 Text Messages", STD 11, RFC 822, August 1982. 1251 [RFC-HOST] Braden, R. (ed.), "Requirements for Internet Hosts - 1252 Application and Support", STD 3, RFC 1123, October 1989. 1254 [RFC-MIME-BODY] Freed, N., and N. Borenstein, "Multipurpose Internet 1255 Mail Extensions (MIME) Part One: Format of Internet Message 1256 Bodies", RFC 2045, November 1996. 1258 [RFC-MIME-MEDIA] Freed, N., and N. Borenstein, "Multipurpose Internet 1259 Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1260 1996. 1262 [RFC-MIME-HEADER] Moore, K., "Multipurpose Internet Mail Extensions 1263 (MIME) Part Three: Message Header Extensions for Non-Ascii Text", 1264 RFC 2047, November 1996. 1266 [RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1267 Reporting of Mail System Administrative Messages", RFC 3462, 1268 January 2003. 1270 [RFC-DSN-SMTP] Moore, K., "SMTP Service Extension for Delivery Status 1271 Notifications", RFC 3461, January 2003. 1273 [RFC-DSN-FORMAT] Moore, K., and G. Vaudreuil, "An Extensible Format 1274 for Delivery Status Notifications, RFC 3464, January 2003. 1276 [RFC-KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 1277 Requirement Levels", BCP 14, RFC 2119, March 1997. 1279 13. Informative References 1281 [SEC-SERVICES] Hoffman, P., "Enhanced Security Services for S/MIME", 1282 RFC 2634, June 1999. 1284 14. Intellectual Property Notice 1286 The IETF takes no position regarding the validity or scope of any 1287 intellectual property or other rights that might be claimed to pertain 1288 to the implementation or use of the technology described in this 1289 document or the extent to which any license under such rights might or 1290 might not be available; neither does it represent that it has made any 1291 effort to identify any such rights. Information on the IETF's 1292 procedures with respect to rights in standards-track and standards- 1293 related documentation can be found in BCP-11. Copies of claims of 1294 rights made available for publication and any assurances of licenses 1295 to be made available, or the result of an attempt made to obtain a 1296 general license or permission for the use of such proprietary rights 1297 by implementors or users of this specification can be obtained from 1298 the IETF Secretariat. 1300 The IETF invites any interested party to bring to its attention any 1301 copyrights, patents or patent applications, or other proprietary 1302 rights which may cover technology that may be required to practice 1303 this standard. Please address the information to the IETF Executive 1304 Director. 1306 15. Copyright Notice 1308 "Copyright (C) The Internet Society (2002). All Rights Reserved. 1310 This document and translations of it may be copied and furnished to 1311 others, and derivative works that comment on or otherwise explain it 1312 or assist in its implementation may be prepared, copied, published and 1313 distributed, in whole or in part, without restriction of any kind, 1314 provided that the above copyright notice and this paragraph are 1315 included on all such copies and derivative works. However, this 1316 document itself may not be modified in any way, such as by removing 1317 the copyright notice or references to the Internet Society or other 1318 Internet organizations, except as needed for the purpose of developing 1319 Internet standards in which case the procedures for copyrights defined 1320 in the Internet Standards process MUST be followed, or as required to 1321 translate it into languages other than English. 1323 The limited permissions granted above are perpetual and will not be 1324 revoked by the Internet Society or its successors or assigns. 1326 This document and the information contained herein is provided on an 1327 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1328 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1329 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1330 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1331 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1333 16. Authors' Addresses 1335 Tony Hansen 1336 AT&T Laboratories 1337 Middletown, NJ 07748 1338 USA 1339 Voice: +1-732-420-8934 1340 E-Mail: tony+mdnbis@maillennium.att.com 1342 Gregory M. Vaudreuil 1343 Lucent Technologies 1344 7291 Williamson Rd 1345 Dallas, TX 75214 1346 USA 1347 Voice: +1 214 823 9325 1348 E-Mail: GregV@ieee.org 1350 17. Appendix A - Changes from RFC2298 1352 Noted new editors, noted Roger Fajan contribution in the 1353 acknowledgements. 1355 Updated to use required standards boilerplate. 1357 The dispositions "denied", and "failed" were removed from the document 1358 reflecting the lack of implementation or usage at this time. 1360 The disposition modifiers "warning", "superseded", "expired", 1361 "mailbox-terminated" have not seen actual implementation. Except for 1362 the extension modifier, they have been deleted from this draft. 1363 General editorial cleanups include spelling, grammar, and consistency 1364 in usage of terms. 1366 Modified the BNF for disposition notification options to eliminate the 1367 need for dummy values where not otherwise needed.