idnits 2.17.1 draft-ietf-receipt-mdn-02.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. Expected boilerplate is as follows today (2024-04-24) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 198: '...position-notification-to header SHOULD...' RFC 2119 keyword, line 242: '...f this parameter MAY generate an MDN i...' RFC 2119 keyword, line 249: '...ames NOT beginning with "X-" MUST |...' RFC 2119 keyword, line 274: '...e delivering MTA SHOULD insert an Orig...' RFC 2119 keyword, line 320: '...The MDN MUST be addressed (in both the...' (18 more instances...) 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: without. The other headers of the message (To, cc, bcc, etc.) must be the same in both copies. The recipients in the respective message envelopes determine for whom message disposition notifica-tions are requested and for whom they are not. If desired, the Message-ID header may be the same in both copies of the message. | | 2.2 The Disposition-Notification-Options Header | | Future extenstions to this specification may require that informa- | tion be supplied to the recipient's UA for additional control over | how and what MDNs are generated. The Disposition-notification- | options header provides an extensible mechanism for such informa- | tion. The syntax of this header using the ABNF of RFC 822 [5] is | | Disposition-notification-options = | "Disposition-notification-options" ":" | disposition-notification-parameters | | Disposition-notification-parameters = parameter *(";" parameter) | | parameter = attribute "=" importance "," 1#value | | importance = "R" / "O" | | The definitions of attribute and value are as in the definition of | the Content-type header in RFC 1521 [1]. | | An importance of R indicates that interpretation of the parameter is | required for proper generation of an MDN in response to this re- | quest. If a UA does not understand the meaning of the parameter, it | MUST not generate an MDN in response to the request. An importance | of O (the letter) indicates that a UA that does not understand the | meaning of this parameter MAY generate an MDN in response anyway, | ignoring the value of the parameter. | | No parameters are defined in this specification. Parameters may be | defined in the future by later revisions or extensions to this | specification. Parameter attribute names beginning with "X-" will | never be defined as standard names; such names are reserved for | experimental use. MDN parameter names NOT beginning with "X-" MUST | be registered with the Internet Assigned Numbers Authority (IANA) | and described in an RFC. | | [Author's note: is the concept of required and optional parameters | above adequate? What should be done if the parameter name is | understood, but the values are invalid? Do we need a disposition to | indicate errors in required parameters?] | | == 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: "autodenied" The recipient does not wish the sender to be informed of the message's disposition and has requested that this MDN be sent automatically. A UA may also siliently ignore message disposition requests in this situa-tion. | disposition-value-extension Additional disposition values may be | defined in the future by later revi- | sions or extensions to this specifica- | tion. Disposition value names begin- | ning 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 an RFC. MDNs | with disposition value 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 (26 November 1996) is 10011 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: '3' is defined on line 1049, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1521 (ref. '1') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1892 (ref. '2') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1891 (ref. '4') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1522 (ref. '6') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1894 (ref. '8') (Obsoleted by RFC 3464) Summary: 17 errors (**), 0 flaws (~~), 5 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: 1 June 1997 26 November 1996 5 An Extensible Message Format 6 for Message Disposition Notifications 8 draft-ietf-receipt-mdn-02.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), nic.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 26 November 1996 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 1. Introduction 67 This memo defines a MIME [1] content-type for message disposition 68 notifications (MDNs). An MDN can be used to notify the sender of a 69 message of any of several conditions that may occur after successful 70 delivery, such as display of the message contents, printing of the 71 message, deletion (without display) of the message, or the 72 recipient's refusal to provide MDNs. The 73 "message/disposition-notification" content-type defined herein is 74 intended for use within the framework of the "multipart/report" 75 content type defined in RFC 1892 [2]. 77 This memo defines the format of the notifications and the RFC 822 78 headers used to request them. 80 1.1 Purposes 82 The MDNs defined in this memo are expected to serve several pur- 83 poses: 85 (a) Inform human beings of the disposition of messages after 86 succcessful delivery, in a manner which is largely independent 87 of human language; 89 (b) Allow mail user agents to keep track of the disposition of 90 messages sent, by associating returned MDNs with earlier 91 message transmissions; 93 (c) Convey disposition notification requests and disposition 94 notifications between Internet Mail and "foreign" mail systems 95 via a gateway; 97 (d) Allow "foreign" notifications to be tunneled through a MIME- 98 capable message system and back into the original messaging 99 system that issued the original notification, or even to a 100 third messaging system; 102 Message Disposition Notifications 26 November 1996 103 Internet Draft 105 (e) Allow language-independent, yet reasonably precise, indications 106 of the disposition of a message to be delivered. 108 1.2 Requirements 110 These purposes place the following constraints on the notification 111 protocol: 113 (a) It must be readable by humans, as well as being machine- 114 parsable. 116 (b) It must provide enough information to allow message senders (or 117 the user agents) to unambiguously associate an MDN with the 118 message that was sent and the original recipient address for 119 which the MDN is issued (if such information is available), 120 even if the message was forwarded to another recipient address. 122 (c) It must also be able to describe the disposition of a message 123 independent of any particular human language or of the ter- 124 minology of any particular mail system. 125 | 126 (d) The specification must be extensible in order to accomodate | 127 future requirements. | 129 2. Requesting Message Disposition Notifications | 130 | 131 Message disposition notifications are requested by including a | 132 Disposition-notification-to header in the message. Further informa- | 133 tion to be used by the recipient's UA in generating the MDN may be | 134 provided by including Original-recipient and/or Disposition- | 135 notification-options headers in the message. | 136 | 137 | 138 2.1 The Disposition-Notification-To Header | 140 A request that the receiving user agent issue message disposition 141 notifications is made by placing a Disposition-notification-to 142 header into the message. The syntax of the header using the ABNF of 143 RFC 822 [5] is 145 mdn-request-header = "Disposition-notification-to" ":" 1#mailbox | 147 The address token is as specified in RFC 822 [5]. 149 The presence of a Disposition-notification-to header in a message is 150 merely a request for an MDN. The recipients' user agents are always 151 free to silently ignore such a request. Alternatively, an explicit 152 denial of the request for information about the disposition of the 153 Message Disposition Notifications 26 November 1996 154 Internet Draft 156 message may be sent using the "denied" or "autodenied" disposition 157 in an MDN. 159 One and only one MDN may be issued on behalf of each particular 160 recipient by their user agent. That is, once an MDN has been issued 161 on behalf of a recipient, no further MDNs may be issued on behalf of 162 that recipient, even if another disposition is performed on the 163 message. However, if a message is forwarded, a "processed" or 164 "autoprocessed" MDN may been issued for the recipient doing the 165 forwarding and the recipient of the forwarded message may also cause 166 an MDN to be generated. 168 While Internet standards normally do not specify the behavior of 169 user interfaces, it is strongly recommended that the user agent 170 obtain the user's consent before sending an MDN. This consent could 171 be obtained for each message through some sort of prompt or dialog 172 box, or globally through the user's setting of a preference. The 173 user might also indicate globally that MDNs are never to be sent or 174 that a "denied" MDN is always sent in response to a request for an 175 MDN. 177 It is also strongly recommended that MDNs never be sent automati- 178 cally if the address in the Disposition-notification-to header 179 differs from the address in the Return-path header (see RFC 822 180 [5]). In this case, confirmation from the user should be obtained, 181 if possible. If obtaining consent is not possible (e.g., because 182 the user is not online at the time), then no MDN should be sent. 183 | 184 It is also recommended that confirmation from the user always be | 185 obtained (or no MDN sent) if there is no Return-path header in the | 186 message, or if there is more than one distinct address in the | 187 Disposition-notification-to header. The comparison of the addresses | 188 should be done using only the addr-spec (local-part "@" domain) | 189 portion, excluding any phrase and route. If the message contains | 190 more than one Return-path header, the implementation may pick one to | 191 use for the comparison, or treat the situation as a failure of the | 192 comparison. | 193 | 194 The reason for not automatically sending an MDN if the comparison | 195 fails is to reduce the possibilities for mail loops and use of MDNs | 196 for mail bombing. | 198 A message that contains a Disposition-notification-to header SHOULD 199 also contain a Message-ID header as specified in RFC 822 [5]. This 200 will permit automatic correlation of MDNs with original messages by 201 user agents. 203 If it is desired to request message disposition notifications for 204 some recipients and not others, two copies of the message should be 205 sent, one with an Disposition-notification-to header and one 206 Message Disposition Notifications 26 November 1996 207 Internet Draft 209 without. The other headers of the message (To, cc, bcc, etc.) must 210 be the same in both copies. The recipients in the respective 211 message envelopes determine for whom message disposition notifica- 212 tions are requested and for whom they are not. If desired, the 213 Message-ID header may be the same in both copies of the message. 214 | 215 | 216 2.2 The Disposition-Notification-Options Header | 217 | 218 Future extenstions to this specification may require that informa- | 219 tion be supplied to the recipient's UA for additional control over | 220 how and what MDNs are generated. The Disposition-notification- | 221 options header provides an extensible mechanism for such informa- | 222 tion. The syntax of this header using the ABNF of RFC 822 [5] is | 223 | 224 Disposition-notification-options = | 225 "Disposition-notification-options" ":" | 226 disposition-notification-parameters | 227 | 228 Disposition-notification-parameters = parameter *(";" parameter) | 229 | 230 parameter = attribute "=" importance "," 1#value | 231 | 232 importance = "R" / "O" | 233 | 234 The definitions of attribute and value are as in the definition of | 235 the Content-type header in RFC 1521 [1]. | 236 | 237 An importance of R indicates that interpretation of the parameter is | 238 required for proper generation of an MDN in response to this re- | 239 quest. If a UA does not understand the meaning of the parameter, it | 240 MUST not generate an MDN in response to the request. An importance | 241 of O (the letter) indicates that a UA that does not understand the | 242 meaning of this parameter MAY generate an MDN in response anyway, | 243 ignoring the value of the parameter. | 244 | 245 No parameters are defined in this specification. Parameters may be | 246 defined in the future by later revisions or extensions to this | 247 specification. Parameter attribute names beginning with "X-" will | 248 never be defined as standard names; such names are reserved for | 249 experimental use. MDN parameter names NOT beginning with "X-" MUST | 250 be registered with the Internet Assigned Numbers Authority (IANA) | 251 and described in an RFC. | 252 | 253 [Author's note: is the concept of required and optional parameters | 254 above adequate? What should be done if the parameter name is | 255 understood, but the values are invalid? Do we need a disposition to | 256 indicate errors in required parameters?] | 257 | 259 Message Disposition Notifications 26 November 1996 260 Internet Draft 262 [Author's note: What should we do if there is a disposition- | 263 notification-options header, but no disposition-notification-to | 264 header?] | 266 | 267 2.3 The Original-Recipient Header | 268 | 269 Since electronic mail addresses may be rewritten while the message 270 is in transit, it is useful for the original recipient address to be 271 made available by the delivering MTA. The MTA may be able to obtain 272 this information from the ORCPT parameter of the SMTP MAIL FROM 273 command, as defined in RFC 1891 [4]. If this information is avail- 274 able, the delivering MTA SHOULD insert an Original-recipient header 275 into the message. The syntax of this header using the ABNF of RFC 276 822 [5] is as follows 278 original-recipient-header = 279 "Original-Recipient" ":" address-type ";" generic-address 281 The address-type and generic-address token are as as specified in 282 the description of the Original-recipient field in section 3.2.3. 284 The purpose of carrying the original recipient information and 285 returning it in the MDN is to permit automatic correlation of MDNs 286 with the original message on a per-recipient basis. 288 3. Format of a Message Disposition Notification 290 A message disposition notification is a MIME message with a top- 291 level content-type of multipart/report (defined in RFC 1892 [2]). 292 When a multipart/report content is used to transmit an MDN: 294 (a) The report-type parameter of the multipart/report content is 295 "disposition-notification". 297 (b) The first component of the multipart/report contains a human- 298 readable explanation of the MDN, as described in RFC 1892 [2]. 300 (c) The second component of the multipart/report is of content-type 301 message/disposition-notification, described in section 3.1 of 302 this document. 304 (d) If the original message or a portion of the message is to be 305 returned to the sender, it appears as the third component of 306 the multipart/report. 308 NOTE: For message dispostion notifications gatewayed from 309 foreign systems, the headers of the original message may not be 310 available. In this case the third component of the MDN may be 312 Message Disposition Notifications 26 November 1996 313 Internet Draft 315 omitted, or it may contain "simulated" RFC 822 headers which 316 contain equivalent information. In particular, it is very 317 desirable to preserve the subject and date fields from the 318 original message. 320 The MDN MUST be addressed (in both the message header and the 321 transport envelope) to the address from the Disposition- 322 notification-to header which from the original message for which the 323 MDN was generated. 325 The From field of the message header of the MDN MUST contain the 326 address of the person on whose behalf the message disposition 327 notification is being issued. 329 The envelope sender address (i.e., SMTP MAIL FROM) of the MDN should 330 be null (<>), specifying that no Delivery Status Notification 331 messages or other messages indicating successful or unsuccessful 332 delivery are to be sent in response to an MDN. 334 A message disposition notification MUST NOT itself request an MDN. 335 That is, it MUST NOT contain a Disposition-notification-to header. 337 The Message-ID header (if present) for an MDN MUST be different from 338 the Message-ID of the message for which the MDN is being issued. 340 A particular MDN describes the disposition of exactly one message 341 for exactly one recipient. Multiple MDNs may be generated as a 342 result of one message submission, one per recipient. However, due 343 to various circumstances, MDNs may not be generated for some 344 recipients for which MDNs were requested. 346 3.1 The message/disposition-notification content-type 348 The message/disposition-notification content-type is defined as 349 follows: 351 MIME type name: message 352 MIME subtype name: disposition-notification 353 Optional parameters: none 354 Encoding considerations: "7bit" encoding is sufficient and 355 MUST be used to maintain readability 356 when viewed by non-MIME mail 357 readers. 358 Security considerations: discussed in section 5 of this memo. 360 The message/disposition-notification report type for use in the 361 multipart/report is "disposition-notification". 363 Message Disposition Notifications 26 November 1996 364 Internet Draft 366 The body of a message/delivery-status consists of one or more 367 "fields" formatted according to the ABNF of RFC 822 header "fields" 368 (see [5]). Using the ABNF of RFC 822, the syntax of the 369 message/disposition-notification content is as follows: 371 disposition-notification-content = [ reporting-ua-field CRLF ] 372 [ mdn-gateway-field CRLF ] 373 [ original-recipient-field CRLF ] 374 final-recipient-field CRLF 375 [ original-message-id-field CRLF ] 376 disposition-field CRLF | 377 *( extension-field CRLF ) 379 3.1.1 General conventions for fields 381 Since these fields are defined according to the rules of RFC 822 | 382 [5], the same conventions for continuation lines and comments apply. | 383 Notification fields may be continued onto multiple lines by begin- 384 ning each additional line with a SPACE or HTAB. Text which appears 385 in parentheses is considered a comment and not part of the contents 386 of that notification field. Field names are case-insensitive, so 387 the names of notification fields may be spelled in any combination 388 of upper and lower case letters. Comments in notification fields 389 may use the "encoded-word" construct defined in [6]. 391 3.1.2 "*-type" subfields 393 Several fields consist of a "-type" subfield, followed by a semi- 394 colon, followed by "*text". For these fields, the keyword used in 395 the address-type or MTA-type subfield indicates the expected format 396 of the address or MTA-name that follows. 398 The "-type" subfields are defined as follows: 400 (a) An "address-type" specifies the format of a mailbox address. 401 For example, Internet mail addresses use the "rfc822" address- 402 type. 404 address-type = atom 406 (b) An "MTA-name-type" specifies the format of a mail transfer 407 agent name. For example, for an SMTP server on an Internet 408 host, the MTA name is the domain name of that host, and the 409 "dns" MTA-name-type is used. 411 mta-name-type = atom 413 Message Disposition Notifications 26 November 1996 414 Internet Draft 416 Values for address-type and mta-name-type are case-insensitive. 417 Thus address-type values of "RFC822" and "rfc822" are equivalent. 419 The Internet Assigned Numbers Authority (IANA) will maintain a 420 registry of address-type and mta-name-type values, along with 421 descriptions of the meanings of each, or a reference to a one or 422 more specifications that provide such descriptions. (The "rfc822" 423 address-type is defined in RFC 1891 [4].) Registration forms for 424 address-type and mta-name-type appear in RFC 1894 [8]. 426 IANA will not accept registrations for any address-type name that 427 begins with "X-". These type names are reserved for experimental 428 use. 430 3.1.3 Lexical tokens imported from RFC 822 432 The following lexical tokens, defined in RFC 822 [5], are used in 433 the ABNF grammar for MDNs: addr-spec, atom, CHAR, comment, CR, 434 CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time 435 lexical token is defined in RFC 1123 [7]. 437 3.2 Message/disposition-notification Fields 439 3.2.1 The Reporting-UA field 441 reporting-ua-field = "Reporting-UA" ":" ua-name 443 ua-name = *text 445 The Reporting-UA field is defined as follows: 447 A MDN describes the disposition of a message after it has been 448 delivered a recipient. In all cases, the Reporting-UA is the UA 449 that performed the disposition described in the MDN. This field is 450 optional, but recommended. For Internet Mail user agents, it is 451 recommended that this field contain both the DNS name of the par- 452 ticular instance of the UA that generated the MDN and the name of 453 the product. For example, 455 Reporting-UA: rogers-mac.dcrt.nih.gov (Foomail 97.1) 457 3.2.2 The MDN-Gateway field 459 The MDN-Gateway field indicates the name of the gateway or MTA that 460 translated a foreign (non-Internet) message disposition notification 461 into this MDN. This field MUST appear in any MDN which was trans- 462 Message Disposition Notifications 26 November 1996 463 Internet Draft 465 lated by a gateway from a foreign system into MDN format, and MUST 466 NOT appear otherwise. 468 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 470 For gateways into Internet mail, the MTA-name-type will normally be 471 "smtp", and the mta-name will be the Internet domain name of the 472 gateway. 474 3.2.3 Original-Recipient field 476 The Original-Recipient field indicates the original recipient 477 address as specified by the sender of the message for which the MDN 478 is being issued. For Internet Mail messages the value of the 479 Original-Recipient field is obtained from the Original-Recipient 480 header from the message for which the MDN is being generated. If 481 there is no Original-Recipient header in the message, then the 482 Original-Recipient field MUST be omitted. If there is an Original- 483 Recipient header in the original message (or original recipient 484 information is available some other way), then the Original- 485 Recipient field must be supplied. 487 original-recipient-field = 488 "Original-Recipient" ":" address-type ";" generic-address 490 generic-address = *text 492 The address-type field indicates the type of the original recipient 493 address. If the message originated within the Internet, the 494 address-type field field will normally be "rfc822", and the address 495 will be according to the syntax specified in [5]. The value "un- 496 known" should be used if the Reporting UA cannot determine the type 497 of the original recipient address from the message envelope. This 498 address is the same as that provided by the sender and can be used 499 to automatically correlate MDN reports with original messages on a 500 per recipient basis. 502 3.2.4 Final-Recipient field 504 The Final-Recipient field indicates the recipient for which the MDN 505 is being issued. This field MUST be present. 507 The syntax of the field is as follows: 509 final-recipient-field = 510 "Final-Recipient" ":" address-type ";" generic-address 512 Message Disposition Notifications 26 November 1996 513 Internet Draft 515 The generic-address subfield of the Final-Recipient field MUST 516 contain the mailbox address of the recipient (from the From header) 517 as it was when the message was accepted by the UA. 519 The Final-Recipient address may differ from the address originally 520 provided by the sender, because it may have been transformed during 521 forwarding and gatewaying into an totally unrecognizable mess. 522 However, in the absence of the optional Original-Recipient field, 523 the Final-Recipient field and any returned content may be the only 524 information available with which to correlate the MDN with a par- 525 ticular message recipient. 527 The address-type subfield indicates the type of address expected by 528 the reporting MTA in that context. Recipient addresses obtained via 529 SMTP will normally be of address-type "rfc822". 531 Since mailbox addresses (including those used in the Internet) may 532 be case sensitive, the case of alphabetic characters in the address 533 MUST be preserved. 535 3.2.5 Original-Message-ID field 537 The Original-Message-ID field indicates the message-ID of the 538 message for which the MDN is being issued. It is obtained from the 539 Message-ID header of the message for which the MDN is issued. This 540 field MUST be present if the original message contained a Message-ID 541 header. The syntax of the field is 543 original-message-id-field = "Original-Message-ID" ":" msg-id | 545 The msg-id token is as specified in RFC 822 [5]. | 547 3.2.6 Disposition field 549 The Disposition field indicates the action performed by the 550 Reporting-UA on behalf of the user. This field MUST be present. 552 The syntax for the action-field is: 554 Message Disposition Notifications 26 November 1996 555 Internet Draft 557 disposition-field = "Disposition" ":" disposition-value 559 disposition-value = 560 "acknowledged" / "autoacknowledged" / | 561 "processed" / "autoprocessed" / | 562 "deleted" / "autodeleted" / | 563 "obsoleted" / "expired" / "terminated" / | 564 "denied" / "autodenied" / | 565 disposition-value-extension | 566 | 567 disposition-value-extension = atom | 569 The disposition-value may be spelled in any combination of upper and 570 lower case characters. 572 "acknowledged" The message has been displayed by the | 573 UA to someone reading the recipient's | 574 mailbox and that person explicitly | 575 allowed the UA to send an MDN. There | 576 is no guarantee that the content has | 577 been read or understood. 579 "autoacknowledged" The message has been displayed by the | 580 UA to someone reading the recipient's | 581 mailbox and the UA sent an MDN auto- | 582 matically. There is no guarantee that | 583 the content has been read or under- | 584 stood. | 585 | 586 "processed" The message has been processed in some 587 manner (e.g., printed, faxed, for- 588 warded) in response to a user command, 589 without being displayed to the user. 590 The user may or may not see the 591 message later. 593 "autoprocessed" The message has been processed auto- 594 matically in some manner (e.g., 595 printed, faxed, forwarded, gatewayed) 596 in response to some user request made 597 in advance, without being displayed to 598 the user. The user may or may not see 599 the message later. 601 "deleted" The message has been manually deleted. 602 The recipient may or may not have seen 603 the message. The recipient might 604 "undelete" the message at a later time 605 and read the message. 607 Message Disposition Notifications 26 November 1996 608 Internet Draft 610 "autodeleted" The message has been automatically 611 deleted without being displayed to the 612 recipient. 614 "obsoleted" The message has been automatically 615 rendered obsolete by another message 616 received. The recipient may still 617 access and read the message later. 619 "expired" The message has reached its expiration 620 date and has been automatically 621 removed from the recipient's mailbox. 623 "terminated" The recipient's mailbox has been 624 terminated and all message in it 625 automatically removed. 627 "denied" The recipient does not wish the sender 628 to be informed of the message's 629 disposition. A UA may also siliently 630 ignore message disposition requests in 631 this situation. 633 "autodenied" The recipient does not wish the sender 634 to be informed of the message's 635 disposition and has requested that 636 this MDN be sent automatically. A UA 637 may also siliently ignore message 638 disposition requests in this situa- 639 tion. 640 | 641 disposition-value-extension Additional disposition values may be | 642 defined in the future by later revi- | 643 sions or extensions to this specifica- | 644 tion. Disposition value names begin- | 645 ning with "X-" will never be defined | 646 as standard values; such names are | 647 reserved for experimental use. MDN | 648 disposition value names NOT beginning | 649 with "X-" MUST be registered with the | 650 Internet Assigned Numbers Authority | 651 (IANA) and described in an RFC. MDNs | 652 with disposition value names not | 653 understood by the receiving UA MAY be | 654 silently ignored or placed in the | 655 user's mailbox without special inter- | 656 pretation. They MUST not cause any | 657 error message to be sent to the sender | 658 of the MDN. | 660 Message Disposition Notifications 26 November 1996 661 Internet Draft 663 It is not required that a UA be able to generate all of the possible 664 values of the Disposition field. 666 One and only one MDN may be issued on behalf of each particular 667 recipient by their user agent. That is, once an MDN has been issued 668 on behalf of a recipient, no further MDNs may be issued on behalf of 669 that recipient, even if another disposition is performed on the 670 message. However, if a message is forwarded, a "processed" or 671 "autoprocessed" MDN may been issued for the recipient doing the 672 forwarding and the recipient of the forwarded message may also cause 673 an MDN to be generated. 675 | 676 3.3 Extension fields | 678 Additional MDN fields may be defined in the future by later revi- 679 sions or extensions to this specification. Extension-field names 680 beginning with "X-" will never be defined as standard fields; such 681 names are reserved for experimental use. MDN field names NOT 682 beginning with "X-" MUST be registered with the Internet Assigned 683 Numbers Authority (IANA) and described in an RFC. 685 Extension MDN fields may be defined for the following reasons: 687 (a) To allow additional information from foreign disposition 688 reports to be tunneled through Internet MDNs. The names of 689 such MDN fields should begin with an indication of the foreign 690 environment name (e.g. X400-Physical-Forwarding-Address). 692 (b) To allow transmission of diagnostic information which is 693 specific to a particular user agent (UA). The names of such 694 MDN fields should begin with an indication of the UA implemen- 695 tation which produced the MDN. (e.g. Foomail-information). 697 If an UA developer does not wish to register the meanings of such 698 extension fields, "X-" fields may be used for this purpose. To 699 avoid name collisions, the name of the UA implementation should 700 follow the "X-", (e.g. "X-Foomail-Log-ID"). 702 4. Timeline of events 704 The following timeline shows when various events in the processing 705 of a message and generation of MDNs take place: 707 --- User composes message 708 | 709 |-- User tells UA to send message 710 | 711 |-- UA passes message to MTA (original recipient information 712 Message Disposition Notifications 26 November 1996 713 Internet Draft 715 | passed along) 716 | 717 |-- MTA sends message to next MTA 718 . 719 . 720 . 721 |-- Final MTA receives message 722 | 723 |-- Final MTA delivers message to UA (possibily generating DSN) 724 | 725 |-- UA performs automatic processing and generates corresponding 726 | MDNs (autoprocessed, autodeleted, obsoleted, expired, 727 | terminated, autodenied) 728 | 729 |-- UA displays list of messages to user 730 | 731 |-- User selects a message and requests that some action be 732 | performed on it. 733 | 734 |-- UA performs requested action and, with user's permission, 735 | sends appropriate MDN (displayed, processed, denied). 736 | 737 |-- User possibly performs other actions on message, but no 738 | further MDNs are generated 740 5. Conformance and Usage Requirements 742 A UA or gateway conforms to this specification if it generates MDNs 743 according to the protocol defined in this memo. It is not necessary 744 to be able to generate all of the possible values of the Disposition 745 field. 747 UAs and gateways MUST NOT generate the Original-Recipient field of 748 an MDN unless the mail protocols provide the address originally 749 specified by the sender at the time of submission. Ordinary SMTP 750 does not make that guarantee, but the SMTP extension defined in RFC 751 1891 [4] permits such information to be carried in the envelope if 752 it is available. The Original-Recipient header defined in this 753 document provides a way for the MTA to pass the original recipient 754 address to the UA. 756 Each sender-specified recipient address may result in more than one 757 MDN. If an MDN is requested for a recipient that is forwarded to 758 multiple recipients of an "alias" (as defined in RFC 1891 [4], 759 section 7.2.7), each of the recipients may issue an MDN. 761 Successful distribution of a message to a mailing list exploder may 762 be considered final disposition of the message. A mailing list 763 exploder may issue an "autoprocessed" MDN indicating that the 764 Message Disposition Notifications 26 November 1996 765 Internet Draft 767 message has been forwarded to the list. In this case, the request 768 for MDNs is not propogated to the members of the list. Alterna- 769 tively, the mailing list exploder may issue no MDN and propogate the 770 request for MDNs to all members of the list. The later behavior is 771 not recommended for any but small, closely knit lists, as it might 772 cause large numbers of MDNs to be generated and may cause confiden- 773 tial subscribers to the list to be revealed. It is also permissible 774 for the mailing list exploder to direct MDNs to itself, correlate 775 them, and produce a report to the original sender of the message. 777 This specification places no restrictions on the processing of MDNs 778 received by user agents or mailing lists. 780 6. Security considerations 782 The following security considerations apply when using MDNs: 784 6.1 Forgery 786 MDNs may be forged as easily as ordinary Internet electronic mail. 787 User agents and automatic mail handling facilities (such as mail 788 distribution list exploders) that wish to make automatic use of MDNs 789 should take appropriate precautions to minimize the potential damage 790 from denial-of-service attacks. 792 Security threats related to forged MDNs include the sending of: 794 (a) A falsified disposition notification when the indicated dis- 795 position of the message has not actually ocurred, 797 (b) Unsolicited MDNs 799 6.2 Confidentiality 801 Another dimension of security is confidentiality. There may be 802 cases in which a message recipient does not wish the disposition of 803 messages addressed to him to be known or is concerned that the 804 sending of MDNs may reveal other confidential information (e.g., 805 when the message was read). In this situation, it is acceptable for 806 the UA to issue "denied" or "autodenied" MDNs or to silently ignore 807 requests for MDNs. 809 If the Disposition-notification-to header is passed on unmodified 810 when a message is distributed to the subscribers of a mailing list, 811 the subscribers to the list may be revealed to the sender of the 812 original message by the generation of MDNs. 814 Message Disposition Notifications 26 November 1996 815 Internet Draft 817 In general, any optional MDN field may be omitted if the Reporting 818 UA site or user determines that inclusion of the field would impose 819 too great a compromise of site confidentiality. The need for such 820 confidentiality must be balanced against the utility of the omitted 821 information in MDNs. 823 6.3 Non-Repudiation 825 Within the framework of today's internet mail, the MDNs defined in 826 this document provide valuable information to the mail user; 827 however, MDNs can not be relied upon as a guarantee that a message 828 was or was not not seen by the recipient. Even if MDNs are not 829 actively forged, they may be lost in transit. The MDN issuing 830 mechanism may be bypassed in some manner by the recipient. 832 Message Disposition Notifications 26 November 1996 833 Internet Draft 835 7. Appendix - collected grammar 837 NOTE: The following lexical tokens are defined in RFC 822: addr- 838 spec, address, atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- 839 white-space, SPACE, text. The date-time lexical token is defined in 840 RFC 1123 [7]. 842 Message headers: | 843 | 844 mdn-request-header = "Disposition-notification-to" ":" 1#mailbox | 845 | 846 Disposition-notification-options = | 847 "Disposition-notification-options" ":" | 848 disposition-notification-parameters | 849 | 850 Disposition-notification-parameters = parameter *(";" parameter) | 851 | 852 parameter = attribute "=" importance "," 1#value | 853 | 854 importance = "R" / "O" | 856 original-recipient-header = 857 "Original-Recipient" ":" address-type ";" generic-address 859 | 860 Report content: | 861 | 862 disposition-notification-content = [ reporting-ua-field CRLF ] 863 [ mdn-gateway-field CRLF ] 864 [ original-recipient-field CRLF ] 865 final-recipient-field CRLF 866 [ original-message-id-field CRLF ] | 867 disposition-field CRLF | 868 *( extension-field CRLF ) 870 address-type = atom 871 | 872 mta-name-type = atom 874 reporting-ua-field = "Reporting-UA" ":" ua-name 876 ua-name = *text 878 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 879 original-recipient-field = 880 "Original-Recipient" ":" address-type ";" generic-address 882 generic-address = *text 884 final-recipient-field = 885 Message Disposition Notifications 26 November 1996 886 Internet Draft 888 "Final-Recipient" ":" address-type ";" generic-address 890 disposition-field = "Disposition" ":" disposition-value 891 | 892 disposition-value = | 893 "acknowledged" / "autoacknowledged" / | 894 "processed" / "autoprocessed" / | 895 "deleted" / "autodeleted" / | 896 "obsoleted" / "expired" / "terminated" / | 897 "denied" / "autodenied" | 898 disposition-value-extension | 899 | 900 disposition-value-extension = atom | 902 original-message-id-field = "Original-Message-ID" ":" msg-id | 904 subscriber-address = *text 906 extension-field = extension-field-name ":" *text 908 extension-field-name = atom 909 Message Disposition Notifications 26 November 1996 910 Internet Draft 912 8. Appendix - Guidelines for gatewaying MDNs 914 NOTE: This section provides non-binding recommendations for the 915 construction of mail gateways that wish to provide semi-transparent 916 disposition notifications between the Internet and another 917 electronic mail system. Specific MDN gateway requirements for a 918 particular pair of mail systems may be defined by other documents. 920 8.1 Gatewaying from other mail systems to MDNs 922 A mail gateway may issue an MDN to convey the contents of a "for- 923 eign" disposition notification over Internet mail. When there are 924 appropriate mappings from the foreign notification elements to MDN 925 fields, the information may be transmitted in those MDN fields. 926 Additional information (such as might be needed to tunnel the 927 foreign notification through the Internet) may be defined in exten- 928 sion MDN fields. (Such fields should be given names that identify 929 the foreign mail protocol, e.g. X400-* for X.400 protocol elements) 931 The gateway must attempt to supply reasonable values for the 932 Reporting-UA, Final-Recipient, and Disposition fields. These will 933 normally be obtained by translating the values from the foreign 934 notification into their Internet-style equivalents. However, some 935 loss of information is to be expected. 937 The sender-specified recipient address, and the original message-id, 938 if present in the foreign notification, should be preserved in the 939 Original-Recipient and Original-Message-ID fields. 941 The gateway should also attempt to preserve the "final" recipient 942 address from the foreign system. Whenever possible, foreign 943 protocol elements should be encoded as meaningful printable ASCII 944 strings. 946 For MDNs produced from foreign disposition notifications, the name 947 of the gateway MUST appear in the MDN-Gateway field of the MDN. 949 Message Disposition Notifications 26 November 1996 950 Internet Draft 952 8.2 Gatewaying from MDNs to other mail systems 954 It may be possible to gateway MDNs from the Internet into a foreign 955 mail system. The primary purpose of such gatewaying is to convey 956 disposition information in a form that is usable by the destination 957 system. A secondary purpose is to allow "tunneling" of MDNs through 958 foreign mail systems, in case the MDN may be gatewayed back into the 959 Internet. 961 In general, the recipient of the MDN (i.e., the sender of the 962 original message) will want to know, for each recipient: the 963 closest available approximation to the original recipient address, 964 and the disposition (displayed, printed, etc.). 966 If possible, the gateway should attempt to preserve the Original- 967 Recipient address and Original-Message-ID (if present), in the 968 resulting foreign disposition report. 970 If it is possible to tunnel an MDN through the destination environ- 971 ment, the gateway specification may define a means of preserving the 972 MDN information in the disposition reports used by that environment. 974 Message Disposition Notifications 26 November 1996 975 Internet Draft 977 9. Appendix - Examples 979 NOTE: These examples are provided as illustration only, and are not 980 considered part of the MDN protocol specification. If an example 981 conflicts with the protocol definition above, the example is wrong. 983 Likewise, the use of *-type subfield names or extension fields in 984 these examples is not to be construed as a definition for those type 985 names or extension fields. 987 Message Disposition Notifications 26 November 1996 988 Internet Draft 990 9.1 This is an MDN issued after a message has been displayed to the 991 user of an Internet Mail user agent. 993 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 994 From: Joe Recipient 995 Message-Id: <199509200019.12345@mega.edu> 996 Subject: Disposition notification 997 To: Jane Sender 998 MIME-Version: 1.0 999 Content-Type: multipart/report; report-type=disposition-notification; 1000 boundary="RAA14128.773615765/mega.edu" 1002 --RAA14128.773615765/mega.edu 1004 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to 1005 Joe Recipient with subject "First 1006 draft of report" has been displayed. This is no guarantee 1007 that the message has been read or understood. 1009 --RAA14128.773615765/mega.edu 1010 content-type: message/disposition-notification 1012 Reporting-UA: joes-pc.cs.mega.edu (Foomail 97.1) 1013 Original-Recipient: rfc822;Joe_Recipient@mega.edu 1014 Final-Recipient: rfc822;Joe_Recipient@mega.edu 1015 Original-Message-ID: <199509192301.12345@mega.edu> 1016 Disposition: acknowledged | 1018 --RAA14128.773615765/mega.edu 1019 content-type: message/rfc822 1021 [original message goes here] 1023 --RAA14128.773615765/mega.edu-- 1024 Message Disposition Notifications 26 November 1996 1025 Internet Draft 1027 10. Acknowledgments 1029 This document is based on the Delivery Status Notifications document 1030 , RFC 1894 [8], by Keith Moore and Greg Vaudreuil. Contributions 1031 were made by members of the IETF Receipt Working Group, including 1032 Harald Alverstrand, Urs Eppenberger, Ned Freed, Jim Galvin, Keith 1033 Moore, Paul Overell, Pete Resnick. | 1034 | 1035 [Author's note -- If you would like to be included, let me know and | 1036 I will add your name.] | 1037 Message Disposition Notifications 26 November 1996 1038 Internet Draft 1040 11. References 1042 [1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Exten- 1043 sions", RFC 1521, Bellcore, Innosoft, September 1993. 1045 [2] Vaudreuil, G. "The Multipart/Report Content Type for the 1046 Reporting of Mail System Administrative Messages", RFC 1892, 1047 Octel Network Services, January 1996. 1049 [3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1050 USC/Information Sciences Institute, August 1982. 1052 [4] Moore, K. "SMTP Service Extension for Delivery Status 1053 Notifications", RFC 1891, University of Tennessee, January 1054 1996. 1056 [5] Crocker, D., "Standard for the Format of ARPA Internet Text 1057 Messages", STD 11, RFC 822, UDEL, August 1982. 1059 [6] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part 1060 Two: Message Header Extensions for Non-Ascii Text", RFC 1522, 1061 University of Tennessee, September 1993. 1063 [7] Braden, R. (ed.) "Requirements for Internet Hosts - Application 1064 and Support", RFC 1123, October 1989. 1066 [8] Moore, K. and Vaudreuil, G. "An Extensible Format for Delivery 1067 Status Notifications, RFC 1894, University of Tennessee, Octel 1068 Network Services, January 1996. 1070 Message Disposition Notifications 26 November 1996 1071 Internet Draft 1073 12. Author's Address 1075 Roger Fajman 1076 National Institutes of Health 1077 12 South Drive MSC 5659 1078 Bethesda, Maryland 20892-5659 1079 USA 1081 Email: raf@cu.nih.gov 1082 Voice: +1 301 402 4265 1083 Fax: +1 301 480 6241