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
   <notifications@cs.utk.edu>.  Requests to subscribe to the mailing
   list should be addressed to <notifications-request@cs.utk.edu>.
   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
    returned to the sender, it appears as the third component of the
    multipart/report.



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


    NOTE: For delivery status notifications gatewayed from foreign
    systems, the headers of the original message may not be available.
    In this case the third component of the DSN 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, date, and message-id (or equivalent) fields from the
    original message.

   The DSN MUST be addressed (in both the message header and the
   transport envelope) to the return address from the transport envelope
   which accompanied the original message for which the DSN was
   generated.  (For a message that arrived via SMTP, the envelope return
   address appears in the MAIL FROM command.)

   The From field of the message header of the DSN SHOULD contain the
   address of a human who is responsible for maintaining the mail system
   at the Reporting MTA site (e.g.  Postmaster), so that a reply to the
   DSN will reach that person.  Exception: if a DSN is translated from a
   foreign delivery report, and the gateway performing the translation
   cannot determine the appropriate address, the From field of the DSN
   MAY be the address of a human who is responsible for maintaining the
   gateway.

   The envelope sender address of the DSN SHOULD be chosen to ensure
   that no delivery status reports will be issued in response to the DSN
   itself, and MUST be chosen so that DSNs will not generate mail loops.
   Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
   command MUST use a NULL return address, i.e. "MAIL FROM:<>".

   A particular DSN describes the delivery status for exactly one
   message.  However, an MTA MAY report on the delivery status for
   several recipients of the same message in a single DSN.  Due to the
   nature of the mail transport system (where responsibility for
   delivery of a message to its recipients may be split among several
   MTAs, and delivery to any particular recipient may be delayed),
   multiple DSNs may be still be issued in response to a single message
   submission.














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


2.1 The message/delivery-status content-type

   The message/delivery-status content-type is defined as follows:

     MIME type name:                message
     MIME subtype name:             delivery-status
     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 4 of this memo.

   The message/delivery-status report type for use in the
   multipart/report is "delivery-status".

   The body of a message/delivery-status consists of one or more
   "fields" formatted according to the ABNF of RFC 822 header "fields"
   (see [6]).  The per-message fields appear first, followed by a blank
   line.  Following the per-message fields are one or more groups of
   per-recipient fields.  Each group of per-recipient fields is preceded
   by a blank line.  Using the ABNF of RFC 822, the syntax of the
   message/delivery-status content is as follows:

     delivery-status-content =
          per-message-fields 1*( CRLF per-recipient-fields )

   The per-message fields are described in section 2.2.  The per-
   recipient fields are described in section 2.3.


2.1.1 General conventions for DSN fields

   Since these fields are defined according to the rules of RFC 822, 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 DSN fields may use the
   "encoded-word" construct defined in [7].

   A number of DSN fields are defined to have a portion of a field body
   of "xtext".  "xtext" is used to allow encoding sequences of octets
   which contain values outside the range [1-127 decimal] of traditional
   ASCII characters, and also to allow comments to be inserted in the
   data.  Any octet may be encoded as "+" followed by two upper case



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


   hexadecimal digits.  (The "+" character MUST be encoded as "+2B".)
   With certain exceptions, octets that correspond to ASCII characters
   may be represented as themselves.  SPACE and HTAB characters are
   ignored.  Comments may be included by enclosing them in parenthesis.
   Except within comments, encoded-words such as defined in [7] may NOT
   be used in xtext.

   "xtext" is formally defined as follows:

     xtext = *( xchar / hexchar / linear-white-space / comment )

     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
          except for "+", "\" and "(".

   "hexchar"s are intended to encode octets that cannot be represented
   as plain text, either because they are reserved, or because they are
   non-printable.  However, any octet value may be represented by a
   "hexchar".

     hexchar = ASCII "+" immediately followed by two upper case
          hexadecimal digits

   When encoding an octet sequence as xtext:

   + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\",
     and "(", MAY be encoded as itself.  (Some CHARs in this range may
     also be encoded as "hexchar"s, at the implementor's discretion.)

   + ASCII CHARs that fall outside the range above must be encoded as
     "hexchar".

   + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line
     lengths from becoming excessive.

   + Comments MAY be added to clarify the meaning for human readers.

2.1.2 "*-type" subfields

   Several DSN fields consist of a "-type" subfield, followed by a
   semicolon, followed by "*text".  For these fields, the keyword used
   in the address-type, diagnostic-type, or MTA-name-type subfield
   indicates the expected format of the address, status-code, or MTA-
   name which follows.








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


   The "-type" subfields are defined as follows:

(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) A "diagnostic-type" specifies the format of a status code.  For
    example, when a DSN field contains a reply code reported via the
    Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is
    used.

         diagnostic-type = atom

(c) An "MTA-name-type" specifies the format of an MTA 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, diagnostic-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-types, diagnostic-types, and MTA-name-types,
   along with descriptions of the meanings and acceptable values of
   each, or a reference to a one or more specifications that provide
   such descriptions.  (The "rfc822" address-type, "smtp" diagnostic-
   type, and "dns" MTA-name-type are defined in [4].)  Registration
   forms for address-type, diagnostic-type, and MTA-name-type appear in
   section 8 of this document.

   IANA will not accept registrations for any address-type, diagnostic-
   type, or MTA-name-type name that begins with "X-".  These type names
   are reserved for experimental use.

2.1.3 Lexical tokens imported from RFC 822

   The following lexical tokens, defined in [6], are used in the ABNF
   grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-
   white-space, SPACE, text.  The date-time lexical token is defined in
   [8].








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


2.2 Per-Message DSN Fields

   Some fields of a DSN apply to all of the delivery attempts described
   by that DSN.  These fields may appear at most once in any DSN.  These
   fields are used to correlate the DSN with the original message
   transaction and to provide additional information which may be useful
   to gateways.

     per-message-fields =
          [ original-envelope-id-field CRLF ]
          reporting-mta-field CRLF
          [ dsn-gateway-field CRLF ]
          [ received-from-mta-field CRLF ]
          [ arrival-date-field CRLF ]
          *( extension-field CRLF )

2.2.1 The Original-Envelope-Id field

   The optional Original-Envelope-Id field contains an "envelope
   identifier" which uniquely identifies the transaction during which
   the message was submitted, and was either (a) specified by the sender
   and supplied to the sender's MTA, or (b) generated by the sender's
   MTA and made available to the sender when the message was submitted.
   Its purpose is to allow the sender (or her user agent) to associate
   the returned DSN with the specific transaction in which the message
   was sent.

   If such an envelope identifier was present in the envelope which
   accompanied the message when it arrived at the Reporting MTA, it
   SHOULD be supplied in the Original-Envelope-Id field of any DSNs
   issued as a result of an attempt to deliver the message.  Except when
   a DSN is issued by the sender's MTA, an MTA MUST NOT supply thi