RFC 1894 (rfc1894) - Page 2 of 39
An Extensible Message Format for Delivery Status Notifications
Alternative Format: Original Text Document
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