idnits 2.17.1 draft-ietf-receipt-mdn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 1383 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 Additional disposition modifiers may be defined in the future by later revisions 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 UA MAY be silently ignored or placed in the user's mailbox without special inter-pretation. 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 (17 November 1997) is 9658 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: '1' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1348, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1892 (ref. '7') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 1891 (ref. '8') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (ref. '9') (Obsoleted by RFC 3464) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Receipt Working Group Roger Fajman 2 Internet Draft National Institutes of Health 3 Expires: 22 May 1998 17 November 1997 5 An Extensible Message Format 6 for Message Disposition Notifications 8 draft-ietf-receipt-mdn-07.txt | 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as refer- 20 ence material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Any questions, comments, and reports of defects or ambiguities in 29 this specification may be sent to the mailing list for the RECEIPT 30 working group of the IETF, using the address . 31 Requests to subscribe to the mailing list should be addressed to 32 . Implementors of this specification are 33 encouraged to subscribe to the mailing list, so that they will 34 quickly be informed of any problems which might hinder inter- 35 operability. 37 Abstract 39 This memo defines a MIME content-type that may be used by a mail 40 user agent (UA) or electronic mail gateway to report the disposition 41 of a message after it has been sucessfully delivered to a recipient. 42 This content-type is intended to be machine-processable. Additional 43 message headers are also defined to permit Message Disposition 44 Notifications (MDNs) to be requested by the sender of a message. 45 The purpose is to extend Internet Mail to support functionality 46 often found in other messaging systems, such as X.400 and the 47 proprietary ''LAN-based'' systems, and often referred to as ''read 48 receipts,'' ''acknowledgements,'' or ''receipt notifications.'' The 49 intention is to do this while respecting the privacy concerns that 50 Message Disposition Notifications 17 November 1997 51 Internet Draft 53 have often been expressed when such functions have been discussed in 54 the past. 56 Because many messages are sent between the Internet and other 57 messaging systems (such as X.400 or the proprietary ''LAN-based'' 58 systems), the MDN protocol is designed to be useful in a multi- 59 protocol messaging environment. To this end, the protocol described 60 in this memo provides for the carriage of ''foreign'' addresses, in 61 addition to those normally used in Internet Mail. Additional 62 attributes may also be defined to support ''tunneling'' of foreign 63 notifications through Internet Mail. 65 Message Disposition Notifications 17 November 1997 66 Internet Draft 68 Table of Contents 70 1. Introduction ................................................... 4 72 2. Requesting Message Disposition Notifications ................... 6 74 3. Format of a Message Disposition Notification ................... 10 76 4. Timeline of events ............................................. 21 78 5. Conformance and Usage Requirements ............................. 22 80 6. Security considerations ........................................ 23 82 7. Collected Grammar .............................................. 25 84 8. Guidelines for Gatewaying MDNs ................................. 27 86 9. Example ........................................................ 29 88 10. IANA Registration Forms ........................................ 30 90 11. Acknowledgments ................................................ 32 92 12. References ..................................................... 33 94 13. Copyright ...................................................... 34 96 14. Author's Address ............................................... 35 97 Message Disposition Notifications 17 November 1997 98 Internet Draft 100 1. Introduction 102 This memo defines a MIME content-type [5] for message disposition 103 notifications (MDNs). An MDN can be used to notify the sender of a 104 message of any of several conditions that may occur after successful 105 delivery, such as display of the message contents, printing of the 106 message, deletion (without display) of the message, or the 107 recipient's refusal to provide MDNs. The 108 "message/disposition-notification" content-type defined herein is 109 intended for use within the framework of the "multipart/report" 110 content type defined in RFC 1892 [7]. 112 This memo defines the format of the notifications and the RFC 822 113 headers used to request them. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119. 119 1.1 Purposes 121 The MDNs defined in this memo are expected to serve several pur- 122 poses: 124 (a) Inform human beings of the disposition of messages after 125 succcessful delivery, in a manner which is largely independent 126 of human language; 128 (b) Allow mail user agents to keep track of the disposition of 129 messages sent, by associating returned MDNs with earlier 130 message transmissions; 132 (c) Convey disposition notification requests and disposition 133 notifications between Internet Mail and "foreign" mail systems 134 via a gateway; 136 (d) Allow "foreign" notifications to be tunneled through a MIME- 137 capable message system and back into the original messaging 138 system that issued the original notification, or even to a 139 third messaging system; 141 (e) Allow language-independent, yet reasonably precise, indications 142 of the disposition of a message to be delivered. 144 Message Disposition Notifications 17 November 1997 145 Internet Draft 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- 153 parsable. 155 (b) It must provide enough information to allow message senders (or 156 their user agents) to unambiguously associate an MDN with the 157 message that was sent and the original recipient address for 158 which the MDN is issued (if such information is available), 159 even if the message was forwarded to another recipient address. 161 (c) It must also be able to describe the disposition of a message 162 independent of any particular human language or of the ter- 163 minology of any particular mail system. 165 (d) The specification must be extensible in order to accomodate 166 future requirements. 168 Message Disposition Notifications 17 November 1997 169 Internet Draft 171 2. Requesting Message Disposition Notifications 173 Message disposition notifications are requested by including a 174 Disposition-Notification-To header in the message. Further informa- 175 tion to be used by the recipient's UA in generating the MDN may be 176 provided by including Original-Recipient and/or Disposition- 177 Notification-Options headers in the message. 179 2.1 The Disposition-Notification-To Header 181 A request that the receiving user agent issue message disposition 182 notifications is made by placing a Disposition-Notification-To 183 header into the message. The syntax of the header, using the ABNF 184 of RFC 822 [2], is 186 mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox 188 The mailbox token is as specified in RFC 822 [2]. 190 The presence of a Disposition-Notification-To header in a message is 191 merely a request for an MDN. The recipients' user agents are always 192 free to silently ignore such a request. Alternatively, an explicit 193 denial of the request for information about the disposition of the 194 message may be sent using the "denied" disposition in an MDN. 196 An MDN MUST NOT itself have a Disposition-Notification-To header. 197 An MDN MUST NOT be generated in response to an MDN. 199 At most one MDN may be issued on behalf of each particular recipient 200 by their user agent. That is, once an MDN has been issued on behalf 201 of a recipient, no further MDNs may be issued on behalf of that 202 recipient, even if another disposition is performed on the message. 203 However, if a message is forwarded, a "dispatched" MDN may been 204 issued for the recipient doing the forwarding and the recipient of 205 the forwarded message may also cause an MDN to be generated. 207 While Internet standards normally do not specify the behavior of 208 user interfaces, it is strongly recommended that the user agent 209 obtain the user's consent before sending an MDN. This consent could 210 be obtained for each message through some sort of prompt or dialog 211 box, or globally through the user's setting of a preference. The 212 user might also indicate globally that MDNs are never to be sent or 213 that a "denied" MDN is always sent in response to a request for an 214 MDN. 216 MDNs SHOULD NOT be sent automatically if the address in the 217 Disposition-Notification-To header differs from the address in the 218 Return-Path header (see RFC 822 [2]). In this case, confirmation 219 from the user SHOULD be obtained, if possible. If obtaining consent 220 Message Disposition Notifications 17 November 1997 221 Internet Draft 223 is not possible (e.g., because the user is not online at the time), 224 then an MDN SHOULD NOT be sent. 226 Confirmation from the user SHOULD be obtained (or no MDN sent) if 227 there is no Return-Path header in the message, or if there is more 228 than one distinct address in the Disposition-Notification-To header. 230 The comparison of the addresses should be done using only the 231 addr-spec (local-part "@" domain) portion, excluding any phrase and 232 route. The comparison MUST be case-sensitive for the local-part and 233 case-insensitive for the domain part. 235 If the message contains more than one Return-Path header, the 236 implementation may pick one to use for the comparison, or treat the 237 situation as a failure of the comparison. 239 The reason for not automatically sending an MDN if the comparison 240 fails or more than one address is specified is to reduce the pos- 241 sibilities for mail loops and use of MDNs for mail bombing. 243 A message that contains a Disposition-Notification-To header SHOULD 244 also contain a Message-ID header as specified in RFC 822 [2]. This 245 will permit automatic correlation of MDNs with original messages by 246 user agents. 248 If it is desired to request message disposition notifications for 249 some recipients and not others, two copies of the message should be 250 sent, one with an Disposition-Notification-To header and one 251 without. Many of the other headers of the message (e.g., To, cc) 252 will be the same in both copies. The recipients in the respective 253 message envelopes determine for whom message disposition notifica- 254 tions are requested and for whom they are not. If desired, the 255 Message-ID header may be the same in both copies of the message. 256 Note that there are other situations (e.g., bcc) in which it is 257 necessary to send multiple copies of a message with slightly dif- 258 ferent headers. The combination of such situations and the need to 259 request MDNs for a subset of all recipients may result in more than 260 two copies of a message being sent, some with a Disposition- 261 Notification-To header and some without. 263 2.2 The Disposition-Notification-Options Header 265 Future extensions to this specification may require that information 266 be supplied to the recipient's UA for additional control over how 267 and what MDNs are generated. The Disposition-Notification-Options 268 header provides an extensible mechanism for such information. The 269 syntax of this header, using the ABNF of RFC 822 [2], is 270 Message Disposition Notifications 17 November 1997 271 Internet Draft 273 Disposition-Notification-Options = 274 "Disposition-Notification-Options" ":" 275 disposition-notification-parameters 277 disposition-notification-parameters = parameter *(";" parameter) 279 parameter = attribute "=" importance "," 1#value 281 importance = "required" / "optional" 283 The definitions of attribute and value are as in the definition of 284 the Content-Type header in RFC 2046 [5]. 286 An importance of "required" indicates that interpretation of the 287 parameter is necessary for proper generation of an MDN in response 288 to this request. If a UA does not understand the meaning of the 289 parameter, it MUST NOT generate an MDN with any disposition type | 290 other than "failed" in response to the request. An importance of | 291 "optional" indicates that a UA that does not understand the meaning 292 of this parameter MAY generate an MDN in response anyway, ignoring 293 the value of the parameter. 295 No parameters are defined in this specification. Parameters may be 296 defined in the future by later revisions or extensions to this 297 specification. Parameter attribute names beginning with "X-" will 298 never be defined as standard names; such names are reserved for 299 experimental use. MDN parameter names not beginning with "X-" MUST 300 be registered with the Internet Assigned Numbers Authority (IANA) 301 and described in a standards-track RFC or an experimental RFC 302 approved by the IESG. See Section 10 for a registration form. 304 If a required parameter is not understood or contains some sort of 305 error, the receiving UA SHOULD issue an MDN with a disposition type | 306 of "failed" (see Section 3.2.6) and include a Failure field (see 307 Section 3.2.7) that further describes the problem. MDNs with the a 308 disposition type of "failed" and a "Failure" field MAY also be | 309 generated when other types of errors are detected in the parameters | 310 of the Disposition-Notification-Options header. 311 | 312 However, an MDN with a disposition type of "failed" MUST NOT be | 313 generated if the user has indicated a preferance that MDNs are not | 314 to be sent. If user consent would be required for an MDN of some | 315 other disposition type to be sent, user consent SHOULD also be | 316 obtained before sending an MDN with a disposition type of "failed". | 317 Message Disposition Notifications 17 November 1997 318 Internet Draft 320 2.3 The Original-Recipient Header 322 Since electronic mail addresses may be rewritten while the message 323 is in transit, it is useful for the original recipient address to be 324 made available by the delivering MTA. The MTA may be able to obtain 325 this information from the ORCPT parameter of the SMTP MAIL FROM 326 command, as defined in RFC 1891 [8]. If this information is avail- 327 able, the delivering MTA SHOULD insert an Original-Recipient header 328 at the beginning of the message (along with the Return-Path header). 329 The delivering MTA MAY delete any other Original-Recipient headers 330 that occur in the message. The syntax of this header, using the 331 ABNF of RFC 822 [2], is as follows 333 original-recipient-header = 334 "Original-Recipient" ":" address-type ";" generic-address 336 The address-type and generic-address token are as as specified in 337 the description of the Original-Recipient field in section 3.2.3. 339 The purpose of carrying the original recipient information and 340 returning it in the MDN is to permit automatic correlation of MDNs 341 with the original message on a per-recipient basis. 343 2.4 Use with the Message/Partial Content Type 345 The use of the headers Disposition-Notification-To, Disposition- 346 Notification-Options, and Original-Recipient with the MIME 347 Message/partial content type (RFC 2046 [5]) requires further defini- 348 tion. 350 When a message is segmented into two or more message/partial frag- 351 ments, the three headers mentioned in the above paragraph SHOULD be 352 placed in the "inner" or "enclosed" message (using the terms of RFC 353 2046 [5]). These headers SHOULD NOT be used in the headers of any 354 of the fragments themselves. 356 When the multiple message/partial fragments are reassembled, the 357 following applies. If these headers occur along with the other 358 headers of a message/partial fragment message, they pertain to an 359 MDN to be generated for the fragment. If these headers occur in the 360 headers of the "inner" or "enclosed" message (using the terms of RFC 361 2046 [5]), they pertain to an MDN to be generated for the reas- 362 sembled message. Section 5.2.2.1 of RFC 2046 [5]) is amended to 363 specify that, in addition to the headers specified there, the three 364 headers described in this specification are to be appended, in 365 order, to the headers of the reassembled message. Any occurances of 366 the three headers defined here in the headers of the initial enclos- 367 ing message must not be copied to the reassembled message. 369 Message Disposition Notifications 17 November 1997 370 Internet Draft 372 3. Format of a Message Disposition Notification 374 A message disposition notification is a MIME message with a top- 375 level content-type of multipart/report (defined in RFC 1892 [7]). 376 When a multipart/report content is used to transmit an MDN: 378 (a) The report-type parameter of the multipart/report content is 379 "disposition-notification". 381 (b) The first component of the multipart/report contains a human- 382 readable explanation of the MDN, as described in RFC 1892 [7]. 384 (c) The second component of the multipart/report is of content-type 385 message/disposition-notification, described in section 3.1 of 386 this document. 388 (d) If the original message or a portion of the message is to be 389 returned to the sender, it appears as the third component of 390 the multipart/report. The decision of whether or not to return 391 the message or part of the message is up to the UA generating 392 the MDN. However, in the case of encrypted messages requesting 393 MDNs, encrypted message text MUST be returned, if it is | 394 returned at all, only in its original encrypted form. | 396 NOTE: For message dispostion notifications gatewayed from 397 foreign systems, the headers of the original message may not be 398 available. In this case the third component of the MDN may be 399 omitted, or it may contain "simulated" RFC 822 headers which 400 contain equivalent information. In particular, it is very 401 desirable to preserve the subject and date fields from the 402 original message. 404 The MDN MUST be addressed (in both the message header and the 405 transport envelope) to the address(es) from the Disposition- 406 Notification-To header from the original message for which the MDN 407 is being generated. 409 The From field of the message header of the MDN MUST contain the 410 address of the person for whom the message disposition notification 411 is being issued. 413 The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST 414 be null (<>), specifying that no Delivery Status Notification 415 messages or other messages indicating successful or unsuccessful 416 delivery are to be sent in response to an MDN. 418 A message disposition notification MUST NOT itself request an MDN. 419 That is, it MUST NOT contain a Disposition-Notification-To header. 421 Message Disposition Notifications 17 November 1997 422 Internet Draft 424 The Message-ID header (if present) for an MDN MUST be different from 425 the Message-ID of the message for which the MDN is being issued. 427 A particular MDN describes the disposition of exactly one message 428 for exactly one recipient. Multiple MDNs may be generated as a 429 result of one message submission, one per recipient. However, due 430 to the circumstances described in Section 2.1, MDNs may not be 431 generated for some recipients for which MDNs were requested. 433 3.1 The message/disposition-notification content-type 435 The message/disposition-notification content-type is defined as 436 follows: 438 MIME type name: message 439 MIME subtype name: disposition-notification 440 Optional parameters: none 441 Encoding considerations: "7bit" encoding is sufficient and 442 MUST be used to maintain readability 443 when viewed by non-MIME mail 444 readers. 445 Security considerations: discussed in section 6 of this memo. 447 The message/disposition-notification report type for use in the 448 multipart/report is "disposition-notification". 450 The body of a message/delivery-status consists of one or more 451 "fields" formatted according to the ABNF of RFC 822 header "fields" 452 (see [2]). Using the ABNF of RFC 822, the syntax of the 453 message/disposition-notification content is as follows: 455 disposition-notification-content = [ reporting-ua-field CRLF ] 456 [ mdn-gateway-field CRLF ] 457 [ original-recipient-field CRLF ] 458 final-recipient-field CRLF 459 [ original-message-id-field CRLF ] 460 disposition-field CRLF 461 *( failure-field CRLF ) 462 *( error-field CRLF ) 463 *( warning-field CRLF ) 464 *( extension-field CRLF ) 466 3.1.1 General conventions for fields 468 Since these fields are defined according to the rules of RFC 822 469 [2], the same conventions for continuation lines and comments apply. 470 Notification fields may be continued onto multiple lines by begin- 471 ning each additional line with a SPACE or HTAB. Text which appears 472 Message Disposition Notifications 17 November 1997 473 Internet Draft 475 in parentheses is considered a comment and not part of the contents 476 of that notification field. Field names are case-insensitive, so 477 the names of notification fields may be spelled in any combination 478 of upper and lower case letters. Comments in notification fields 479 may use the "encoded-word" construct defined in RFC 2047 [6]. 481 3.1.2 "*-type" subfields 483 Several fields consist of a "-type" subfield, followed by a semi- 484 colon, followed by "*text". For these fields, the keyword used in 485 the address-type or MTA-type subfield indicates the expected format 486 of the address or MTA-name that follows. 488 The "-type" subfields are defined as follows: 490 (a) An "address-type" specifies the format of a mailbox address. 491 For example, Internet Mail addresses use the "rfc822" address- 492 type. 494 address-type = atom 496 (b) An "MTA-name-type" specifies the format of a mail transfer 497 agent name. For example, for an SMTP server on an Internet 498 host, the MTA name is the domain name of that host, and the 499 "dns" MTA-name-type is used. 501 mta-name-type = atom 503 Values for address-type and mta-name-type are case-insensitive. 504 Thus address-type values of "RFC822" and "rfc822" are equivalent. 506 The Internet Assigned Numbers Authority (IANA) will maintain a 507 registry of address-type and mta-name-type values, along with 508 descriptions of the meanings of each, or a reference to a one or 509 more specifications that provide such descriptions. (The "rfc822" 510 address-type is defined in RFC 1891 [8].) Registration forms for 511 address-type and mta-name-type appear in RFC 1894 [9]. 513 IANA will not accept registrations for any address-type name that 514 begins with "X-". These type names are reserved for experimental 515 use. 517 3.1.3 Lexical tokens imported from RFC 822 519 The following lexical tokens, defined in RFC 822 [2], are used in 520 the ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text. 522 Message Disposition Notifications 17 November 1997 523 Internet Draft 525 3.2 Message/disposition-notification Fields 527 3.2.1 The Reporting-UA field 529 reporting-ua-field = "Reporting-UA" ":" ua-name 530 [ ";" ua-product ] 532 ua-name = *text 534 ua-product = *text 536 The Reporting-UA field is defined as follows: 538 A MDN describes the disposition of a message after it has been 539 delivered to a recipient. In all cases, the Reporting-UA is the UA 540 that performed the disposition described in the MDN. This field is 541 optional, but recommended. For Internet Mail user agents, it is 542 recommended that this field contain both the DNS name of the par- 543 ticular instance of the UA that generated the MDN and the name of 544 the product. For example, 546 Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1 548 If the reporting UA consists of more than one component (e.g., a 549 base program and plug-ins), this may be indicated by including a 550 list of product names. 552 3.2.2 The MDN-Gateway field 554 The MDN-Gateway field indicates the name of the gateway or MTA that 555 translated a foreign (non-Internet) message disposition notification 556 into this MDN. This field MUST appear in any MDN which was trans- 557 lated by a gateway from a foreign system into MDN format, and MUST 558 NOT appear otherwise. 560 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 562 mta-name = *text 564 For gateways into Internet Mail, the MTA-name-type will normally be 565 "smtp", and the mta-name will be the Internet domain name of the 566 gateway. 568 3.2.3 Original-Recipient field 570 The Original-Recipient field indicates the original recipient 571 address as specified by the sender of the message for which the MDN 572 is being issued. For Internet Mail messages the value of the 573 Message Disposition Notifications 17 November 1997 574 Internet Draft 576 Original-Recipient field is obtained from the Original-Recipient 577 header from the message for which the MDN is being generated. If 578 there is no Original-Recipient header in the message, then the 579 Original-Recipient field MUST be omitted, unless the same informa- 580 tion is reliably available some other way. If there is an Original- 581 Recipient header in the original message (or original recipient 582 information is reliably available some other way), then the 583 Original-Recipient field must be supplied. If there is more than 584 one Original-Recipient header in the message, the UA may choose the 585 one to use or act as if no Original-Recipient header is present. 587 original-recipient-field = 588 "Original-Recipient" ":" address-type ";" generic-address 590 generic-address = *text 592 The address-type field indicates the type of the original recipient 593 address. If the message originated within the Internet, the 594 address-type field field will normally be "rfc822", and the address 595 will be according to the syntax specified in RFC 822 [2]. The value 596 "unknown" should be used if the Reporting UA cannot determine the 597 type of the original recipient address from the message envelope. 598 This address is the same as that provided by the sender and can be 599 used to automatically correlate MDN reports with original messages 600 on a per recipient basis. 602 3.2.4 Final-Recipient field 604 The Final-Recipient field indicates the recipient for which the MDN 605 is being issued. This field MUST be present. 607 The syntax of the field is as follows: 609 final-recipient-field = 610 "Final-Recipient" ":" address-type ";" generic-address 612 The generic-address subfield of the Final-Recipient field MUST 613 contain the mailbox address of the recipient (from the From header 614 of the MDN) as it was when the MDN was generated by the UA. 616 The Final-Recipient address may differ from the address originally 617 provided by the sender, because it may have been transformed during 618 forwarding and gatewaying into an totally unrecognizable mess. 619 However, in the absence of the optional Original-Recipient field, 620 the Final-Recipient field and any returned content may be the only 621 information available with which to correlate the MDN with a par- 622 ticular message recipient. 624 Message Disposition Notifications 17 November 1997 625 Internet Draft 627 The address-type subfield indicates the type of address expected by 628 the reporting MTA in that context. Recipient addresses obtained via 629 SMTP will normally be of address-type "rfc822". 631 Since mailbox addresses (including those used in the Internet) may 632 be case sensitive, the case of alphabetic characters in the address 633 MUST be preserved. 635 3.2.5 Original-Message-ID field 637 The Original-Message-ID field indicates the message-ID of the 638 message for which the MDN is being issued. It is obtained from the 639 Message-ID header of the message for which the MDN is issued. This 640 field MUST be present if the original message contained a Message-ID 641 header. The syntax of the field is 643 original-message-id-field = "Original-Message-ID" ":" msg-id 645 The msg-id token is as specified in RFC 822 [2]. 647 3.2.6 Disposition field 649 The Disposition field indicates the action performed by the 650 Reporting-UA on behalf of the user. This field MUST be present. 652 The syntax for the Disposition field is: 654 disposition-field = "Disposition" ":" disposition-mode ";" 655 disposition-type 656 [ '/' disposition-modifier 657 *( "," dispostion-modifier ) ] 659 disposition-mode = action-mode "/" sending-mode 661 action-mode = "manual-action" / "automatic-action" 663 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 665 disposition-type = "displayed" 666 / "dispatched" 667 / "processed" 668 / "deleted" 669 / "denied" 670 / "failed" 672 Message Disposition Notifications 17 November 1997 673 Internet Draft 675 disposition-modifier = ( "error" / "warning" ) 676 / ( "superseded" / "expired" / 677 "mailbox-terminated" ) 678 / disposition-modifier-extension 680 disposition-modifier-extension = atom 682 The disposition-mode, disposition-type and disposition-modifier may 683 be spelled in any combination of upper and lower case characters. 685 3.2.6.1 Disposition modes 687 The following disposition modes are defined: 689 "manual-action" The disposition described by the disposi- 690 tion type was a result of an explicit 691 instruction by the user rather than some 692 sort of automatically performed action. 694 "automatic-action" The disposition described by the disposi- 695 tion type was a result of an automatic 696 action, rather than an explicit instruc- 697 tion by the user for this message. 699 "Manual-action" and "automatic-action" 700 are mutually exclusive. One or the other 701 must be specified. 703 "MDN-sent-manually" The user explicity gave permission for 704 this particular MDN to be sent. 706 "MDN-sent-automatically" The MDN was sent because the UA had 707 previously been configured to do so 708 automatically. 710 "MDN-sent-manually" and "MDN-sent- 711 automatically" are mutually exclusive. 712 One or the other must be specified. 714 3.2.6.2 Disposition types 716 The following disposition-types are defined: 718 "displayed" The message has been displayed by the UA to someone 719 reading the recipient's mailbox. There is no 720 guarantee that the content has been read or under- 721 stood. 723 Message Disposition Notifications 17 November 1997 724 Internet Draft 726 "dispatched" The message has been sent somewhere manner (e.g., 727 printed, faxed, forwarded) without being displayed to 728 the user. The user may or may not see the message 729 later. 731 "processed" The message has been processed in some manner (i.e., 732 by some sort of rules or server) without being 733 displayed to the user. The user may or may not see 734 the message later, or there may not even be a human 735 user associated with the mailbox. 737 "deleted" The message has been deleted. The recipient may or 738 may not have seen the message. The recipient might 739 "undelete" the message at a later time and read the 740 message. 742 "denied" The recipient does not wish the sender to be informed 743 of the message's disposition. A UA may also 744 siliently ignore message disposition requests in this 745 situation. 747 "failed" A failure occurred that prevented the proper gener- 748 ation of an MDN. More information about the cause of 749 the failure may be contained in a Failure field. The 750 "failed" disposition type is not to be used for the 751 situation in which there is is some problem in 752 processing the message other than interpreting the 753 request for an MDN. The "processed" or other dis- 754 position type with appropriate disposition modifiers 755 is to be used in such situations. 757 3.2.6.3 Disposition modifiers 759 The following disposition modifiers are defined: 761 "error" An error of some sort occurred 762 that prevented successful 763 processing of the message. 764 Further information is contained 765 in an Error field. 767 "warning" The message was successfully 768 processed but some sort of 769 exceptional condition occurred. 770 Further information is contained 771 in a Warning field. 773 "superseded" The message has been automati- 774 cally rendered obsolete by 776 Message Disposition Notifications 17 November 1997 777 Internet Draft 779 another message received. The 780 recipient may still access and 781 read the message later. 783 "expired" The message has reached its 784 expiration date and has been 785 automatically removed from the 786 recipient's mailbox. 788 "mailbox-terminated" The recipient's mailbox has been 789 terminated and all message in it 790 automatically removed. 792 "Obsoleted", "expired", and 793 "terminated" are to be used with 794 the "deleted" disposition type 795 and the "autoaction" and 796 "autosent" disposition modifiers. 798 disposition-modifier-extension Additional disposition modifiers 799 may be defined in the future by 800 later revisions or extensions to 801 this specification. Disposition 802 value names beginning with "X-" 803 will never be defined as standard 804 values; such names are reserved 805 for experimental use. MDN 806 disposition value names NOT 807 beginning with "X-" MUST be 808 registered with the Internet 809 Assigned Numbers Authority (IANA) 810 and described in a standards- 811 track RFC or an experimental RFC 812 approved by the IESG. See 813 Section 10 for a registration 814 form. MDNs with disposition 815 modifier names not understood by 816 the receiving UA MAY be silently 817 ignored or placed in the user's 818 mailbox without special inter- 819 pretation. They MUST not cause 820 any error message to be sent to 821 the sender of the MDN. 823 If an UA developer does not wish 824 to register the meanings of such 825 disposition modifier extensions, 826 "X-" modifiers may be used for 827 this purpose. To avoid name 828 collisions, the name of the UA 830 Message Disposition Notifications 17 November 1997 831 Internet Draft 833 implementation should follow the 834 "X-", (e.g. "X-Foomail-fratzed"). 836 It is not required that a UA be able to generate all of the possible 837 values of the Disposition field. 839 One and only one MDN may be issued on behalf of each particular 840 recipient by their user agent. That is, once an MDN has been issued 841 on behalf of a recipient, no further MDNs may be issued on behalf of 842 that recipient, even if another disposition is performed on the 843 message. However, if a message is forwarded, a "dispatched" MDN may 844 been issued for the recipient doing the forwarding and the recipient 845 of the forwarded message may also cause an MDN to be generated. 847 3.2.7 Failure, Error and Warning fields 849 The Failure, Error and Warning fields are used to supply additional 850 information in the form of text messages when the "failure" disposi- 851 tion type, "error" disposition modifier, and/or the "warning" 852 disposition modifer appear. The syntax is 854 failure-field = "Failure" ":" *text 856 error-field = "Error" ":" *text 858 warning-field = "Warning" ":" *text 860 3.3 Extension fields 862 Additional MDN fields may be defined in the future by later revi- 863 sions or extensions to this specification. Extension-field names 864 beginning with "X-" will never be defined as standard fields; such 865 names are reserved for experimental use. MDN field names NOT 866 beginning with "X-" MUST be registered with the Internet Assigned 867 Numbers Authority (IANA) and described in a standards-track RFC or 868 an experimental RFC approved by the IESG. See Section 10 for a 869 registration form. 871 Extension MDN fields may be defined for the following reasons: 873 (a) To allow additional information from foreign disposition 874 reports to be tunneled through Internet MDNs. The names of 875 such MDN fields should begin with an indication of the foreign 876 environment name (e.g. X400-Physical-Forwarding-Address). 878 (b) To allow transmission of diagnostic information which is 879 specific to a particular user agent (UA). The names of such 881 Message Disposition Notifications 17 November 1997 882 Internet Draft 884 MDN fields should begin with an indication of the UA implemen- 885 tation which produced the MDN. (e.g. Foomail-information). 887 If an application developer does not wish to register the meanings 888 of such extension fields, "X-" fields may be used for this purpose. 889 To avoid name collisions, the name of the application implementation 890 should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info"). 892 Message Disposition Notifications 17 November 1997 893 Internet Draft 895 4. Timeline of events 897 The following timeline shows when various events in the processing 898 of a message and generation of MDNs take place: 900 --- User composes message 901 | 902 |-- User tells UA to send message 903 | 904 |-- UA passes message to MTA (original recipient information 905 | passed along) 906 | 907 |-- MTA sends message to next MTA 908 . 909 . 910 . 911 |-- Final MTA receives message 912 | 913 |-- Final MTA delivers message to UA (possibily generating DSN) 914 | 915 |-- UA performs automatic processing and generates corresponding 916 | MDNs ("dispatched", "processed", "deleted", "denied" or "failed" 917 | disposition type with "automatic-action" and "MDN-sent-automatically" 918 | disposition modes) 919 | 920 |-- UA displays list of messages to user 921 | 922 |-- User selects a message and requests that some action be 923 | performed on it. 924 | 925 |-- UA performs requested action and, with user's permission, 926 | sends appropriate MDN ("displayed", "dispatched", "processed", 927 | "deleted", "denied" or "failed" disposition type with "manual-action" 928 | and "MDN-sent-manually" or "MDN-sent-automatically" disposition 929 | mode). 930 | 931 |-- User possibly performs other actions on message, but no 932 | further MDNs are generated. 934 Message Disposition Notifications 17 November 1997 935 Internet Draft 937 5. Conformance and Usage Requirements 939 A UA or gateway conforms to this specification if it generates MDNs 940 according to the protocol defined in this memo. It is not necessary 941 to be able to generate all of the possible values of the Disposition 942 field. 944 UAs and gateways MUST NOT generate the Original-Recipient field of 945 an MDN unless the mail protocols provide the address originally 946 specified by the sender at the time of submission. Ordinary SMTP 947 does not make that guarantee, but the SMTP extension defined in RFC 948 1891 [8] permits such information to be carried in the envelope if 949 it is available. The Original-Recipient header defined in this 950 document provides a way for the MTA to pass the original recipient 951 address to the UA. 953 Each sender-specified recipient address may result in more than one 954 MDN. If an MDN is requested for a recipient that is forwarded to 955 multiple recipients of an "alias" (as defined in RFC 1891 [8], 956 section 7.2.7), each of the recipients may issue an MDN. 958 Successful distribution of a message to a mailing list exploder 959 SHOULD be considered final disposition of the message. A mailing 960 list exploder may issue an MDN with a disposition type of 961 "processed" and disposition modes of "automatic-action" and "MDN- 962 sent-automatically" indicating that the message has been forwarded 963 to the list. In this case, the request for MDNs is not propogated 964 to the members of the list. 966 Alternaively, the mailing list exploder may issue no MDN and 967 propogate the request for MDNs to all members of the list. The 968 latter behavior is not recommended for any but small, closely knit 969 lists, as it might cause large numbers of MDNs to be generated and 970 may cause confidential subscribers to the list to be revealed. It 971 is also permissible for the mailing list exploder to direct MDNs to 972 itself, correlate them, and produce a report to the original sender 973 of the message. 975 This specification places no restrictions on the processing of MDNs 976 received by user agents or mailing lists. 978 Message Disposition Notifications 17 November 1997 979 Internet Draft 981 6. Security considerations 983 The following security considerations apply when using MDNs: 985 6.1 Forgery 987 MDNs may be forged as easily as ordinary Internet electronic mail. 988 User agents and automatic mail handling facilities (such as mail 989 distribution list exploders) that wish to make automatic use of MDNs 990 should take appropriate precautions to minimize the potential damage 991 from denial-of-service attacks. 993 Security threats related to forged MDNs include the sending of: 995 (a) A falsified disposition notification when the indicated dis- 996 position of the message has not actually ocurred, 998 (b) Unsolicited MDNs 1000 6.2 Confidentiality 1002 Another dimension of security is confidentiality. There may be 1003 cases in which a message recipient does not wish the disposition of 1004 messages addressed to him to be known or is concerned that the 1005 sending of MDNs may reveal other confidential information (e.g., 1006 when the message was read). In this situation, it is acceptable for 1007 the UA to issue "denied" MDNs or to silently ignore requests for 1008 MDNs. 1010 If the Disposition-Notification-To header is passed on unmodified 1011 when a message is distributed to the subscribers of a mailing list, 1012 the subscribers to the list may be revealed to the sender of the 1013 original message by the generation of MDNs. 1015 Headers of the original message returned in part 3 of the 1016 multipart/report could reveal confidential information about host 1017 names and/or network topology inside a firewall. 1019 An unencrypted MDN could reveal confidential information about an 1020 encrypted message, especially if all or part of the original message 1021 is returned in part 3 of the multipart/report. Encrypted MDNs are 1022 not defined in this specification. 1024 In general, any optional MDN field may be omitted if the Reporting 1025 UA site or user determines that inclusion of the field would impose 1026 too great a compromise of site confidentiality. The need for such 1027 confidentiality must be balanced against the utility of the omitted 1028 information in MDNs. 1030 Message Disposition Notifications 17 November 1997 1031 Internet Draft 1033 6.3 Non-Repudiation 1035 Within the framework of today's Internet Mail, the MDNs defined in 1036 this document provide valuable information to the mail user; 1037 however, MDNs can not be relied upon as a guarantee that a message 1038 was or was not not seen by the recipient. Even if MDNs are not 1039 actively forged, they may be lost in transit. The MDN issuing 1040 mechanism may be bypassed in some manner by the recipient. 1042 Message Disposition Notifications 17 November 1997 1043 Internet Draft 1045 7. Collected Grammar 1047 NOTE: The following lexical tokens are defined in RFC 822: atom, 1048 CRLF, mailbox, msg-id, text. The definitions of attribute and value 1049 are as in the definition of the Content-Type header in RFC 2046 [5]. 1051 Message headers: 1053 mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox 1055 Disposition-Notification-Options = 1056 "Disposition-Notification-Options" ":" 1057 disposition-notification-parameters 1059 disposition-notification-parameters = parameter *(";" parameter) 1061 parameter = attribute "=" importance "," 1#value 1063 importance = "required" / "optional" 1065 original-recipient-header = 1066 "Original-Recipient" ":" address-type ";" generic-address 1068 Report content: 1070 disposition-notification-content = [ reporting-ua-field CRLF ] 1071 [ mdn-gateway-field CRLF ] 1072 [ original-recipient-field CRLF ] 1073 final-recipient-field CRLF 1074 [ original-message-id-field CRLF ] 1075 disposition-field CRLF 1076 *( failure-field CRLF ) 1077 *( error-field CRLF ) 1078 *( warning-field CRLF ) 1079 *( extension-field CRLF ) 1081 address-type = atom 1083 mta-name-type = atom 1085 reporting-ua-field = "Reporting-UA" ":" ua-name 1086 [ ";" ua-product ] 1088 ua-name = *text 1090 ua-product = *text 1092 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 1093 Message Disposition Notifications 17 November 1997 1094 Internet Draft 1096 mta-name = *text 1098 original-recipient-field = 1099 "Original-Recipient" ":" address-type ";" generic-address 1101 generic-address = *text 1103 final-recipient-field = 1104 "Final-Recipient" ":" address-type ";" generic-address 1106 disposition-field = "Disposition" ":" disposition-mode ";" 1107 disposition-type 1108 [ '/' disposition-modifier 1109 *( "," dispostion-modifier ) ] 1111 disposition-mode = action-mode "/" sending-mode 1113 action-mode = "manual-action" / "automatic-action" 1115 sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" 1117 disposition-type = "displayed" 1118 / "dispatched" 1119 / "processed" 1120 / "deleted" 1121 / "denied" 1122 / "failed" 1124 disposition-modifier = ( "error" / "warning" ) 1125 / ( "superseded" / "expired" / 1126 "mailbox-terminated" ) 1127 / disposition-modifier-extension 1129 disposition-modifier-extension = atom 1131 original-message-id-field = "Original-Message-ID" ":" msg-id 1133 failure-field = "Failure" ":" *text 1135 error-field = "Error" ":" *text 1137 warning-field = "Warning" ":" *text 1139 extension-field = extension-field-name ":" *text 1141 extension-field-name = atom 1142 Message Disposition Notifications 17 November 1997 1143 Internet Draft 1145 8. Guidelines for Gatewaying MDNs 1147 NOTE: This section provides non-binding recommendations for the 1148 construction of mail gateways that wish to provide semi-transparent 1149 disposition notifications between the Internet and another 1150 electronic mail system. Specific MDN gateway requirements for a 1151 particular pair of mail systems may be defined by other documents. 1153 8.1 Gatewaying from other mail systems to MDNs 1155 A mail gateway may issue an MDN to convey the contents of a "for- 1156 eign" disposition notification over Internet Mail. When there are 1157 appropriate mappings from the foreign notification elements to MDN 1158 fields, the information may be transmitted in those MDN fields. 1159 Additional information (such as might be needed to tunnel the 1160 foreign notification through the Internet) may be defined in exten- 1161 sion MDN fields. (Such fields should be given names that identify 1162 the foreign mail protocol, e.g. X400-* for X.400 protocol elements) 1164 The gateway must attempt to supply reasonable values for the 1165 Reporting-UA, Final-Recipient, and Disposition fields. These will 1166 normally be obtained by translating the values from the foreign 1167 notification into their Internet-style equivalents. However, some 1168 loss of information is to be expected. 1170 The sender-specified recipient address, and the original message-id, 1171 if present in the foreign notification, should be preserved in the 1172 Original-Recipient and Original-Message-ID fields. 1174 The gateway should also attempt to preserve the "final" recipient 1175 address from the foreign system. Whenever possible, foreign 1176 protocol elements should be encoded as meaningful printable ASCII 1177 strings. 1179 For MDNs produced from foreign disposition notifications, the name 1180 of the gateway MUST appear in the MDN-Gateway field of the MDN. 1182 Message Disposition Notifications 17 November 1997 1183 Internet Draft 1185 8.2 Gatewaying from MDNs to other mail systems 1187 It may be possible to gateway MDNs from the Internet into a foreign 1188 mail system. The primary purpose of such gatewaying is to convey 1189 disposition information in a form that is usable by the destination 1190 system. A secondary purpose is to allow "tunneling" of MDNs through 1191 foreign mail systems, in case the MDN may be gatewayed back into the 1192 Internet. 1194 In general, the recipient of the MDN (i.e., the sender of the 1195 original message) will want to know, for each recipient: the 1196 closest available approximation to the original recipient address, 1197 and the disposition (displayed, printed, etc.). 1199 If possible, the gateway should attempt to preserve the Original- 1200 Recipient address and Original-Message-ID (if present), in the 1201 resulting foreign disposition report. 1203 If it is possible to tunnel an MDN through the destination environ- 1204 ment, the gateway specification may define a means of preserving the 1205 MDN information in the disposition reports used by that environment. 1207 Message Disposition Notifications 17 November 1997 1208 Internet Draft 1210 9. Example 1212 NOTE: This example is provided as illustration only, and is not 1213 considered part of the MDN protocol specification. If the example 1214 conflicts with the protocol definition above, the example is wrong. 1216 Likewise, the use of *-type subfield names or extension fields in 1217 this example is not to be construed as a definition for those type 1218 names or extension fields. 1220 9.1 This is an MDN issued after a message has been displayed to the 1221 user of an Internet Mail user agent. 1223 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 1224 From: Joe Recipient 1225 Message-Id: <199509200019.12345@mega.edu> 1226 Subject: Disposition notification 1227 To: Jane Sender 1228 MIME-Version: 1.0 1229 Content-Type: multipart/report; report-type=disposition-notification; 1230 boundary="RAA14128.773615765/mega.edu" 1232 --RAA14128.773615765/mega.edu 1234 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to 1235 Joe Recipient with subject "First 1236 draft of report" has been displayed. This is no guarantee 1237 that the message has been read or understood. 1239 --RAA14128.773615765/mega.edu 1240 content-type: message/disposition-notification 1242 Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1 1243 Original-Recipient: rfc822;Joe_Recipient@mega.edu 1244 Final-Recipient: rfc822;Joe_Recipient@mega.edu 1245 Original-Message-ID: <199509192301.12345@mega.edu> 1246 Disposition: manual-action/MDN-sent-manually; displayed 1248 --RAA14128.773615765/mega.edu 1249 content-type: message/rfc822 1251 [original message goes here] 1253 --RAA14128.773615765/mega.edu-- 1254 Message Disposition Notifications 17 November 1997 1255 Internet Draft 1257 10. IANA Registration Forms 1259 The forms below are for use when registering a new parameter name 1260 for the Disposition-Notification-Options header, a new disposition 1261 modifier name, or a new MDN extension field. Each piece of informa- 1262 tion required by a registration form may be satisfied either by 1263 providing the information on the form itself, or by including a 1264 reference to a published, publicly available specification that 1265 includes the necessary information. IANA MAY reject registrations 1266 because of incomplete registration forms, imprecise specifications, 1267 or inappropriate names. 1269 To register, complete the applicable form below and send it via 1270 electronic mail to . 1272 10.1 IANA registration form for Disposition-Notification-Options 1273 header parameter names 1275 A registration for a Disposition-Notification-Options header 1276 parameter name MUST include the following information: 1278 (a) The proposed parameter name. 1280 (b) The syntax for parameter values, specified using BNF, ABNF, 1281 regular expressions, or other non-ambiguous language. 1283 (c) If parameter values are not composed entirely of graphic charac- 1284 ters from the US-ASCII repertoire, a specification for how they are 1285 to be encoded as graphic US-ASCII characters in a Disposition- 1286 Notification-Options header. 1288 (d) A reference to a standards track RFC or experimental RFC ap- 1289 proved by the IESG that describes the semantics of the parameter 1290 values. 1292 10.2 IANA registration form for disposition modifer names 1294 A registration for a disposition-modifier name MUST include the 1295 following information: 1297 (a) The proposed disposition-modifier name. 1299 (b) A reference to a standards track RFC or experimental RFC ap- 1300 proved by the IESG that describes the semantics of the disposition 1301 modifier. 1303 Message Disposition Notifications 17 November 1997 1304 Internet Draft 1306 10.3 IANA registration form for MDN extension field names 1308 A registration for an MDN extension field name MUST include the 1309 following information: 1311 (a) The proposed extension field name. 1313 (b) The syntax for extension values, specified using BNF, ABNF, 1314 regular expressions, or other non-ambiguous language. 1316 (c) If extension field values are not composed entirely of graphic 1317 characters from the US-ASCII repertoire, a specification for how 1318 they are to be encoded as graphic US-ASCII characters in a 1319 Disposition-Notification-Options header. 1321 (d) A reference to a standards track RFC or experimental RFC ap- 1322 proved by the IESG that describes the semantics of the extension 1323 field. 1325 Message Disposition Notifications 17 November 1997 1326 Internet Draft 1328 11. Acknowledgments 1330 This document is based on the Delivery Status Notifications docu- 1331 ment, RFC 1894 [9], by Keith Moore and Greg Vaudreuil. Contribu- 1332 tions were made by members of the IETF Receipt Working Group, 1333 including Harald Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri 1334 Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, 1335 Paul Overell, Pete Resnick, Chuck Shih. 1337 Message Disposition Notifications 17 November 1997 1338 Internet Draft 1340 12. References 1342 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1343 USC/Information Sciences Institute, August 1982. 1345 [2] Crocker, D., "Standard for the Format of ARPA Internet Text 1346 Messages", STD 11, RFC 822, UDEL, August 1982. 1348 [3] Braden, R. (ed.), "Requirements for Internet Hosts - Applica- 1349 tion and Support", RFC 1123, October 1989. 1351 [4] Freed, N., Borenstein, N., "Multipurpose Internet Mail Exten- 1352 sions (MIME) Part One: Format of Internet Message Bodies", 1353 RFC 2045, Innosoft, Bellcore, November 1996. 1355 [5] Freed, N., Borenstein, N., "Multipurpose Internet Mail Exten- 1356 sions (MIME) Part Two: Media Types", RFC 2046, Innosoft, 1357 Bellcore, November 1996. 1359 [6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part 1360 Three: Message Header Extensions for Non-Ascii Text", RFC 1361 2047, University of Tennessee, November 1996. 1363 [7] Vaudreuil, G., "The Multipart/Report Content Type for the 1364 Reporting of Mail System Administrative Messages", RFC 1892, 1365 Octel Network Services, January 1996. 1367 [8] Moore, K., "SMTP Service Extension for Delivery Status 1368 Notifications", RFC 1891, University of Tennessee, January 1369 1996. 1371 [9] Moore, K. and Vaudreuil, G., "An Extensible Format for 1372 Delivery Status Notifications, RFC 1894, University of Ten- 1373 nessee, Octel Network Services, January 1996. 1375 [10] Bradner, S., "Key Words for Use in RFCs to Indicate Require- 1376 ment Levels", RFC 2119, March 1997. 1378 Message Disposition Notifications 17 November 1997 1379 Internet Draft 1381 13. Copyright | 1382 | 1383 Copyright (C) The Internet Society (17 October 1997). All Rights | 1384 Reserved. | 1385 | 1386 This document and translations of it may be copied and furnished to | 1387 others, and derivative works that comment on or otherwise explain it | 1388 or assist in its implmentation may be prepared, copied, published | 1389 and distributed, in whole or in part, without restriction of any | 1390 kind, provided that the above copyright notice and this paragraph | 1391 are included on all such copies and derivative works. However, this | 1392 document itself may not be modified in any way, such as by removing | 1393 the copyright notice or references to the Internet Society or other | 1394 Internet organizations, except as needed for the purpose of develop- | 1395 ing Internet standards in which case the procedures for copyrights | 1396 defined in the Internet Standards process must be followed, or as | 1397 required to translate it into languages other than English. | 1398 | 1399 The limited permissions granted above are perpetual and will not be | 1400 revoked by the Internet Society or its successors or assigns. | 1401 | 1402 This document and the information contained herein is provided on an | 1403 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | 1404 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | 1405 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | 1406 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | 1407 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | 1408 Message Disposition Notifications 17 November 1997 1409 Internet Draft 1411 14. Author's Address | 1413 Roger Fajman 1414 National Institutes of Health 1415 Building 12A, Room 3063 1416 12 South Drive MSC 5659 1417 Bethesda, Maryland 20892-5659 1418 USA 1420 Email: raf@cu.nih.gov 1421 Voice: +1 301 402 4265 1422 Fax: +1 301 480 6241