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



