Network Working Group K. Moore
Request for Comments: 3464 University of Tennessee
Obsoletes: 1894 G. Vaudreuil
Category: Standards Track Lucent Technologies
January 2003
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo defines a Multipurpose Internet Mail Extensions (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 "Local Area Network
(LAN)-based" systems), the Delivery Status Notification (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.
Moore & Vaudreuil Standards Track [Page 1]
RFC 3464 Delivery Status Notifications January 2003
Table of Contents
1. Introduction ....................................................3
1.1 Purposes .....................................................3
1.2 Requirements .................................................4
1.3 Terminology ..................................................5
2. Format of a Delivery Status Notification ........................7
2.1 The message/delivery-status content-type .....................9
2.1.1 General conventions for DSN fields ........................9
2.1.2 "*-type" sub-fields .......................................9
2.1.3 Lexical tokens imported from RFC 822 .....................10
2.2 Per-Message DSN Fields ......................................11
2.2.1 The Original-Envelope-Id field ...........................11
2.2.2 The Reporting-MTA DSN field ..............................12
2.2.3 The DSN-Gateway field ....................................13
2.2.4 The Received-From-MTA DSN field ..........................14
2.2.5 The Arrival-Date DSN field ...............................14
2.3 Per-Recipient DSN fields ....................................14
2.3.1 Original-Recipient field .................................15
2.3.2 Final-Recipient field ....................................15
2.3.3 Action field .............................................16
2.3.4 Status field .............................................18
2.3.5 Remote-MTA field .........................................19
2.3.6 Diagnostic-Code field ....................................19
2.3.7 Last-Attempt-Date field ..................................20
2.3.8 final-log-id field .......................................20
2.3.9 Will-Retry-Until field ...................................20
2.4 Extension fields ............................................21
3. Conformance and Usage Requirements .............................22
4. Security Considerations ........................................23
4.1 Forgery .....................................................23
4.2 Confidentiality .............................................23
4.3 Non-Repudiation .............................................25
5. References .....................................................25
6. Acknowledgments ................................................26
Appendix A - Collected Grammar ....................................27
Appendix B - Guidelines for Gatewaying DSNS .......................29
Gatewaying from other mail systems to DSNs ......................29
Gatewaying from DSNs to other mail systems ......................30
Appendix C - Guidelines for Use of DSNS By Mailing List Exploders .30
Appendix D - IANA Registration Forms for DSN Types ................31
IANA registration form for address-type .........................32
IANA registration form for diagnostic-type ......................32
IANA registration form for MTA-name-type ........................32
Appendix E - Examples .............................................33
Simple DSN ......................................................34
Multi-Recipient DSN .............................................35
DSN from gateway to foreign system ..............................36
Moore & Vaudreuil Standards Track [Page 2]
RFC 3464 Delivery Status Notifications January 2003
Delayed DSN .....................................................37
Appendix F - Changes from RFC 1894 ................................38
Authors' Addresses ................................................39
Full Copyright Statement ..........................................40
1. Introduction
This memo defines a Multipurpose Internet Mail Extensions (MIME)
[MIME1] 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 [REPORT].
This memo defines only the format of the notifications. An extension
to the Simple Message Transfer Protocol (SMTP) [SMTP] to fully
support such notifications is the subject of a separate memo [DRPT].
Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
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 that is largely independent of human
language and media;
(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;
Moore & Vaudreuil Standards Track [Page 3]
RFC 3464 Delivery Status Notifications January 2003
(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 and medium-independent, yet reasonably
precise, indications of the reason for the failure of a message
to be delivered; 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 sender wants to report the problem to the remote MTA
administrator.
1.2 Requirements
These purposes place the following constraints on the notification
protocol:
(a) It must be readable by humans as well as being machine-parsable.
(b) It must provide enough information to allow message senders (or
the user agents) to unambiguously associate a DSN with the
message that was sent and the original recipient address for
which the DSN is issued (if such information is available), even
if the message was forwarded to another recipient address.
(c) It must be able to preserve the reason for the success or failure
of a delivery attempt in a remote messaging system, using the
"language" (mailbox addresses and status codes) of that remote
system.
(d) It must also be able to describe the reason for the success or
failure of a delivery attempt, independent of any particular
human language or of the "language" of any particular mail
system.
(e) It must preserve enough information to allow the maintainer of a
remote MTA to understand (and if possible, reproduce) the
conditions that caused a delivery failure at that MTA.
(f) For any notifications issued by foreign mail systems, which are
translated by a mail gateway to the DSN format, the DSN must
preserve the "type" of the foreign addresses and error codes, so
that these may be correctly interpreted by gateways.
Moore & Vaudreuil Standards Track [Page 4]
RFC 3464 Delivery Status Notifications January 2003
A DSN contains a set of per-message fields that identify the message
and the transaction during which the message was submitted, along
with other fields that apply to all delivery attempts described by
the DSN. The DSN also includes a set of per-recipient fields to
convey the result of the attempt to deliver the message to each of
one or more recipients.
1.3 Terminology
A message may be transmitted through several message transfer agents
(MTAs) on its way to a recipient. For a variety of reasons,
recipient addresses may be rewritten during this process, so each MTA
may potentially see a different recipient address. Depending on the
purpose for which a DSN is used, different formats of a particular
recipient address will be needed.
Several DSN fields are defined in terms of the view from a particular
MTA in the transmission. The MTAs are assigned the following names:
(a) Original MTA
The Original MTA is the one to which the message is submitted for
delivery by the sender of the message.
(b) Reporting MTA
For any DSN, the Reporting MTA is the one which is reporting the
results of delivery attempts described in the DSN.
If the delivery attempts described occurred in a "foreign" (non-
Internet) mail system, and the DSN was produced by translating
the foreign notice into DSN format, the Reporting MTA will still
identify the "foreign" MTA where the delivery attempts occurred.
(c) Received-From MTA
The Received-From MTA is the MTA from which the Reporting MTA
received the message, and accepted responsibility for delivery of
the message.
(d) Remote MTA
If an MTA determines that it must relay a message to one or more
recipients, but the message cannot be transferred to its "next
hop" MTA, or if the "next hop" MTA refuses to accept
responsibility for delivery of the message to one or more of its
intended recipients, the relaying MTA may need to issue a DSN on
behalf of the recipients for whom the message cannot be
Moore & Vaudreuil Standards Track [Page 5]
RFC 3464 Delivery Status Notifications January 2003
delivered. In this case the relaying MTA is the Reporting MTA,
and the "next hop" MTA is known as the Remote MTA.
Figure 1 illustrates the relationship between the various MTAs.
+-----+ +--------+ +---------+ +---------+ +------+
| | | | |Received-| | | | |
| | => |Original| => ... => | From | => |Reporting| ===> |Remote|
| user| | MTA | | MTA | | MTA |