diff options
Diffstat (limited to 'doc/rfc/rfc2298.txt')
| -rw-r--r-- | doc/rfc/rfc2298.txt | 1571 |
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc2298.txt b/doc/rfc/rfc2298.txt new file mode 100644 index 0000000..6283651 --- /dev/null +++ b/doc/rfc/rfc2298.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group R. Fajman +Request for Comments: 2298 National Institutes of Health +Category: Standards Track March 1998 + + + An Extensible Message Format + for Message Disposition Notifications + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This memo defines a MIME content-type that may be used by a mail user + agent (UA) or electronic mail gateway to report the disposition of a + message after it has been sucessfully delivered to a recipient. This + content-type is intended to be machine-processable. Additional + message headers are also defined to permit Message Disposition + Notifications (MDNs) to be requested by the sender of a message. The + purpose is to extend Internet Mail to support functionality often + found in other messaging systems, such as X.400 and the proprietary + "LAN-based" systems, and often referred to as "read receipts," + "acknowledgements," or "receipt notifications." The intention is to + do this while respecting the privacy concerns that have often been + expressed when such functions have been discussed in the past. + + Because many messages are sent between the Internet and other + messaging systems (such as X.400 or the proprietary "LAN-based" + systems), the MDN protocol is designed to be useful in a multi- + protocol messaging environment. To this end, the protocol described + in this memo provides for the carriage of "foreign" addresses, in + addition to those normally used in Internet Mail. Additional + attributes may also be defined to support "tunneling" of foreign + notifications through Internet Mail. + + + + + + + + +Fajman Standards Track [Page 1] + +RFC 2298 Message Disposition Notifications March 1998 + + +Table of Contents + + 1. Introduction ............................................ 2 + 2. Requesting Message Disposition Notifications ............ 3 + 3. Format of a Message Disposition Notification ............ 7 + 4. Timeline of events ...................................... 17 + 5. Conformance and Usage Requirements ...................... 18 + 6. Security Considerations ................................. 19 + 7. Collected Grammar ....................................... 20 + 8. Guidelines for Gatewaying MDNs .......................... 22 + 9. Example ................................................. 24 + 10. IANA Registration Forms ................................. 25 + 11. Acknowledgments ......................................... 26 + 12. References .............................................. 26 + 13. Author's Address ........................................ 27 + 14. Copyright ............................................... 28 + +1. Introduction + + This memo defines a MIME content-type [5] for message disposition + notifications (MDNs). An MDN can be used to notify the sender of a + message of any of several conditions that may occur after successful + delivery, such as display of the message contents, printing of the + message, deletion (without display) of the message, or the + recipient's refusal to provide MDNs. The "message/disposition- + notification" content-type defined herein is intended for use within + the framework of the "multipart/report" content type defined in RFC + 1892 [7]. + + This memo defines the format of the notifications and the RFC 822 + headers used to request them. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +1.1 Purposes + + The MDNs defined in this memo are expected to serve several purposes: + + (a) Inform human beings of the disposition of messages after + succcessful delivery, in a manner which is largely independent + of human language; + + (b) Allow mail user agents to keep track of the disposition of + messages sent, by associating returned MDNs with earlier message + transmissions; + + + + +Fajman Standards Track [Page 2] + +RFC 2298 Message Disposition Notifications March 1998 + + + (c) Convey disposition notification requests and disposition + notifications between Internet Mail and "foreign" mail systems + via a gateway; + + (d) Allow "foreign" notifications to be tunneled through a MIME- + capable message system and back into the original messaging + system that issued the original notification, or even to a third + messaging system; + + (e) Allow language-independent, yet reasonably precise, indications + of the disposition of a message to be delivered. + +1.2 Requirements + + These purposes place the following constraints on the notification + protocol: + + (a) It must be readable by humans, as well as being machine- + parsable. + + (b) It must provide enough information to allow message senders (or + their user agents) to unambiguously associate an MDN with the + message that was sent and the original recipient address for + which the MDN is issued (if such information is available), even + if the message was forwarded to another recipient address. + + (c) It must also be able to describe the disposition of a message + independent of any particular human language or of the + terminology of any particular mail system. + + (d) The specification must be extensible in order to accomodate + future requirements. + +2. Requesting Message Disposition Notifications + + Message disposition notifications are requested by including a + Disposition-Notification-To header in the message. Further + information to be used by the recipient's UA in generating the MDN + may be provided by including Original-Recipient and/or Disposition- + Notification-Options headers in the message. + +2.1 The Disposition-Notification-To Header + + A request that the receiving user agent issue message disposition + notifications is made by placing a Disposition-Notification-To header + into the message. The syntax of the header, using the ABNF of RFC + 822 [2], is + + + + +Fajman Standards Track [Page 3] + +RFC 2298 Message Disposition Notifications March 1998 + + + mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox + + The mailbox token is as specified in RFC 822 [2]. + + The presence of a Disposition-Notification-To header in a message is + merely a request for an MDN. The recipients' user agents are always + free to silently ignore such a request. Alternatively, an explicit + denial of the request for information about the disposition of the + message may be sent using the "denied" disposition in an MDN. + + An MDN MUST NOT itself have a Disposition-Notification-To header. + An MDN MUST NOT be generated in response to an MDN. + + At most one MDN may be issued on behalf of each particular recipient + by their user agent. That is, once an MDN has been issued on behalf + of a recipient, no further MDNs may be issued on behalf of that + recipient, even if another disposition is performed on the message. + However, if a message is forwarded, an MDN may been issued for the + recipient doing the forwarding and the recipient of the forwarded + message may also cause an MDN to be generated. + + While Internet standards normally do not specify the behavior of user + interfaces, it is strongly recommended that the user agent obtain the + user's consent before sending an MDN. This consent could be obtained + for each message through some sort of prompt or dialog box, or + globally through the user's setting of a preference. The user might + also indicate globally that MDNs are never to be sent or that a + "denied" MDN is always sent in response to a request for an MDN. + + MDNs SHOULD NOT be sent automatically if the address in the + Disposition-Notification-To header differs from the address in the + Return-Path header (see RFC 822 [2]). In this case, confirmation + from the user SHOULD be obtained, if possible. If obtaining consent + is not possible (e.g., because the user is not online at the time), + then an MDN SHOULD NOT be sent. + + Confirmation from the user SHOULD be obtained (or no MDN sent) if + there is no Return-Path header in the message, or if there is more + than one distinct address in the Disposition-Notification-To header. + + The comparison of the addresses should be done using only the addr- + spec (local-part "@" domain) portion, excluding any phrase and route. + The comparison MUST be case-sensitive for the local-part and case- + insensitive for the domain part. + + If the message contains more than one Return-Path header, the + implementation may pick one to use for the comparison, or treat the + situation as a failure of the comparison. + + + +Fajman Standards Track [Page 4] + +RFC 2298 Message Disposition Notifications March 1998 + + + The reason for not automatically sending an MDN if the comparison + fails or more than one address is specified is to reduce the + possibilities for mail loops and use of MDNs for mail bombing. + + A message that contains a Disposition-Notification-To header SHOULD + also contain a Message-ID header as specified in RFC 822 [2]. This + will permit automatic correlation of MDNs with original messages by + user agents. + + If it is desired to request message disposition notifications for + some recipients and not others, two copies of the message should be + sent, one with an Disposition-Notification-To header and one without. + Many of the other headers of the message (e.g., To, cc) will be the + same in both copies. The recipients in the respective message + envelopes determine for whom message disposition notifications are + requested and for whom they are not. If desired, the Message-ID + header may be the same in both copies of the message. Note that + there are other situations (e.g., bcc) in which it is necessary to + send multiple copies of a message with slightly different headers. + The combination of such situations and the need to request MDNs for a + subset of all recipients may result in more than two copies of a + message being sent, some with a Disposition- Notification-To header + and some without. + + Messages posted to newsgroups SHOULD NOT have a Disposition- + Notification-To header. + +2.2 The Disposition-Notification-Options Header + + Future extensions to this specification may require that information + 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 information. The syntax of + this header, using the ABNF of RFC 822 [2], is + + Disposition-Notification-Options = + "Disposition-Notification-Options" ":" + disposition-notification-parameters + + disposition-notification-parameters = parameter *(";" parameter) + + parameter = attribute "=" importance "," 1#value + + importance = "required" / "optional" + + The definitions of attribute and value are as in the definition of + the Content-Type header in RFC 2045 [4]. + + + + +Fajman Standards Track [Page 5] + +RFC 2298 Message Disposition Notifications March 1998 + + + An importance of "required" indicates that interpretation of the + parameter is necessary for proper generation of an MDN in response to + this request. If a UA does not understand the meaning of the + parameter, it MUST NOT generate an MDN with any disposition type + other than "failed" in response to the request. An importance of + "optional" 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 a standards-track RFC or an experimental RFC approved by + the IESG. See Section 10 for a registration form. + + If a required parameter is not understood or contains some sort of + error, the receiving UA SHOULD issue an MDN with a disposition type + of "failed" (see Section 3.2.6) and include a Failure field (see + Section 3.2.7) that further describes the problem. MDNs with the a + disposition type of "failed" and a "Failure" field MAY also be + generated when other types of errors are detected in the parameters + of the Disposition-Notification-Options header. + + However, an MDN with a disposition type of "failed" MUST NOT be + generated if the user has indicated a preferance that MDNs are not to + be sent. If user consent would be required for an MDN of some other + disposition type to be sent, user consent SHOULD also be obtained + before sending an MDN with a disposition type of "failed". + +2.3 The Original-Recipient Header + + Since electronic mail addresses may be rewritten while the message is + in transit, it is useful for the original recipient address to be + made available by the delivering MTA. The delivering MTA may be able + to obtain this information from the ORCPT parameter of the SMTP RCPT + TO command, as defined in RFC 1891 [8]. If this information is + available, the delivering MTA SHOULD insert an Original-Recipient + header at the beginning of the message (along with the Return-Path + header). The delivering MTA MAY delete any other Original-Recipient + headers that occur in the message. The syntax of this header, using + the ABNF of RFC 822 [2], is as follows + + original-recipient-header = + "Original-Recipient" ":" address-type ";" generic-address + + + + +Fajman Standards Track [Page 6] + +RFC 2298 Message Disposition Notifications March 1998 + + + The address-type and generic-address token are as as specified in the + description of the Original-Recipient field in section 3.2.3. + + The purpose of carrying the original recipient information and + returning it in the MDN is to permit automatic correlation of MDNs + with the original message on a per-recipient basis. + +2.4 Use with the Message/Partial Content Type + + The use of the headers Disposition-Notification-To, Disposition- + Notification-Options, and Original-Recipient with the MIME + Message/partial content type (RFC 2046 [5]) requires further + definition. + + When a message is segmented into two or more message/partial + fragments, the three headers mentioned in the above paragraph SHOULD + be placed in the "inner" or "enclosed" message (using the terms of + RFC 2046 [5]). These headers SHOULD NOT be used in the headers of + any of the fragments themselves. + + When the multiple message/partial fragments are reassembled, the + following applies. If these headers occur along with the other + headers of a message/partial fragment message, they pertain to an MDN + to be generated for the fragment. If these headers occur in the + headers of the "inner" or "enclosed" message (using the terms of RFC + 2046 [5]), they pertain to an MDN to be generated for the reassembled + message. Section 5.2.2.1 of RFC 2046 [5]) is amended to specify + that, in addition to the headers specified there, the three headers + described in this specification are to be appended, in order, to the + headers of the reassembled message. Any occurances of the three + headers defined here in the headers of the initial enclosing message + must not be copied to the reassembled message. + +3. Format of a Message Disposition Notification + + A message disposition notification is a MIME message with a top- + level content-type of multipart/report (defined in RFC 1892 [7]). + When a multipart/report content is used to transmit an MDN: + + (a) The report-type parameter of the multipart/report content is + "disposition-notification". + + (b) The first component of the multipart/report contains a human- + readable explanation of the MDN, as described in RFC 1892 [7]. + + (c) The second component of the multipart/report is of content-type + message/disposition-notification, described in section 3.1 of + this document. + + + +Fajman Standards Track [Page 7] + +RFC 2298 Message Disposition Notifications March 1998 + + + (d) If the original message or a portion of the message is to be + returned to the sender, it appears as the third component of the + multipart/report. The decision of whether or not to return the + message or part of the message is up to the UA generating the + MDN. However, in the case of encrypted messages requesting + MDNs, encrypted message text MUST be returned, if it is returned + at all, only in its original encrypted form. + + NOTE: For message dispostion notifications gatewayed from + foreign systems, the headers of the original message may not be + available. In this case the third component of the MDN may be + omitted, or it may contain "simulated" RFC 822 headers which + contain equivalent information. In particular, it is very + desirable to preserve the subject and date fields from the + original message. + + The MDN MUST be addressed (in both the message header and the + transport envelope) to the address(es) from the Disposition- + Notification-To header from the original message for which the MDN is + being generated. + + The From field of the message header of the MDN MUST contain the + address of the person for whom the message disposition notification + is being issued. + + The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be + null (<>), specifying that no Delivery Status Notification messages + or other messages indicating successful or unsuccessful delivery are + to be sent in response to an MDN. + + A message disposition notification MUST NOT itself request an MDN. + That is, it MUST NOT contain a Disposition-Notification-To header. + + The Message-ID header (if present) for an MDN MUST be different from + the Message-ID of the message for which the MDN is being issued. + + A particular MDN describes the disposition of exactly one message for + exactly one recipient. Multiple MDNs may be generated as a result of + one message submission, one per recipient. However, due to the + circumstances described in Section 2.1, MDNs may not be generated for + some recipients for which MDNs were requested. + +3.1 The message/disposition-notification content-type + + The message/disposition-notification content-type is defined as + follows: + + MIME type name: message + + + +Fajman Standards Track [Page 8] + +RFC 2298 Message Disposition Notifications March 1998 + + + MIME subtype name: disposition-notification + Optional parameters: none + Encoding considerations: "7bit" encoding is sufficient and + MUST be used to maintain readability + when viewed by non-MIME mail + readers. + Security considerations: discussed in section 6 of this memo. + + The message/disposition-notification report type for use in the + multipart/report is "disposition-notification". + + The body of a message/disposition-notification consists of one or + more "fields" formatted according to the ABNF of RFC 822 header + "fields" (see [2]). Using the ABNF of RFC 822, the syntax of the + message/disposition-notification content is as follows: + + disposition-notification-content = [ reporting-ua-field CRLF ] + [ mdn-gateway-field CRLF ] + [ original-recipient-field CRLF ] + final-recipient-field CRLF + [ original-message-id-field CRLF ] + disposition-field CRLF + *( failure-field CRLF ) + *( error-field CRLF ) + *( warning-field CRLF ) + *( extension-field CRLF ) + +3.1.1 General conventions for fields + + Since these fields are defined according to the rules of RFC 822 [2], + the same conventions for continuation lines and comments apply. + Notification fields may be continued onto multiple lines by beginning + each additional line with a SPACE or HTAB. Text which appears in + parentheses is considered a comment and not part of the contents of + that notification field. Field names are case-insensitive, so the + names of notification fields may be spelled in any combination of + upper and lower case letters. Comments in notification fields may + use the "encoded-word" construct defined in RFC 2047 [6]. + +3.1.2 "*-type" subfields + + Several fields consist of a "-type" subfield, followed by a semi- + colon, followed by "*text". For these fields, the keyword used in + the address-type or MTA-type subfield indicates the expected format + of the address or MTA-name that follows. + + The "-type" subfields are defined as follows: + + + + +Fajman Standards Track [Page 9] + +RFC 2298 Message Disposition Notifications March 1998 + + + (a) An "address-type" specifies the format of a mailbox address. + For example, Internet Mail addresses use the "rfc822" address- + type. + + address-type = atom + + (b) An "MTA-name-type" specifies the format of a mail transfer + agent name. For example, for an SMTP server on an Internet + host, the MTA name is the domain name of that host, and the + "dns" MTA-name-type is used. + + mta-name-type = atom + + Values for address-type and mta-name-type are case-insensitive. Thus + address-type values of "RFC822" and "rfc822" are equivalent. + + The Internet Assigned Numbers Authority (IANA) will maintain a + registry of address-type and mta-name-type values, along with + descriptions of the meanings of each, or a reference to a one or more + specifications that provide such descriptions. (The "rfc822" + address-type is defined in RFC 1891 [8].) Registration forms for + address-type and mta-name-type appear in RFC 1894 [9]. + + IANA will not accept registrations for any address-type name that + begins with "X-". These type names are reserved for experimental + use. + +3.1.3 Lexical tokens imported from RFC 822 + + The following lexical tokens, defined in RFC 822 [2], are used in the + ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text. + +3.2 Message/disposition-notification Fields + +3.2.1 The Reporting-UA field + + reporting-ua-field = "Reporting-UA" ":" ua-name + [ ";" ua-product ] + + ua-name = *text + + ua-product = *text + + The Reporting-UA field is defined as follows: + + A MDN describes the disposition of a message after it has been + delivered to a recipient. In all cases, the Reporting-UA is the UA + that performed the disposition described in the MDN. This field is + + + +Fajman Standards Track [Page 10] + +RFC 2298 Message Disposition Notifications March 1998 + + + optional, but recommended. For Internet Mail user agents, it is + recommended that this field contain both the DNS name of the + particular instance of the UA that generated the MDN and the name of + the product. For example, + + Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1 + + If the reporting UA consists of more than one component (e.g., a base + program and plug-ins), this may be indicated by including a list of + product names. + +3.2.2 The MDN-Gateway field + + The MDN-Gateway field indicates the name of the gateway or MTA that + translated a foreign (non-Internet) message disposition notification + into this MDN. This field MUST appear in any MDN which was + translated by a gateway from a foreign system into MDN format, and + MUST NOT appear otherwise. + + mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name + + mta-name = *text + + For gateways into Internet Mail, the MTA-name-type will normally be + "smtp", and the mta-name will be the Internet domain name of the + gateway. + +3.2.3 Original-Recipient field + + The Original-Recipient field indicates the original recipient address + as specified by the sender of the message for which the MDN is being + issued. For Internet Mail messages the value of the + + Original-Recipient field is obtained from the Original-Recipient + header from the message for which the MDN is being generated. If + there is no Original-Recipient header in the message, then the + Original-Recipient field MUST be omitted, unless the same information + is reliably available some other way. If there is an Original- + Recipient header in the original message (or original recipient + information is reliably available some other way), then the + Original-Recipient field must be supplied. If there is more than one + Original-Recipient header in the message, the UA may choose the one + to use or act as if no Original-Recipient header is present. + + original-recipient-field = + "Original-Recipient" ":" address-type ";" generic-address + + generic-address = *text + + + +Fajman Standards Track [Page 11] + +RFC 2298 Message Disposition Notifications March 1998 + + + The address-type field indicates the type of the original recipient + address. If the message originated within the Internet, the + address-type field field will normally be "rfc822", and the address + will be according to the syntax specified in RFC 822 [2]. The value + "unknown" should be used if the Reporting UA cannot determine the + type of the original recipient address from the message envelope. + This address is the same as that provided by the sender and can be + used to automatically correlate MDN reports with original messages on + a per recipient basis. + +3.2.4 Final-Recipient field + + The Final-Recipient field indicates the recipient for which the MDN + is being issued. This field MUST be present. + + The syntax of the field is as follows: + + final-recipient-field = + "Final-Recipient" ":" address-type ";" generic-address + + The generic-address subfield of the Final-Recipient field MUST + contain the mailbox address of the recipient (from the From header of + the MDN) as it was when the MDN was generated by the UA. + + The Final-Recipient address may differ from the address originally + provided by the sender, because it may have been transformed during + forwarding and gatewaying into an totally unrecognizable mess. + However, in the absence of the optional Original-Recipient field, the + Final-Recipient field and any returned content may be the only + information available with which to correlate the MDN with a + particular message recipient. + + The address-type subfield indicates the type of address expected by + the reporting MTA in that context. Recipient addresses obtained via + SMTP will normally be of address-type "rfc822". + + Since mailbox addresses (including those used in the Internet) may be + case sensitive, the case of alphabetic characters in the address MUST + be preserved. + +3.2.5 Original-Message-ID field + + The Original-Message-ID field indicates the message-ID of the message + for which the MDN is being issued. It is obtained from the Message- + ID header of the message for which the MDN is issued. This field + MUST be present if the original message contained a Message-ID + header. The syntax of the field is + + + + +Fajman Standards Track [Page 12] + +RFC 2298 Message Disposition Notifications March 1998 + + + original-message-id-field = "Original-Message-ID" ":" msg-id + + The msg-id token is as specified in RFC 822 [2]. + +3.2.6 Disposition field + + The Disposition field indicates the action performed by the + Reporting-UA on behalf of the user. This field MUST be present. + + The syntax for the Disposition field is: + + disposition-field = "Disposition" ":" disposition-mode ";" + disposition-type + [ '/' disposition-modifier + *( "," dispostion-modifier ) ] + + disposition-mode = action-mode "/" sending-mode + + action-mode = "manual-action" / "automatic-action" + + sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" + + disposition-type = "displayed" + / "dispatched" + / "processed" + / "deleted" + / "denied" + / "failed" + + disposition-modifier = ( "error" / "warning" ) + / ( "superseded" / "expired" / + "mailbox-terminated" ) + / disposition-modifier-extension + + disposition-modifier-extension = atom + + The disposition-mode, disposition-type and disposition-modifier may + be spelled in any combination of upper and lower case characters. + +3.2.6.1 Disposition modes + + The following disposition modes are defined: + + "manual-action" The disposition described by the + disposition type was a result of an + explicit instruction by the user rather + than some sort of automatically performed + action. + + + +Fajman Standards Track [Page 13] + +RFC 2298 Message Disposition Notifications March 1998 + + + "automatic-action" The disposition described by the + disposition type was a result of an + automatic action, rather than an explicit + instruction by the user for this message. + + "Manual-action" and "automatic-action" are + mutually exclusive. One or the other must + be specified. + + "MDN-sent-manually" The user explicity gave permission for + this particular MDN to be sent. + + "MDN-sent-automatically" The MDN was sent because the UA had + previously been configured to do so + automatically. + + "MDN-sent-manually" and "MDN-sent- + automatically" are mutually exclusive. + One or the other must be specified. + +3.2.6.2 Disposition types + + The following disposition-types are defined: + + "displayed" The message has been displayed by the UA to someone + reading the recipient's mailbox. There is + no guarantee that the content has been + read or understood. + + + "dispatched" The message has been sent somewhere in some manner + (e.g., printed, faxed, forwarded) without + necessarily having been previously + displayed to the user. The user may or + may not see the message later. + + "processed" The message has been processed in some manner (i.e., + by some sort of rules or server) without + being displayed to the user. The user may + or may not see the message later, or there + may not even be a human user associated + with the mailbox. + + "deleted" The message has been deleted. The recipient may or + may not have seen the message. The + recipient might "undelete" the message at + a later time and read the message. + + + + +Fajman Standards Track [Page 14] + +RFC 2298 Message Disposition Notifications March 1998 + + + "denied" The recipient does not wish the sender to be informed + of the message's disposition. A UA may + also siliently ignore message disposition + requests in this situation. + + "failed" A failure occurred that prevented the proper + generation of an MDN. More information + about the cause of the failure may be + contained in a Failure field. The + "failed" disposition type is not to be + used for the situation in which there is + is some problem in processing the message + other than interpreting the request for an + MDN. The "processed" or other disposition + type with appropriate disposition + modifiers is to be used in such + situations. + +3.2.6.3 Disposition modifiers + + The following disposition modifiers are defined: + + "error" An error of some sort occurred + that prevented successful + processing of the message. + Further information is contained + in an Error field. + + "warning" The message was successfully + processed but some sort of + exceptional condition occurred. + Further information is contained + in a Warning field. + + "superseded" The message has been + automatically rendered obsolete by + another message received. The + recipient may still access and + read the message later. + + "expired" The message has reached its + expiration date and has been + automatically removed from the + recipient's mailbox. + + "mailbox-terminated" The recipient's mailbox has been + terminated and all message in it + automatically removed. + + + +Fajman Standards Track [Page 15] + +RFC 2298 Message Disposition Notifications March 1998 + + + "Obsoleted", "expired", and + "terminated" are to be used with + the "deleted" disposition type and + the "autoaction" and "autosent" + disposition modifiers. + + disposition-modifier-extension Additional disposition modifiers + may be defined in the future by + later revisions or extensions to + this specification. Disposition + value names beginning with "X-" + will never be defined as standard + values; such names are reserved + for experimental use. MDN + disposition value names NOT + beginning with "X-" MUST be + registered with the Internet + Assigned Numbers Authority (IANA) + and described in a standards- + track RFC or an experimental RFC + approved by the IESG. See Section + 10 for a registration form. MDNs + with disposition modifier names + not understood by the receiving UA + MAY be silently ignored or placed + in the user's mailbox without + special inter- pretation. They + MUST not cause any error message + to be sent to the sender of the + MDN. + + If an UA developer does not wish + to register the meanings of such + disposition modifier extensions, + "X-" modifiers may be used for + this purpose. To avoid name + collisions, the name of the UA + implementation should follow the + "X-", (e.g. "X-Foomail-fratzed"). + + It is not required that a UA be able to generate all of the possible + values of the Disposition field. + + One and only one MDN may be issued on behalf of each particular + recipient by their user agent. That is, once an MDN has been issued + on behalf of a recipient, no further MDNs may be issued on behalf of + that recipient, even if another disposition is performed on the + message. However, if a message is forwarded, a "dispatched" MDN may + + + +Fajman Standards Track [Page 16] + +RFC 2298 Message Disposition Notifications March 1998 + + + been issued for the recipient doing the forwarding and the recipient + of the forwarded message may also cause an MDN to be generated. + +3.2.7 Failure, Error and Warning fields + + The Failure, Error and Warning fields are used to supply additional + information in the form of text messages when the "failure" + disposition type, "error" disposition modifier, and/or the "warning" + disposition modifer appear. The syntax is + + failure-field = "Failure" ":" *text + + error-field = "Error" ":" *text + + warning-field = "Warning" ":" *text + +3.3 Extension fields + + Additional MDN fields may be defined in the future by later revisions + or extensions to this specification. Extension-field names beginning + with "X-" will never be defined as standard fields; such names are + reserved for experimental use. MDN field names NOT beginning with + "X-" MUST be registered with the Internet Assigned Numbers Authority + (IANA) and described in a standards-track RFC or an experimental RFC + approved by the IESG. See Section 10 for a registration form. + + Extension MDN fields may be defined for the following reasons: + + (a) To allow additional information from foreign disposition + reports to be tunneled through Internet MDNs. The names of such + MDN fields should begin with an indication of the foreign + environment name (e.g. X400-Physical-Forwarding-Address). + + (b) To allow transmission of diagnostic information which is + specific to a particular user agent (UA). The names of such MDN + fields should begin with an indication of the UA implementation + which produced the MDN. (e.g. Foomail-information). + + If an application developer does not wish to register the meanings of + such extension fields, "X-" fields may be used for this purpose. To + avoid name collisions, the name of the application implementation + should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info"). + +4. Timeline of events + + The following timeline shows when various events in the processing of + a message and generation of MDNs take place: + + + + +Fajman Standards Track [Page 17] + +RFC 2298 Message Disposition Notifications March 1998 + + + -- User composes message + + -- User tells UA to send message + + -- UA passes message to MTA (original recipient information + passed along) + + -- MTA sends message to next MTA + + -- Final MTA receives message + + -- Final MTA delivers message to UA (possibily generating DSN) + + -- UA performs automatic processing and generates corresponding + MDNs ("dispatched", "processed", "deleted", "denied" or "failed" + disposition type with "automatic-action" and "MDN-sent- + automatically" disposition modes) + + -- UA displays list of messages to user + + -- User selects a message and requests that some action be + performed on it. + + -- UA performs requested action and, with user's permission, + sends appropriate MDN ("displayed", "dispatched", "processed", + "deleted", "denied" or "failed" disposition type with "manual- + action" and "MDN-sent-manually" or "MDN-sent-automatically" + disposition mode). + + -- User possibly performs other actions on message, but no + further MDNs are generated. + +5. Conformance and Usage Requirements + + A UA or gateway conforms to this specification if it generates MDNs + according to the protocol defined in this memo. It is not necessary + to be able to generate all of the possible values of the Disposition + field. + + UAs and gateways MUST NOT generate the Original-Recipient field of an + MDN unless the mail protocols provide the address originally + specified by the sender at the time of submission. Ordinary SMTP + does not make that guarantee, but the SMTP extension defined in RFC + 1891 [8] permits such information to be carried in the envelope if it + is available. The Original-Recipient header defined in this document + provides a way for the MTA to pass the original recipient address to + the UA. + + + + +Fajman Standards Track [Page 18] + +RFC 2298 Message Disposition Notifications March 1998 + + + Each sender-specified recipient address may result in more than one + MDN. If an MDN is requested for a recipient that is forwarded to + multiple recipients of an "alias" (as defined in RFC 1891 [8], + section 6.2.7.3), each of the recipients may issue an MDN. + + Successful distribution of a message to a mailing list exploder + SHOULD be considered final disposition of the message. A mailing + list exploder may issue an MDN with a disposition type of "processed" + and disposition modes of "automatic-action" and "MDN- sent- + automatically" indicating that the message has been forwarded to the + list. In this case, the request for MDNs is not propogated to the + members of the list. + + Alternaively, the mailing list exploder may issue no MDN and + propogate the request for MDNs to all members of the list. The + latter behavior is not recommended for any but small, closely knit + lists, as it might cause large numbers of MDNs to be generated and + may cause confidential subscribers to the list to be revealed. It is + also permissible for the mailing list exploder to direct MDNs to + itself, correlate them, and produce a report to the original sender + of the message. + + This specification places no restrictions on the processing of MDNs + received by user agents or mailing lists. + +6. Security Considerations + + The following security considerations apply when using MDNs: + +6.1 Forgery + + MDNs may be forged as easily as ordinary Internet electronic mail. + User agents and automatic mail handling facilities (such as mail + distribution list exploders) that wish to make automatic use of MDNs + should take appropriate precautions to minimize the potential damage + from denial-of-service attacks. + + Security threats related to forged MDNs include the sending of: + + (a) A falsified disposition notification when the indicated + disposition of the message has not actually ocurred, + + (b) Unsolicited MDNs + +6.2 Confidentiality + + Another dimension of security is confidentiality. There may be cases + in which a message recipient does not wish the disposition of + + + +Fajman Standards Track [Page 19] + +RFC 2298 Message Disposition Notifications March 1998 + + + messages addressed to him to be known or is concerned that the + sending of MDNs may reveal other confidential information (e.g., when + the message was read). In this situation, it is acceptable for the + UA to issue "denied" MDNs or to silently ignore requests for MDNs. + + If the Disposition-Notification-To header is passed on unmodified + when a message is distributed to the subscribers of a mailing list, + the subscribers to the list may be revealed to the sender of the + original message by the generation of MDNs. + + Headers of the original message returned in part 3 of the + multipart/report could reveal confidential information about host + names and/or network topology inside a firewall. + + An unencrypted MDN could reveal confidential information about an + encrypted message, especially if all or part of the original message + is returned in part 3 of the multipart/report. Encrypted MDNs are + not defined in this specification. + + In general, any optional MDN field may be omitted if the Reporting UA + site or user determines that inclusion of the field would impose too + great a compromise of site confidentiality. The need for such + confidentiality must be balanced against the utility of the omitted + information in MDNs. + +6.3 Non-Repudiation + + Within the framework of today's Internet Mail, the MDNs defined in + this document provide valuable information to the mail user; however, + MDNs can not be relied upon as a guarantee that a message was or was + not not seen by the recipient. Even if MDNs are not actively forged, + they may be lost in transit. The MDN issuing mechanism may be + bypassed in some manner by the recipient. + +7. Collected Grammar + + NOTE: The following lexical tokens are defined in RFC 822: atom, + CRLF, mailbox, msg-id, text. The definitions of attribute and value + are as in the definition of the Content-Type header in RFC 2045 [4]. + + Message headers: + + mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox + + Disposition-Notification-Options = + "Disposition-Notification-Options" ":" + disposition-notification-parameters + + + + +Fajman Standards Track [Page 20] + +RFC 2298 Message Disposition Notifications March 1998 + + + disposition-notification-parameters = parameter *(";" parameter) + + parameter = attribute "=" importance "," 1#value + + importance = "required" / "optional" + + original-recipient-header = + "Original-Recipient" ":" address-type ";" generic-address + + + Report content: + + disposition-notification-content = [ reporting-ua-field CRLF ] + [ mdn-gateway-field CRLF ] + [ original-recipient-field CRLF ] + final-recipient-field CRLF + [ original-message-id-field CRLF ] + disposition-field CRLF + *( failure-field CRLF ) + *( error-field CRLF ) + *( warning-field CRLF ) + *( extension-field CRLF ) + + address-type = atom + + mta-name-type = atom + + reporting-ua-field = "Reporting-UA" ":" ua-name + [ ";" ua-product ] + + ua-name = *text + + ua-product = *text + + mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name + + mta-name = *text + + original-recipient-field = + "Original-Recipient" ":" address-type ";" generic-address + + generic-address = *text + + final-recipient-field = + "Final-Recipient" ":" address-type ";" generic-address + + disposition-field = "Disposition" ":" disposition-mode ";" + disposition-type + + + +Fajman Standards Track [Page 21] + +RFC 2298 Message Disposition Notifications March 1998 + + + [ '/' disposition-modifier + *( "," dispostion-modifier ) ] + + disposition-mode = action-mode "/" sending-mode + + action-mode = "manual-action" / "automatic-action" + + sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" + + disposition-type = "displayed" + / "dispatched" + / "processed" + / "deleted" + / "denied" + / "failed" + + disposition-modifier = ( "error" / "warning" ) + / ( "superseded" / "expired" / + "mailbox-terminated" ) + / disposition-modifier-extension + + disposition-modifier-extension = atom + + original-message-id-field = "Original-Message-ID" ":" msg-id + + failure-field = "Failure" ":" *text + + error-field = "Error" ":" *text + + warning-field = "Warning" ":" *text + + extension-field = extension-field-name ":" *text + + extension-field-name = atom + +8. Guidelines for Gatewaying MDNs + + NOTE: This section provides non-binding recommendations for the + construction of mail gateways that wish to provide semi-transparent + disposition notifications between the Internet and another electronic + mail system. Specific MDN gateway requirements for a particular pair + of mail systems may be defined by other documents. + +8.1 Gatewaying from other mail systems to MDNs + + A mail gateway may issue an MDN to convey the contents of a "foreign" + disposition notification over Internet Mail. When there are + appropriate mappings from the foreign notification elements to MDN + + + +Fajman Standards Track [Page 22] + +RFC 2298 Message Disposition Notifications March 1998 + + + fields, the information may be transmitted in those MDN fields. + Additional information (such as might be needed to tunnel the foreign + notification through the Internet) may be defined in extension MDN + fields. (Such fields should be given names that identify the foreign + mail protocol, e.g. X400-* for X.400 protocol elements) + + The gateway must attempt to supply reasonable values for the + Reporting-UA, Final-Recipient, and Disposition fields. These will + normally be obtained by translating the values from the foreign + notification into their Internet-style equivalents. However, some + loss of information is to be expected. + + The sender-specified recipient address, and the original message-id, + if present in the foreign notification, should be preserved in the + Original-Recipient and Original-Message-ID fields. + + The gateway should also attempt to preserve the "final" recipient + address from the foreign system. Whenever possible, foreign protocol + elements should be encoded as meaningful printable ASCII strings. + + For MDNs produced from foreign disposition notifications, the name of + the gateway MUST appear in the MDN-Gateway field of the MDN. + +8.2 Gatewaying from MDNs to other mail systems + + It may be possible to gateway MDNs from the Internet into a foreign + mail system. The primary purpose of such gatewaying is to convey + disposition information in a form that is usable by the destination + system. A secondary purpose is to allow "tunneling" of MDNs through + foreign mail systems, in case the MDN may be gatewayed back into the + Internet. + + In general, the recipient of the MDN (i.e., the sender of the + original message) will want to know, for each recipient: the closest + available approximation to the original recipient address, and the + disposition (displayed, printed, etc.). + + If possible, the gateway should attempt to preserve the Original- + Recipient address and Original-Message-ID (if present), in the + resulting foreign disposition report. + + If it is possible to tunnel an MDN through the destination + environment, the gateway specification may define a means of + preserving the MDN information in the disposition reports used by + that environment. + + + + + + +Fajman Standards Track [Page 23] + +RFC 2298 Message Disposition Notifications March 1998 + + +9. Example + + NOTE: This example is provided as illustration only, and is not + considered part of the MDN protocol specification. If the example + conflicts with the protocol definition above, the example is wrong. + + Likewise, the use of *-type subfield names or extension fields in + this example is not to be construed as a definition for those type + names or extension fields. + +9.1 This is an MDN issued after a message has been displayed to the user + of an Internet Mail user agent. + + Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 + From: Joe Recipient <Joe_Recipient@mega.edu> + Message-Id: <199509200019.12345@mega.edu> + Subject: Disposition notification + To: Jane Sender <Jane_Sender@huge.com> + MIME-Version: 1.0 + Content-Type: multipart/report; report-type=disposition-notification; + boundary="RAA14128.773615765/mega.edu" + + --RAA14128.773615765/mega.edu + + The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe + Recipient <Joe_Recipient@mega.edu> with subject "First draft of + report" has been displayed. This is no guarantee that the message + has been read or understood. + + --RAA14128.773615765/mega.edu + content-type: message/disposition-notification + + Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1 + Original-Recipient: rfc822;Joe_Recipient@mega.edu + Final-Recipient: rfc822;Joe_Recipient@mega.edu + Original-Message-ID: <199509192301.23456@huge.com> + Disposition: manual-action/MDN-sent-manually; displayed + + --RAA14128.773615765/mega.edu + content-type: message/rfc822 + + [original message goes here] + + --RAA14128.773615765/mega.edu-- + + + + + + + +Fajman Standards Track [Page 24] + +RFC 2298 Message Disposition Notifications March 1998 + + +10. IANA Registration Forms + + The forms below are for use when registering a new parameter name for + the Disposition-Notification-Options header, a new disposition + modifier name, or a new MDN extension field. Each piece of + information required by a registration form may be satisfied either + by providing the information on the form itself, or by including a + reference to a published, publicly available specification that + includes the necessary information. IANA MAY reject registrations + because of incomplete registration forms, imprecise specifications, + or inappropriate names. + + To register, complete the applicable form below and send it via + electronic mail to <IANA@IANA.ORG>. + +10.1 IANA registration form for Disposition-Notification-Options header + parameter names + + A registration for a Disposition-Notification-Options header + parameter name MUST include the following information: + + (a) The proposed parameter name. + + (b) The syntax for parameter values, specified using BNF, ABNF, + regular expressions, or other non-ambiguous language. + + (c) If parameter values are not composed entirely of graphic + characters from the US-ASCII repertoire, a specification for how they + are to be encoded as graphic US-ASCII characters in a Disposition- + Notification-Options header. + + (d) A reference to a standards track RFC or experimental RFC approved + by the IESG that describes the semantics of the parameter values. + +10.2 IANA registration form for disposition modifer names + + A registration for a disposition-modifier name MUST include the + following information: + + (a) The proposed disposition-modifier name. + + (b) A reference to a standards track RFC or experimental RFC approved + by the IESG that describes the semantics of the disposition modifier. + +10.3 IANA registration form for MDN extension field names + + A registration for an MDN extension field name MUST include the + following information: + + + +Fajman Standards Track [Page 25] + +RFC 2298 Message Disposition Notifications March 1998 + + + (a) The proposed extension field name. + + (b) The syntax for extension values, specified using BNF, ABNF, + regular expressions, or other non-ambiguous language. + + (c) If extension field values are not composed entirely of graphic + characters from the US-ASCII repertoire, a specification for how they + are to be encoded as graphic US-ASCII characters in a Disposition- + Notification-Options header. + + (d) A reference to a standards track RFC or experimental RFC approved + by the IESG that describes the semantics of the extension field. + +11. Acknowledgments + + This document is based on the Delivery Status Notifications document, + RFC 1894 [9], by Keith Moore and Greg Vaudreuil. Contributions were + made by members of the IETF Receipt Working Group, including Harald + Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned + Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, + Pete Resnick, Chuck Shih. + +12. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [3] Braden, R. (ed.), "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + [6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part + Three: Message Header Extensions for Non-Ascii Text", RFC + 2047, November 1996. + + [7] Vaudreuil, G., "The Multipart/Report Content Type for the + Reporting of Mail System Administrative Messages", RFC 1892, + January 1996. + + + +Fajman Standards Track [Page 26] + +RFC 2298 Message Disposition Notifications March 1998 + + + [8] Moore, K., "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, January 1996. + + [9] Moore, K., and G. Vaudreuil, "An Extensible Format for + Delivery Status Notifications, RFC 1894, January 1996. + + [10] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +13. Author's Address + + Roger Fajman + National Institutes of Health + Building 12A, Room 3063 + 12 South Drive MSC 5659 + Bethesda, Maryland 20892-5659 + USA + + EMail: raf@cu.nih.gov + Phone: +1 301 402 4265 + Fax: +1 301 480 6241 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fajman Standards Track [Page 27] + +RFC 2298 Message Disposition Notifications March 1998 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Fajman Standards Track [Page 28] + |