You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-dev@james.apache.org by ba...@apache.org on 2007/09/18 02:14:48 UTC
svn commit: r576631 [20/29] - in /james/site/trunk/www/jsieve: ./ apidocs/
apidocs/org/apache/jsieve/ apidocs/org/apache/jsieve/class-use/
apidocs/org/apache/jsieve/commands/
apidocs/org/apache/jsieve/commands/class-use/
apidocs/org/apache/jsieve/comma...
Modified: james/site/trunk/www/jsieve/rfc2298.txt
URL: http://svn.apache.org/viewvc/james/site/trunk/www/jsieve/rfc2298.txt?rev=576631&r1=576630&r2=576631&view=diff
==============================================================================
--- james/site/trunk/www/jsieve/rfc2298.txt (original)
+++ james/site/trunk/www/jsieve/rfc2298.txt Mon Sep 17 17:14:20 2007
@@ -1,1570 +1,1570 @@
-
-
-
-
-
-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 <Jo...@mega.edu>
- Message-Id: <19...@mega.edu>
- Subject: Disposition notification
- To: Jane Sender <Ja...@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 <Jo...@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: <19...@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 <IA...@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]
-
+
+
+
+
+
+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
+
[... 993 lines stripped ...]