rfc2298.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,572 行 · 第 1/5 页

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