james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r526370 [3/4] - in /james/jsieve/trunk/src/site: resources/rfc2234.txt resources/rfc2244.txt resources/rfc2298.txt resources/rfc3028.txt site.xml
Date Sat, 07 Apr 2007 06:28:56 GMT
Added: james/jsieve/trunk/src/site/resources/rfc2298.txt
URL: http://svn.apache.org/viewvc/james/jsieve/trunk/src/site/resources/rfc2298.txt?view=auto&rev=526370
==============================================================================
--- james/jsieve/trunk/src/site/resources/rfc2298.txt (added)
+++ james/jsieve/trunk/src/site/resources/rfc2298.txt Fri Apr  6 23:28:55 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 <Joe_Recipient@mega.edu>
+   Message-Id: <199509200019.12345@mega.edu>
+   Subject: Disposition notification
+   To: Jane Sender <Jane_Sender@huge.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=disposition-notification;
+         boundary="RAA14128.773615765/mega.edu"
+
+   --RAA14128.773615765/mega.edu
+
+   The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
+   Recipient <Joe_Recipient@mega.edu> with subject "First draft of
+   report" has been displayed.  This is no guarantee that the message
+   has been read or understood.
+
+   --RAA14128.773615765/mega.edu
+   content-type: message/disposition-notification
+
+   Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
+   Original-Recipient: rfc822;Joe_Recipient@mega.edu
+   Final-Recipient: rfc822;Joe_Recipient@mega.edu
+   Original-Message-ID: <199509192301.23456@huge.com>
+   Disposition: manual-action/MDN-sent-manually; displayed
+
+   --RAA14128.773615765/mega.edu
+   content-type: message/rfc822
+
+   [original message goes here]
+
+   --RAA14128.773615765/mega.edu--
+
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 24]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+10.  IANA Registration Forms
+
+   The forms below are for use when registering a new parameter name for
+   the Disposition-Notification-Options header, a new disposition
+   modifier name, or a new MDN extension field.  Each piece of
+   information required by a registration form may be satisfied either
+   by providing the information on the form itself, or by including a
+   reference to a published, publicly available specification that
+   includes the necessary information.  IANA MAY reject registrations
+   because of incomplete registration forms, imprecise specifications,
+   or inappropriate names.
+
+   To register, complete the applicable form below and send it via
+   electronic mail to <IANA@IANA.ORG>.
+
+10.1 IANA registration form for Disposition-Notification-Options header
+   parameter names
+
+   A registration for a Disposition-Notification-Options header
+   parameter name MUST include the following information:
+
+   (a) The proposed parameter name.
+
+   (b) The syntax for parameter values, specified using BNF, ABNF,
+   regular expressions, or other non-ambiguous language.
+
+   (c) If parameter values are not composed entirely of graphic
+   characters from the US-ASCII repertoire, a specification for how they
+   are to be encoded as graphic US-ASCII characters in a Disposition-
+   Notification-Options header.
+
+   (d) A reference to a standards track RFC or experimental RFC approved
+   by the IESG that describes the semantics of the parameter values.
+
+10.2 IANA registration form for disposition modifer names
+
+   A registration for a disposition-modifier name MUST include the
+   following information:
+
+   (a) The proposed disposition-modifier name.
+
+   (b) A reference to a standards track RFC or experimental RFC approved
+   by the IESG that describes the semantics of the disposition modifier.
+
+10.3 IANA registration form for MDN extension field names
+
+   A registration for an MDN extension field name MUST include the
+   following information:
+
+
+
+Fajman                      Standards Track                    [Page 25]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   (a) The proposed extension field name.
+
+   (b) The syntax for extension values, specified using BNF, ABNF,
+   regular expressions, or other non-ambiguous language.
+
+   (c) If extension field values are not composed entirely of graphic
+   characters from the US-ASCII repertoire, a specification for how they
+   are to be encoded as graphic US-ASCII characters in a Disposition-
+   Notification-Options header.
+
+   (d) A reference to a standards track RFC or experimental RFC approved
+   by the IESG that describes the semantics of the extension field.
+
+11.  Acknowledgments
+
+   This document is based on the Delivery Status Notifications document,
+   RFC 1894 [9], by Keith Moore and Greg Vaudreuil.  Contributions were
+   made by members of the IETF Receipt Working Group, including Harald
+   Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned
+   Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell,
+   Pete Resnick, Chuck Shih.
+
+12.  References
+
+   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+         August 1982.
+
+   [2]   Crocker, D., "Standard for the Format of ARPA Internet Text
+         Messages", STD 11, RFC 822, August 1982.
+
+   [3]   Braden, R. (ed.), "Requirements for Internet Hosts -
+         Application and Support", STD 3, RFC 1123, October 1989.
+
+   [4]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One:  Format of Internet Message
+         Bodies", RFC 2045, November 1996.
+
+   [5]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Two:  Media Types", RFC 2046, November
+         1996.
+
+   [6]   Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
+         Three:  Message Header Extensions for Non-Ascii Text", RFC
+         2047, November 1996.
+
+   [7]   Vaudreuil, G., "The Multipart/Report Content Type for the
+         Reporting of Mail System Administrative Messages", RFC 1892,
+         January 1996.
+
+
+
+Fajman                      Standards Track                    [Page 26]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   [8]   Moore, K., "SMTP Service Extension for Delivery Status
+         Notifications", RFC 1891, January 1996.
+
+   [9]   Moore, K., and G. Vaudreuil, "An Extensible Format for
+         Delivery Status Notifications, RFC 1894, January 1996.
+
+   [10]  Bradner, S., "Key Words for Use in RFCs to Indicate
+         Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+13.  Author's Address
+
+   Roger Fajman
+   National Institutes of Health
+   Building 12A, Room 3063
+   12 South Drive MSC 5659
+   Bethesda, Maryland 20892-5659
+   USA
+
+   EMail:  raf@cu.nih.gov
+   Phone:  +1 301 402 4265
+   Fax:    +1 301 480 6241
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 27]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 28]
+



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message