rfc1894.txt

RFC 的详细文档！

Network Working Group                                           K. Moore
Request for Comments: 1894                       University of Tennessee
Category: Standards Track                                   G. Vaudreuil
                                                  Octel Network Services
                                                            January 1996


     An Extensible Message Format for Delivery Status 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.

Abstract

   This memo defines a MIME content-type that may be used by a message
   transfer agent (MTA) or electronic mail gateway to report the result
   of an attempt to deliver a message to one or more recipients.  This
   content-type is intended as a machine-processable replacement for the
   various types of delivery status notifications currently used in
   Internet electronic mail.

   Because many messages are sent between the Internet and other
   messaging systems (such as X.400 or the so-called "LAN-based"
   systems), the DSN 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 and
   error codes, in addition to those normally used in Internet mail.
   Additional attributes may also be defined to support "tunneling" of
   foreign notifications through Internet mail.

   Any questions, comments, and reports of defects or ambiguities in
   this specification may be sent to the mailing list for the NOTARY
   working group of the IETF, using the address
   <[e-mail]>.  Requests to subscribe to the mailing
   list should be addressed to <[e-mail]>.
   Implementors of this specification are encouraged to subscribe to the
   mailing list, so that they will quickly be informed of any problems
   which might hinder interoperability.

   NOTE: This document is a Proposed Standard.  If and when this
   protocol is submitted for Draft Standard status, any normative text
   (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
   this document will be re-evaluated in light of implementation



Moore & Vaudreuil           Standards Track                     [Page 1]

RFC 1894             Delivery Status Notifications          January 1996


   experience, and are thus subject to change.

1. Introduction

   This memo defines a MIME [1] content-type for delivery status
   notifications (DSNs).  A DSN can be used to notify the sender of a
   message of any of several conditions:  failed delivery, delayed
   delivery, successful delivery, or the gatewaying of a message into an
   environment that may not support DSNs.  The "message/delivery-status"
   content-type defined herein is intended for use within the framework
   of the "multipart/report" content type defined in [2].

   This memo defines only the format of the notifications.  An extension
   to the Simple Message Transfer Protocol (SMTP) [3] to fully support
   such notifications is the subject of a separate memo [4].

1.1 Purposes

   The DSNs defined in this memo are expected to serve several purposes:

(a) Inform human beings of the status of message delivery processing, as
    well as the reasons for any delivery problems or outright failures,
    in a manner which is largely independent of human language;

(b) Allow mail user agents to keep track of the delivery status of
    messages sent, by associating returned DSNs with earlier message
    transmissions;

(c) Allow mailing list exploders to automatically maintain their
    subscriber lists when delivery attempts repeatedly fail;

(d) Convey delivery and non-delivery notifications resulting from
    attempts to deliver messages to "foreign" mail systems via a
    gateway;

(e) 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;

(f) Allow language-independent, yet reasonably precise, indications of
    the reason for the failure of a message to be delivered (once status
    codes of sufficient precision are defined); and

(g) Provide sufficient information to remote MTA maintainers (via
    "trouble tickets") so that they can understand the nature of
    reported errors.  This feature is used in the case that failure to
    deliver a message is due to the malfunction of a remote MTA and the



Moore & Vaudreuil           Standards Track                     [Page 2]

RFC 1894             Delivery Status Notifications          January 1996


    sender wants to report the problem to the remote MTA administrator.

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 the
    user agents) to unambiguously associate a DSN with the message that
    was sent and the original recipient address for which the DSN is
    issued (if such information is available), even if the message was
    forwarded to another recipient address.

(c) It must be able to preserve the reason for the success or failure of
    a delivery attempt in a remote messaging system, using the
    "language" (mailbox addresses and status codes) of that remote
    system.

(d) It must also be able to describe the reason for the success or
    failure of a delivery attempt, independent of any particular human
    language or of the "language" of any particular mail system.

(e) It must preserve enough information to allow the maintainer of a
    remote MTA to understand (and if possible, reproduce) the conditions
    that caused a delivery failure at that MTA.

(f) For any notifications issued by foreign mail systems, which are
    translated by a mail gateway to the DSN format, the DSN must
    preserve the "type" of the foreign addresses and error codes, so
    that these may be correctly interpreted by gateways.

   A DSN contains a set of per-message fields which identify the message
   and the transaction during which the message was submitted, along
   with other fields that apply to all delivery attempts described by
   the DSN.  The DSN also includes a set of per-recipient fields to
   convey the result of the attempt to deliver the message to each of
   one or more recipients.

1.3 Terminology

   A message may be transmitted through several message transfer agents
   (MTAs) on its way to a recipient.  For a variety of reasons,
   recipient addresses may be rewritten during this process, so each MTA
   may potentially see a different recipient address.  Depending on the
   purpose for which a DSN is used, different formats of a particular
   recipient address will be needed.



Moore & Vaudreuil           Standards Track                     [Page 3]

