idnits 2.17.1 draft-ietf-receipt-mdn-00.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-26) 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 1 instance 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 164: '...position-notification-to header SHOULD...' RFC 2119 keyword, line 224: '...The MDN MUST be addressed (in both the...' RFC 2119 keyword, line 229: '...age header of the MDN MUST contain the...' RFC 2119 keyword, line 234: '... message disposition notification MUST...' RFC 2119 keyword, line 235: '...n MDN. That is, it MUST NOT contain a...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (5 October 1995) is 10431 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 864, 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) == Outdated reference: A later version (-05) exists of draft-ietf-notary-mime-report-03 ** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821) == Outdated reference: A later version (-05) exists of draft-ietf-notary-smtp-drpt-04 ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 3 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: 10 April 1996 5 October 1995 5 An Extensible Message Format 6 for Message Disposition Notifications 8 draft-ietf-receipt-mdn-00.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 5 October 1995 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 [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 5 October 1995 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. 126 2. Requesting MDNs 128 A request that the receiving user agent issue message disposition 129 notifications is made by placing a Disposition-notification-to 130 header into the message. The syntax of the header using the ABNF of 131 RFC 822 [5] is 133 mdn-request-header = "Disposition-notification-to" ":" address 135 The address token is as specified in RFC 822 [5]. 137 Note that the presence of a Disposition-notification-to header in a 138 message is merely a request for an MDN. The recipients' user agents 139 are always free to silently ignore such a request. Alternatively, 140 an explicit denial of the request for information about the disposi- 141 tion of the message may be sent using the "denied" disposition in an 142 MDN. 144 One and only one MDN may be issued on behalf of each particular 145 recipient by their user agent. That is, once an MDN has been issued 146 on behalf of a recipient, no further MDNs may be issued on behalf of 147 that recipient, even if another disposition is performed on the 148 message. If a message is forwarded, a "forwarded" MDN may been 149 issued for the recipient doing the forwarding and the recipient of 150 the forwarded message may also cause an MDN to be generated. 152 Message Disposition Notifications 5 October 1995 153 Internet Draft 155 While Internet standards normally do not specify the behavior of 156 user interfaces, it is strongly recommended that the user agent 157 obtain the user's consent before sending an MDN. This consent could 158 be obtained for each message through some sort of prompt or dialog 159 box, or globally through the user's setting of a preference. The 160 user might also indicate globally that MDNs are never to be sent or 161 that a "denied" MDN is always sent in response to a request for an 162 MDN. 164 A message that contains a Disposition-notification-to header SHOULD 165 also contain a Message-ID header as specified in RFC 822 [5]. This 166 will permit automatic correlation of MDNs with original messages by 167 user agents. 169 If it desired to request message disposition notifications for some 170 recipients and not others, two copies of the message should be sent, 171 one with an Disposition-notification-to header and one without. The 172 other headers of the message (To, cc, bcc, etc.) are the same in 173 both copies. The recipients in the respective message envelopes 174 determine for whom message disposition notifications are requested 175 and for whom they are not. If desired, the Message-ID header may be 176 the same in both copies of the message. 178 Since electronic mail addresses may be rewritten while the message 179 is in transit, it is useful for the original recipient address to be 180 made available by the delivering MTA. The MTA may be able to obtain 181 this information from the ORCPT parameter of the SMTP MAIL FROM 182 command, as defined in [4]. If this information is available, the 183 delivering MTA may insert an Original-recipient header into the 184 message. The syntax of this header using the ABNF of RFC 822 [5] is 185 as follows 187 original-recipient-header = 188 "Original-Recipient" ":" address-type ";" generic-address 190 The address-type and generic-address token are as as specified in 191 the description of the Original-recipient field in section 3.2.3. 193 3. Format of a Message Disposition Notification 195 A message disposition notification is a MIME message with a top- 196 level content-type of multipart/report (defined in [2]). When a 197 multipart/report content is used to transmit an MDN: 199 (a) The report-type parameter of the multipart/report content is 200 "disposition-notification". 202 (b) The first component of the multipart/report contains a human- 203 readable explanation of the MDN, as described in [2]. 205 Message Disposition Notifications 5 October 1995 206 Internet Draft 208 (c) The second component of the multipart/report is of content-type 209 message/disposition-notification, described in section 3.1 of 210 this document. 212 (d) If the original message or a portion of the message is to be 213 returned to the sender, it appears as the third component of 214 the multipart/report. 216 NOTE: For message dispostion notifications gatewayed from 217 foreign systems, the headers of the original message may not be 218 available. In this case the third component of the MDN may be 219 omitted, or it may contain "simulated" RFC 822 headers which 220 contain equivalent information. In particular, it is very 221 desirable to preserve the subject and date fields from the 222 original message. 224 The MDN MUST be addressed (in both the message header and the 225 transport envelope) to the address from the Disposition- 226 notification-to header which from the original message for which the 227 MDN was generated. 229 The From field of the message header of the MDN MUST contain the 230 address of the person on whose behalf the message disposition 231 notification is being issued. 233 The envelope sender address of the MDN should be the same as the 234 address in the From header. A message disposition notification MUST 235 NOT itself request an MDN. That is, it MUST NOT contain a 236 Disposition-notification-to header. 238 The Message-ID header (if present) for an MDN MUST be different from 239 the Message-ID of the message for which the MDN is being issued. 241 A particular MDN describes the disposition of exactly one message 242 for exactly one recipient. Multiple MDNs may be generated as a 243 result of one message submission, one per recipient. However, due 244 to various circumstances, MDNs may not be generated for some 245 recipients for which MDNs were requested. 247 3.1 The message/disposition-notification content-type 249 The message/disposition-notification content-type is defined as 250 follows: 252 Message Disposition Notifications 5 October 1995 253 Internet Draft 255 MIME type name: message 256 MIME subtype name: disposition-notification 257 Optional parameters: none 258 Encoding considerations: "7bit" encoding is sufficient and 259 MUST be used to maintain readability 260 when viewed by non-MIME mail 261 readers. 262 Security considerations: discussed in section 5 of this memo. 264 The message/disposition-notification report type for use in the 265 multipart/report is "disposition-notification". 267 The body of a message/delivery-status consists of one or more 268 "fields" formatted according to the ABNF of RFC 822 header "fields" 269 (see [5]). Using the ABNF of RFC 822, the syntax of the 270 message/disposition-notification content is as follows: 272 disposition-notification-content = reporting-ua-field CRLF 273 [ mdn-gateway-field CRLF ] 274 [ original-recipient-field CRLF ] 275 final-recipient-field CRLF 276 [ original-message-id-field CRLF ] 277 disposition-field CRLF 278 *( extension-field CRLF) 280 3.1.1 General conventions for fields 282 Since these fields are defined according to the rules of RFC 822, 283 the same conventions for continuation lines and comments apply. 284 Notification fields may be continued onto multiple lines by begin- 285 ning each additional line with a SPACE or HTAB. Text which appears 286 in parentheses is considered a comment and not part of the contents 287 of that notification field. Field names are case-insensitive, so 288 the names of notification fields may be spelled in any combination 289 of upper and lower case letters. Comments in notification fields 290 may use the "encoded-word" construct defined in [6]. 292 3.1.2 "*-type" subfields 294 Several fields consist of a "-type" subfield, followed by a semi- 295 colon, followed by "*text". For these fields, the keyword used in 296 the address-type, UA-type, or MTA-type subfield indicates the 297 expected format of the address, UA-name, or MTA-name that follows. 299 The "-type" subfields are defined as follows: 301 Message Disposition Notifications 5 October 1995 302 Internet Draft 304 (a) An "address-type" specifies the format of a mailbox address. 305 For example, Internet mail addresses use the "rfc822" address- 306 type. 308 address-type = atom 310 (b) An "UA-name-type" specifies the format of a user agent name. 311 For example, for a Eudora user agent on an Internet host, the 312 UA name might be the domain name of that host, and a UA-name- 313 type of "Eudora" might be used. 315 ua-name-type = atom 317 (c) An "MTA-name-type" specifies the format of a mail transfer 318 agent name. For example, for an SMTP server on an Internet 319 host, the MTA name is the domain name of that host, and the 320 "dns" MTA-name-type is used. 322 mta-name-type = atom 324 Values for address-type, ua-name-type, and mta-name-type are case- 325 insensitive. Thus address-type values of "RFC822" and "rfc822" are 326 equivalent. 328 The Internet Assigned Numbers Authority (IANA) will maintain a 329 registry of address-type, ua-name-type, and mta-name-type values, 330 along with descriptions of the meanings of each, or a reference to a 331 one or more specifications that provide such descriptions. (The 332 "rfc822" address-type is defined in [4].) Registration forms for 333 address-type and mta-name-type appear in [8]. A registration form 334 for ua-name-type appears in this document. 336 IANA will not accept registrations for any address-type name that 337 begins with "X-". These type names are reserved for experimental 338 use. 340 3.1.3 Lexical tokens imported from RFC 822 342 The following lexical tokens, defined in RFC 822 [5], are used in 343 the ABNF grammar for MDNs: addr-spec, atom, CHAR, comment, CR, 344 CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time 345 lexical token is defined in RFC 1123 [7]. 347 Message Disposition Notifications 5 October 1995 348 Internet Draft 350 3.2 Message/disposition-notification Fields 352 3.2.1 The Reporting-UA field 354 reporting-ua-field = "Reporting-UA" ":" ua-name-type ";" ua-name 356 ua-name = *text 358 The Reporting-UA field is defined as follows: 360 A MDN describes the disposition of a message after it has been 361 delivered a recipient. In all cases, the Reporting-UA is the UA 362 that performed the disposition described in the MDN. This field is 363 required. 365 3.2.2 The MDN-Gateway field 367 The MDN-Gateway field indicates the name of the gateway or MTA that 368 translated a foreign (non-Internet) message disposition notification 369 into this MDN. This field MUST appear in any MDN which was trans- 370 lated by a gateway from a foreign system into MDN format, and MUST 371 NOT appear otherwise. 373 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 375 For gateways into Internet mail, the MTA-name-type will normally be 376 "smtp", and the mta-name will be the Internet domain name of the 377 gateway. 379 3.2.3 Original-Recipient field 381 The Original-Recipient field indicates the original recipient 382 address as specified by the sender of the message for which the MDN 383 is being issued. For Internet Mail messages the value of the 384 Original-Recipient field is obtained from the Original-Recipient 385 header from the message for which the MDN is being generated. If 386 there is no Original-Recipient header in the message, then the 387 Original-Recipient field MUST be omitted. 389 original-recipient-field = 390 "Original-Recipient" ":" address-type ";" generic-address 392 generic-address = *text 394 The address-type field indicates the type of the original recipient 395 address. If the message originated within the Internet, the 396 address-type field field will normally be "rfc822", and the address 397 will be according to the syntax specified in [5]. The value "un- 398 Message Disposition Notifications 5 October 1995 399 Internet Draft 401 known" should be used if the Reporting UA cannot determine the type 402 of the original recipient address from the message envelope. This 403 address is the same as that provided by the sender and can be used 404 to automatically correlate MDN reports and message transactions. 406 3.3.4 Final-Recipient field 408 The Final-Recipient field indicates the recipient for which the MDN 409 is being issued. This field MUST be present. 411 The syntax of the field is as follows: 413 final-recipient-field = 414 "Final-Recipient" ":" address-type ";" generic-address 416 The generic-address subfield of the Final-Recipient field MUST 417 contain the mailbox address of the recipient (from the From header) 418 as it was when the message was accepted for delivery by the UA. 420 The Final-Recipient address may differ from the address originally 421 provided by the sender, because it may have been transformed during 422 forwarding and gatewaying into an totally unrecognizable mess. 423 However, in the absence of the optional Original-Recipient field, 424 the Final-Recipient field and any returned content may be the only 425 information available with which to correlate the MDN with a par- 426 ticular message recipient. 428 The address-type subfield indicates the type of address expected by 429 the reporting MTA in that context. Recipient addresses obtained via 430 SMTP will normally be of address-type "rfc822". 432 Since mailbox addresses (including those used in the Internet) may 433 be case sensitive, the case of alphabetic characters in the address 434 MUST be preserved. 436 3.3.5 Original-Message-ID field 438 The Original-Message-ID field indicates the message-ID of the 439 message for which the MDN is being issued. It is obtained from the 440 Message-ID header of the message for which the MDN is issued. This 441 field SHOULD be present if the original message contained a Message- 442 ID header. The syntax of the field is 444 original-message-id-field = "Original-Message-ID" ":" 445 "<" addr-spec ">" 447 The addr-spec token is as specified in RFC 822 [5]. 449 Message Disposition Notifications 5 October 1995 450 Internet Draft 452 3.3.6 Disposition field 454 The Disposition field indicates the action performed by the 455 Reporting-UA on behalf of the user. This field MUST be present. 457 The syntax for the action-field is: 459 disposition-field = "Disposition" ":" disposition-value 461 disposition-value = 462 "displayed" / "printed" / "forwarded" / "deleted" / 463 "obsoleted" / "expired" / "terminated" / "denied" 465 The disposition-value may be spelled in any combination of upper and 466 lower case characters. 468 "displayed" The message has been displayed by the UA to someone 469 reading the recipient's mailbox. There is no guarantee 470 that the content has been read or understood. 472 "printed" The message has been converted to hardcopy form by the 473 UA on behalf of someone reading the recipient's mail- 474 box. This could include sending the message to a fax 475 machine. 477 "forwarded" The message has been forwarded to another mailbox. 479 "deleted" The message has been deleted without being displayed to 480 the recipient. 482 "obsoleted" The message has been rendered obsolete by another 483 message. 485 "expired" The message has reached its expiration date and has 486 been removed from the recipient's mailbox. 488 "terminated" The recipient's mailbox has been terminated. 490 "denied" The recipient does not wish the sender to be informed 491 of the message's disposition. A UA may also siliently 492 ignore message disposition requests in this situation. 494 3.4 Extension fields 496 Additional MDN fields may be defined in the future by later revi- 497 sions or extensions to this specification. Extension-field names 498 beginning with "X-" will never be defined as standard fields; such 499 names are reserved for experimental use. MDN field names NOT 500 Message Disposition Notifications 5 October 1995 501 Internet Draft 503 beginning with "X-" MUST be registered with the Internet Assigned 504 Numbers Authority (IANA) and described in an RFC. 506 Extension MDN fields may be defined for the following reasons: 508 (a) To allow additional information from foreign disposition 509 reports to be tunneled through Internet MDNs. The names of 510 such MDN fields should begin with an indication of the foreign 511 environment name (e.g. X400-Physical-Forwarding-Address). 513 (b) To allow transmission of diagnostic information which is 514 specific to a particular user agent (UA). The names of such 515 MDN fields should begin with an indication of the UA implemen- 516 tation which produced the MDN. (e.g. Foomail-information). 518 If an UA developer does not wish to register the meanings of such 519 extension fields, "X-" fields may be used for this purpose. To 520 avoid name collisions, the name of the UA implementation should 521 follow the "X-", (e.g. "X-Foomail-Log-ID"). 523 4. Conformance and Usage Requirements 525 A UA or gateway conforms to this specification if it generates MDNs 526 according to the protocol defined in this memo. It is not necessary 527 to be able to generate all of the values of the Disposition field. 529 UAs and gateways MUST NOT generate the Original-Recipient field of 530 an MDN unless the mail protocols provide the address originally 531 specified by the sender at the time of submission. Ordinary SMTP 532 does not make that guarantee, but the SMTP extension defined in [4] 533 permits such information to be carried in the envelope if it is 534 available. The Original-recipient header defined in this document 535 provides a way for the MTA to pass the original recipient address to 536 the UA. 538 Each sender-specified recipient address may result in more than one 539 MDN. If an MDN is requested for a recipient that is forwarded to 540 multiple recipients of an "alias" (as defined in [4], section 541 7.2.7), each of the recipients may issue an MDN. 543 By contrast, successful distribution of a message to a mailing list 544 exploder may be considered final disposition of the message. A 545 mailing list exploder may issue an MDN indicating that the message 546 has been forwarded to the list. In this case, the request for MDNs 547 is not propogated to the members of the list. Alternatively, the 548 mailing list exploder may issue no MDN and propogate the request for 549 MDNs to all members of the list. The later behavior is not recom- 550 mended for any but small, closely knit lists. 552 Message Disposition Notifications 5 October 1995 553 Internet Draft 555 This specification places no restrictions on the processing of MDNs 556 received by user agents or mailing lists. 558 5. Security considerations 560 The following security considerations apply when using MDNs: 562 5.1 Forgery 564 MDNs may be forged as easily as ordinary Internet electronic mail. 565 User agents and automatic mail handling facilities (such as mail 566 distribution list exploders) that wish to make automatic use of MDNs 567 should take appropriate precautions to minimize the potential damage 568 from denial-of-service attacks. 570 Security threats related to forged MDNs include the sending of: 572 (a) A falsified disposition notification when the indicated dis- 573 position of the message has not actually ocurred, 575 (b) Unsolicited MDNs 577 5.2 Confidentiality 579 Another dimension of security is confidentiality. There may be 580 cases in which a message recipient does not wish the disposition of 581 messages addressed to him to be known. In this situation, it is 582 acceptable for the UA to issue "denied" MDNs or to silently ignore 583 requests for MDNs. 585 In general, any optional MDN field may be omitted if the Reporting 586 UA site or user determines that inclusion of the field would impose 587 too great a compromise of site confidentiality. The need for such 588 confidentiality must be balanced against the utility of the omitted 589 information in MDNs. 591 5.3 Non-Repudiation 593 Within the framework of today's internet mail, the MDNs defined in 594 this document provide valuable information to the mail user; 595 however, MDNs can not be relied upon as a guarantee that a message 596 was or was not not seen by the recipient. Even if MDNs are not 597 actively forged, they may be lost in transit. The MDN issuing 598 mechanism may be bypassed in some manner by the recipient. 600 Message Disposition Notifications 5 October 1995 601 Internet Draft 603 6. Appendix - collected grammar 605 NOTE: The following lexical tokens are defined in RFC 822: addr- 606 spec, address, atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- 607 white-space, SPACE, text. The date-time lexical token is defined in 608 RFC 1123 [7]. 610 mdn-request-header = "Disposition-notification-to" ":" address 612 original-recipient-header = 613 "Original-Recipient" ":" address-type ";" generic-address 615 disposition-notification-content = reporting-ua-field CRLF 616 [ mdn-gateway-field CRLF ] 617 [ original-recipient-field CRLF ] 618 final-recipient-field CRLF 619 [message-id-field CRLF] 620 disposition-field CRLF 621 *( extension-field CRLF) 623 address-type = atom 625 ua-name-type = atom 627 mta-name-type = atom 629 reporting-ua-field = "Reporting-UA" ":" ua-name-type ";" ua-name 631 ua-name = *text 633 mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name 634 original-recipient-field = 635 "Original-Recipient" ":" address-type ";" generic-address 637 generic-address = *text 639 final-recipient-field = 640 "Final-Recipient" ":" address-type ";" generic-address 642 disposition-field = "Disposition" ":" disposition-value 644 disposition-value = 645 "displayed" / "printed" / "forwarded" / "deleted" / 646 "obsoleted" / "expired" / "terminated" / "denied" 648 original-message-id-field = "Original-Message-ID" ":" "<" addr-spec ">" 650 extension-field = extension-field-name ":" *text 652 extension-field-name = atom 653 Message Disposition Notifications 5 October 1995 654 Internet Draft 656 7. Appendix - Guidelines for gatewaying MDNs 658 NOTE: This section provides non-binding recommendations for the 659 construction of mail gateways that wish to provide semi-transparent 660 disposition notifications between the Internet and another 661 electronic mail system. Specific MDN gateway requirements for a 662 particular pair of mail systems may be defined by other documents. 664 6.1 Gatewaying from other mail systems to MDNs 666 A mail gateway may issue an MDN to convey the contents of a "for- 667 eign" disposition notification over Internet mail. When there are 668 appropriate mappings from the foreign notification elements to MDN 669 fields, the information may be transmitted in those MDN fields. 670 Additional information (such as might be needed to tunnel the 671 foreign notification through the Internet) may be defined in exten- 672 sion MDN fields. (Such fields should be given names that identify 673 the foreign mail protocol, e.g. X400-* for X.400 protocol elements) 675 The gateway must attempt to supply reasonable values for the 676 Reporting-UA, Final-Recipient, and Disposition fields. These will 677 normally be obtained by translating the values from the foreign 678 notification into their Internet-style equivalents. However, some 679 loss of information is to be expected. 681 The sender-specified recipient address, and the original message-id, 682 if present in the foreign notification, should be preserved in the 683 Original-Recipient and Original-Message-ID fields. 685 The gateway should also attempt to preserve the "final" recipient 686 address from the foreign system. Whenever possible, foreign 687 protocol elements should be encoded as meaningful printable ASCII 688 strings. 690 For MDNs produced from foreign disposition notifications, the name 691 of the gateway MUST appear in the MDN-Gateway field of the MDN. 693 Message Disposition Notifications 5 October 1995 694 Internet Draft 696 7.2 Gatewaying from MDNs to other mail systems 698 It may be possible to gateway MDNs from the Internet into a foreign 699 mail system. The primary purpose of such gatewaying is to convey 700 disposition information in a form that is usable by the destination 701 system. A secondary purpose is to allow "tunneling" of MDNs through 702 foreign mail systems, in case the MDN may be gatewayed back into the 703 Internet. 705 In general, the recipient of the MDN (i.e., the sender of the 706 original message) will want to know, for each recipient: the 707 closest available approximation to the original recipient address, 708 and the disposition (displayed, printed, etc.). 710 If possible, the gateway should attempt to preserve the Original- 711 Recipient address and Original-Message-ID (if present), in the 712 resulting foreign disposition report. 714 If it is possible to tunnel an MDN through the destination environ- 715 ment, the gateway specification may define a means of preserving the 716 MDN information in the disposition reports used by that environment. 718 Message Disposition Notifications 5 October 1995 719 Internet Draft 721 9. Appendix - IANA registration forms for MDN types 723 The forms below are for use when registering a new address-type, 724 UA-name-type, or MTA-name-type with the Internet Assigned Numbers 725 Authority (IANA). Each piece of information requested by a 726 registration form may be satisfied either by providing the informa- 727 tion on the form itself, or by including a reference to a published, 728 publicly available specification which includes the necessary 729 information. IANA MAY reject MDN type registrations because of 730 incomplete registration forms, imprecise specifications, or inap- 731 propriate type names. 733 To register an MDN type, complete the applicable form below and send 734 it via Internet electronic mail to . 736 Message Disposition Notifications 5 October 1995 737 Internet Draft 739 9.1 IANA registration form for address-type 741 A registration for an address-type MUST include the following 742 information: 744 (a) The proposed address-type name. 746 (b) The syntax for mailbox addresses of this type, specified using 747 BNF, regular expressions, ASN.1, or other non-ambiguous lan- 748 guage. 750 (c) If addresses of this type are not composed entirely of graphic 751 characters from the US-ASCII repertoire, a specification for 752 how they are to be encoded as graphic US-ASCII characters in a 753 MDN Original-Recipient or Final-Recipient MDN field. 755 (d) [optional] A specification for how addresses of this type are 756 to be translated to and from Internet electronic mail ad- 757 dresses. 759 9.2 IANA registration form for UA-name-type 761 A registration for a UA-name-type must include the following infor- 762 mation: 764 (a) The proposed UA-name-type name. 766 (b) A description of the syntax of UA names of this type, using 767 BNF, regular expressions, ASN.1, or other non-ambiguous lan- 768 guage. 770 (c) If UA names of this type do not consist entirely of graphic 771 characters from the US-ASCII repertoire, a specification for 772 how an MTA name of this type should be expressed as a sequence 773 of graphic US-ASCII characters. 775 9.3 IANA registration form for MTA-name-type 777 A registration for a MDN MTA-name-type must include the following 778 information: 780 (a) The proposed MTA-name-type name. 782 (b) A description of the syntax of MTA names of this type, using 783 BNF, regular expressions, ASN.1, or other non-ambiguous lan- 784 guage. 786 Message Disposition Notifications 5 October 1995 787 Internet Draft 789 (c) If MTA names of this type do not consist entirely of graphic 790 characters from the US-ASCII repertoire, a specification for 791 how an MTA name of this type should be expressed as a sequence 792 of graphic US-ASCII characters. 794 Message Disposition Notifications 5 October 1995 795 Internet Draft 797 10. Appendix - Examples 799 NOTE: These examples are provided as illustration only, and are not 800 considered part of the MDN protocol specification. If an example 801 conflicts with the protocol definition above, the example is wrong. 803 Likewise, the use of *-type subfield names or extension fields in 804 these examples is not to be construed as a definition for those type 805 names or extension fields. 807 Message Disposition Notifications 5 October 1995 808 Internet Draft 810 10.1 This is an MDN issued after a message has been displayed to the 811 user of an Internet Mail user agent. 813 Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 814 From: Joe Recipient 815 Message-Id: <199509200019.12345@mega.edu> 816 Subject: Disposition notification 817 To: Jane Sender 818 MIME-Version: 1.0 819 Content-Type: multipart/report; report-type=disposition-notification; 820 boundary="RAA14128.773615765/mega.edu" 822 --RAA14128.773615765/mega.edu 824 The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to 825 Joe Recipient with subject "First 826 draft of report" has been displayed. This is no guarantee 827 that the message has been read or understood. 829 --RAA14128.773615765/mega.edu 830 content-type: message/disposition-notification 832 Reporting-UA: foomail; joes-pc.cs.mega.edu 833 Original-Recipient: rfc822;Joe_Recipient@mega.edu 834 Final-Recipient: rfc822;Joe_Recipient@mega.edu 835 Original-Message-ID: <199509192301.12345@mega.edu> 836 Disposition: displayed 838 --RAA14128.773615765/mega.edu 839 content-type: message/rfc822 841 [original message goes here] 843 --RAA14128.773615765/mega.edu-- 844 Message Disposition Notifications 5 October 1995 845 Internet Draft 847 11. Acknowledgments 849 This document is based on the Delivery Status Notifications document 850 [8] by Keith Moore and Greg Vaudreuil. 852 Message Disposition Notifications 5 October 1995 853 Internet Draft 855 12. References 857 [1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Exten- 858 sions", RFC 1521, Bellcore, Innosoft, September 1993. 860 [2] Vaudreuil, G. "The Multipart/Report Content Type for the 861 Reporting of Mail System Administrative Messages", Internet- 862 Draft draft-ietf-notary-mime-report-03.txt, 5 May 1995. 864 [3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 865 USC/Information Sciences Institute, August 1982. 867 [4] Moore, K. "SMTP Service Extension for Delivery Status 868 Notifications", Internet-Draft 869 draft-ietf-notary-smtp-drpt-04.txt, 29 May 1995. 871 [5] Crocker, D., "Standard for the Format of ARPA Internet Text 872 Messages", STD 11, RFC 822, UDEL, August 1982. 874 [6] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part 875 Two: Message Header Extensions for Non-Ascii Text", RFC 1522, 876 University of Tennessee, September 1993. 878 [7] Braden, R. (ed.) "Requirements for Internet Hosts - Application 879 and Support", RFC 1123, October 1989. 881 [8] Moore, K. and Vaudreuil, G. "An Extensible Format for Delivery 882 Status Notifications, Internet Draft, 21 June 1995. 884 Message Disposition Notifications 5 October 1995 885 Internet Draft 887 12. Author's Address 889 Roger Fajman 890 National Institutes of Health 891 12 South Drive MSC 5659 892 Bethesda, Maryland 20892-5659 893 USA 895 Email: raf@cu.nih.gov 896 Voice: +1 301 402 4265 897 Fax: +1 301 480 6241