An Extensible Message Format for Delivery Status Notifications
RFC 1894
Document | Type |
RFC - Proposed Standard
(January 1996; Errata)
Obsoleted by RFC 3464
Updated by RFC 2852
|
|
---|---|---|---|
Authors | Gregory Vaudreuil , Keith Moore | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1894 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text