An Extensible Message Format for Delivery Status Notifications
RFC 1894

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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.