SMTP Service Extension for Delivery Status Notifications
RFC 1891

Document Type RFC - Proposed Standard (January 1996; Errata)
Obsoleted by RFC 3461
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1891 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           K. Moore
Request for Comments: 1891                       University of Tennessee
Category: Standards Track                                   January 1996

                         SMTP Service Extension
                   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.

1. Abstract

   This memo defines an extension to the SMTP service, which allows an
   SMTP client to specify (a) that delivery status notifications (DSNs)
   should be generated under certain conditions, (b) whether such
   notifications should return the contents of the message, and (c)
   additional information, to be returned with a DSN, that allows the
   sender to identify both the recipient(s) for which the DSN was
   issued, and the transaction in which the original message was sent.

   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
   <>.  Requests to subscribe to the mailing
   list should be addressed to <>.
   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
   experience, and are thus subject to change.

2. Introduction

   The SMTP protocol [1] requires that an SMTP server provide
   notification of delivery failure, if it determines that a message
   cannot be delivered to one or more recipients.  Traditionally, such
   notification consists of an ordinary Internet mail message (format
   defined by [2]), sent to the envelope sender address (the argument of

Moore                       Standards Track                     [Page 1]
RFC 1891           SMTP Delivery Status Notifications       January 1996

   the SMTP MAIL command), containing an explanation of the error and at
   least the headers of the failed message.

   Experience with large mail distribution lists [3] indicates that such
   messages are often insufficient to diagnose problems, or even to
   determine at which host or for which recipients a problem occurred.
   In addition, the lack of a standardized format for delivery
   notifications in Internet mail makes it difficult to exchange such
   notifications with other message handling systems.

   Such experience has demonstrated a need for a delivery status
   notification service for Internet electronic mail, which:

(a) is reliable, in the sense that any DSN request will either be
    honored at the time of final delivery, or result in a response
    that indicates that the request cannot be honored,

(b) when both success and failure notifications are requested,
    provides an unambiguous and nonconflicting indication of whether
    delivery of a message to a recipient succeeded or failed,

(c) is stable, in that a failed attempt to deliver a DSN should never
    result in the transmission of another DSN over the network,

(d) preserves sufficient information to allow the sender to identify
    both the mail transaction and the recipient address which caused
    the notification, even when mail is forwarded or gatewayed to
    foreign environments, and

(e) interfaces acceptably with non-SMTP and non-822-based mail
    systems, both so that notifications returned from foreign mail
    systems may be useful to Internet users, and so that the
    notification requests from foreign environments may be honored.
    Among the requirements implied by this goal are the ability to
    request non-return-of-content, and the ability to specify whether
    positive delivery notifications, negative delivery notifications,
    both, or neither, should be issued.

   In an attempt to provide such a service, this memo uses the mechanism
   defined in [4] to define an extension to the SMTP protocol.  Using
   this mechanism, an SMTP client may request that an SMTP server issue
   or not issue a delivery status notification (DSN) under certain
   conditions.  The format of a DSN is defined in [5].

Moore                       Standards Track                     [Page 2]
RFC 1891           SMTP Delivery Status Notifications       January 1996

3. Framework for the Delivery Status Notification Extension
Show full document text