You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by da...@apache.org on 2007/05/03 14:59:55 UTC
svn commit: r534834 [3/5] - in /james/mailet: ./ lib/ src/ src/main/
src/main/java/ src/site/ src/site/resources/ src/site/resources/images/
src/site/xdoc/ src/site/xdoc/images/ src/site/xdoc/stylesheets/ src/test/
src/test/java/ src/test/resources/
Added: james/mailet/src/site/resources/rfc2298.txt
URL: http://svn.apache.org/viewvc/james/mailet/src/site/resources/rfc2298.txt?view=auto&rev=534834
==============================================================================
--- james/mailet/src/site/resources/rfc2298.txt (added)
+++ james/mailet/src/site/resources/rfc2298.txt Thu May 3 05:59:54 2007
@@ -0,0 +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]
+
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org