RFC 1894             Delivery Status Notifications          January 1996


   Several DSN fields are defined in terms of the view from a particular
   MTA in the transmission.  The MTAs are assigned the following names:

   (a) Original MTA

   The Original MTA is the one to which the message is submitted for
   delivery by the sender of the message.

   (b) Reporting MTA

   For any DSN, the Reporting MTA is the one which is reporting the
   results of delivery attempts described in the DSN.

   If the delivery attempts described occurred in a "foreign" (non-
   Internet) mail system, and the DSN was produced by translating the
   foreign notice into DSN format, the Reporting MTA will still identify
   the "foreign" MTA where the delivery attempts occurred.

   (c) Received-From MTA

   The Received-From MTA is the MTA from which the Reporting MTA
   received the message, and accepted responsibility for delivery of the
   message.

   (d) Remote MTA

   If an MTA determines that it must relay a message to one or more
   recipients, but the message cannot be transferred to its "next hop"
   MTA, or if the "next hop" MTA refuses to accept responsibility for
   delivery of the message to one or more of its intended recipients,
   the relaying MTA may need to issue a DSN on behalf of the recipients
   for whom the message cannot be delivered.  In this case the relaying
   MTA is the Reporting MTA, and the "next hop" MTA is known as the
   Remote MTA.

















Moore & Vaudreuil           Standards Track                     [Page 4]

RFC 1894             Delivery Status Notifications          January 1996


Figure 1 illustrates the relationship between the various MTAs.


+-----+    +--------+           +---------+    +---------+      +------+
|     |    |        |           |Received-|    |         |      |      |
|     | => |Original| => ... => |  From   | => |Reporting| ===> |Remote|
| user|    |   MTA  |           |   MTA   |    |   MTA   | <No! |  MTA |
|agent|    +--------+           +---------+    +----v----+      +------+
|     |                                             |
|     | <-------------------------------------------+
+-----+      (DSN returned to sender by Reporting MTA)


     Figure 1.  Original, Received-From, Reporting and Remote MTAs


   Each of these MTAs may provide information which is useful in a DSN:

+ Ideally, the DSN will contain the address of each recipient as
  originally specified to the Original MTA by the sender of the message.
  This version of the address is needed (rather than a forwarding
  address or some modified version of the original address) so that the
  sender may compare the recipient address in the DSN with the address
  in the sender's records (e.g. an address book for an individual, the
  list of subscribers for a mailing list) and take appropriate action.

  Similarly, the DSN might contain an "envelope identifier" that was
  known to both the sender's user agent and the Original MTA at the time
  of message submission, and which, if included in the DSN, can be used
  by the sender to keep track of which messages were or were not
  delivered.

+ If a message was (a) forwarded to a different address than that
  specified by the sender, (b) gatewayed to a different mail system than
  that used by the sender, or (c) subjected to address rewriting during
  transmission, the "final" form of the recipient address (i.e. the one
  seen by the Reporting MTA) will be different than the original
  (sender-specified) recipient address.  Just as the sender's user agent
  (or the sender) prefers the original recipient address, so the "final"
  address is needed when reporting a problem to the postmaster of the
  site where message delivery failed, because only the final recipient
  address will allow her to reproduce the conditions that caused the
  failure.

+ A "failed" DSN should contain the most accurate explanation for the
  delivery failure that is available.  For ease of interpretation, this
  information should be a format which is independent of the mail
  transport system that issued the DSN.  However, if a foreign error



Moore & Vaudreuil           Standards Track                     [Page 5]

RFC 1894             Delivery Status Notifications          January 1996


  code is translated into some transport-independent format, some
  information may be lost.  It is therefore desirable to provide both a
  transport-independent status code and a mechanism for reporting
  transport-specific codes.  Depending on the circumstances that
  produced delivery failure, the transport-specific code might be
  obtained from either the Reporting MTA or the Remote MTA.

   Since different values for "recipient address" and "delivery status
   code" are needed according to the circumstance in which a DSN will be
   used, and since the MTA that issues the DSN cannot anticipate those
   circumstances, the DSN format described here may contain both the
   original and final forms of a recipient address, and both a
   transport-independent and a transport-specific indication of delivery
   status.

   Extension fields may also be added by the Reporting MTA as needed to
   provide additional information for use in a trouble ticket or to
   preserve information for tunneling of foreign delivery reports
   through Internet DSNs.

   The Original, Reporting, and Remote MTAs may exist in very different
   environments and use dissimilar transport protocols, MTA names,
   address formats, and delivery status codes.  DSNs therefore do not
   assume any particular format for mailbox addresses, MTA names, or
   transport-specific status codes.  Instead, the various DSN fields
   that carry such quantities consist of a "type" subfield followed by a
   subfield whose contents are ordinary text characters, and the format
   of which is indicated by the "type" subfield.  This allows a DSN to
   convey these quantities regardless of format.

2. Format of a Delivery Status Notification

   A DSN is a MIME message with a top-level content-type of
   multipart/report (defined in [2]).  When a multipart/report content
   is used to transmit a DSN:

(a) The report-type parameter of the multipart/report content is
    "delivery-status".

(b) The first component of the multipart/report contains a human-
    readable explanation of the DSN, as described in [2].

(c) The second component of the multipart/report is of content-type
    message/delivery-status, described in section 2.1 of this document.

(d) If the original message or a portion of the message is to be