summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1894.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1894.txt')
-rw-r--r--doc/rfc/rfc1894.txt2187
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc1894.txt b/doc/rfc/rfc1894.txt
new file mode 100644
index 0000000..f1fc90d
--- /dev/null
+++ b/doc/rfc/rfc1894.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+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.
+
+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.
+
+ A DSN contains a set of per-message fields which 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.
+
+
+
+Moore & Vaudreuil Standards Track [Page 3]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ 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 delivered. In this case the relaying
+ MTA is the Reporting MTA, and the "next hop" MTA is known as the
+ Remote MTA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 4]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+Figure 1 illustrates the relationship between the various MTAs.
+
+
++-----+ +--------+ +---------+ +---------+ +------+
+| | | | |Received-| | | | |
+| | => |Original| => ... => | From | => |Reporting| ===> |Remote|
+| user| | MTA | | MTA | | MTA | <No! | MTA |
+|agent| +--------+ +---------+ +----v----+ +------+
+| | |
+| | <-------------------------------------------+
++-----+ (DSN returned to sender by Reporting MTA)
+
+
+ Figure 1. Original, Received-From, Reporting and Remote MTAs
+
+
+ Each of these MTAs may provide information which is useful in a DSN:
+
++ Ideally, the DSN will contain the address of each recipient as
+ originally specified to the Original MTA by the sender of the message.
+ This version of the address is needed (rather than a forwarding
+ address or some modified version of the original address) so that the
+ sender may compare the recipient address in the DSN with the address
+ in the sender's records (e.g. an address book for an individual, the
+ list of subscribers for a mailing list) and take appropriate action.
+
+ Similarly, the DSN might contain an "envelope identifier" that was
+ known to both the sender's user agent and the Original MTA at the time
+ of message submission, and which, if included in the DSN, can be used
+ by the sender to keep track of which messages were or were not
+ delivered.
+
++ If a message was (a) forwarded to a different address than that
+ specified by the sender, (b) gatewayed to a different mail system than
+ that used by the sender, or (c) subjected to address rewriting during
+ transmission, the "final" form of the recipient address (i.e. the one
+ seen by the Reporting MTA) will be different than the original
+ (sender-specified) recipient address. Just as the sender's user agent
+ (or the sender) prefers the original recipient address, so the "final"
+ address is needed when reporting a problem to the postmaster of the
+ site where message delivery failed, because only the final recipient
+ address will allow her to reproduce the conditions that caused the
+ failure.
+
++ A "failed" DSN should contain the most accurate explanation for the
+ delivery failure that is available. For ease of interpretation, this
+ information should be a format which is independent of the mail
+ transport system that issued the DSN. However, if a foreign error
+
+
+
+Moore & Vaudreuil Standards Track [Page 5]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ code is translated into some transport-independent format, some
+ information may be lost. It is therefore desirable to provide both a
+ transport-independent status code and a mechanism for reporting
+ transport-specific codes. Depending on the circumstances that
+ produced delivery failure, the transport-specific code might be
+ obtained from either the Reporting MTA or the Remote MTA.
+
+ Since different values for "recipient address" and "delivery status
+ code" are needed according to the circumstance in which a DSN will be
+ used, and since the MTA that issues the DSN cannot anticipate those
+ circumstances, the DSN format described here may contain both the
+ original and final forms of a recipient address, and both a
+ transport-independent and a transport-specific indication of delivery
+ status.
+
+ Extension fields may also be added by the Reporting MTA as needed to
+ provide additional information for use in a trouble ticket or to
+ preserve information for tunneling of foreign delivery reports
+ through Internet DSNs.
+
+ The Original, Reporting, and Remote MTAs may exist in very different
+ environments and use dissimilar transport protocols, MTA names,
+ address formats, and delivery status codes. DSNs therefore do not
+ assume any particular format for mailbox addresses, MTA names, or
+ transport-specific status codes. Instead, the various DSN fields
+ that carry such quantities consist of a "type" subfield followed by a
+ subfield whose contents are ordinary text characters, and the format
+ of which is indicated by the "type" subfield. This allows a DSN to
+ convey these quantities regardless of format.
+
+2. Format of a Delivery Status Notification
+
+ A DSN is a MIME message with a top-level content-type of
+ multipart/report (defined in [2]). When a multipart/report content
+ is used to transmit a DSN:
+
+(a) The report-type parameter of the multipart/report content is
+ "delivery-status".
+
+(b) The first component of the multipart/report contains a human-
+ readable explanation of the DSN, as described in [2].
+
+(c) The second component of the multipart/report is of content-type
+ message/delivery-status, described in section 2.1 of this document.
+
+(d) If the original message or a portion of the message is to be
+ returned to the sender, it appears as the third component of the
+ multipart/report.
+
+
+
+Moore & Vaudreuil Standards Track [Page 6]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ NOTE: For delivery status notifications gatewayed from foreign
+ systems, the headers of the original message may not be available.
+ In this case the third component of the DSN may be omitted, or it
+ may contain "simulated" RFC 822 headers which contain equivalent
+ information. In particular, it is very desirable to preserve the
+ subject, date, and message-id (or equivalent) fields from the
+ original message.
+
+ The DSN MUST be addressed (in both the message header and the
+ transport envelope) to the return address from the transport envelope
+ which accompanied the original message for which the DSN was
+ generated. (For a message that arrived via SMTP, the envelope return
+ address appears in the MAIL FROM command.)
+
+ The From field of the message header of the DSN SHOULD contain the
+ address of a human who is responsible for maintaining the mail system
+ at the Reporting MTA site (e.g. Postmaster), so that a reply to the
+ DSN will reach that person. Exception: if a DSN is translated from a
+ foreign delivery report, and the gateway performing the translation
+ cannot determine the appropriate address, the From field of the DSN
+ MAY be the address of a human who is responsible for maintaining the
+ gateway.
+
+ The envelope sender address of the DSN SHOULD be chosen to ensure
+ that no delivery status reports will be issued in response to the DSN
+ itself, and MUST be chosen so that DSNs will not generate mail loops.
+ Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
+ command MUST use a NULL return address, i.e. "MAIL FROM:<>".
+
+ A particular DSN describes the delivery status for exactly one
+ message. However, an MTA MAY report on the delivery status for
+ several recipients of the same message in a single DSN. Due to the
+ nature of the mail transport system (where responsibility for
+ delivery of a message to its recipients may be split among several
+ MTAs, and delivery to any particular recipient may be delayed),
+ multiple DSNs may be still be issued in response to a single message
+ submission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 7]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+2.1 The message/delivery-status content-type
+
+ The message/delivery-status content-type is defined as follows:
+
+ MIME type name: message
+ MIME subtype name: delivery-status
+ Optional parameters: none
+ Encoding considerations: "7bit" encoding is sufficient and
+ MUST be used to maintain readability
+ when viewed by non-MIME mail
+ readers.
+ Security considerations: discussed in section 4 of this memo.
+
+ The message/delivery-status report type for use in the
+ multipart/report is "delivery-status".
+
+ The body of a message/delivery-status consists of one or more
+ "fields" formatted according to the ABNF of RFC 822 header "fields"
+ (see [6]). The per-message fields appear first, followed by a blank
+ line. Following the per-message fields are one or more groups of
+ per-recipient fields. Each group of per-recipient fields is preceded
+ by a blank line. Using the ABNF of RFC 822, the syntax of the
+ message/delivery-status content is as follows:
+
+ delivery-status-content =
+ per-message-fields 1*( CRLF per-recipient-fields )
+
+ The per-message fields are described in section 2.2. The per-
+ recipient fields are described in section 2.3.
+
+
+2.1.1 General conventions for DSN fields
+
+ Since these fields are defined according to the rules of RFC 822, the
+ same conventions for continuation lines and comments apply.
+ Notification fields may be continued onto multiple lines by beginning
+ each additional line with a SPACE or HTAB. Text which appears in
+ parentheses is considered a comment and not part of the contents of
+ that notification field. Field names are case-insensitive, so the
+ names of notification fields may be spelled in any combination of
+ upper and lower case letters. Comments in DSN fields may use the
+ "encoded-word" construct defined in [7].
+
+ A number of DSN fields are defined to have a portion of a field body
+ of "xtext". "xtext" is used to allow encoding sequences of octets
+ which contain values outside the range [1-127 decimal] of traditional
+ ASCII characters, and also to allow comments to be inserted in the
+ data. Any octet may be encoded as "+" followed by two upper case
+
+
+
+Moore & Vaudreuil Standards Track [Page 8]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ hexadecimal digits. (The "+" character MUST be encoded as "+2B".)
+ With certain exceptions, octets that correspond to ASCII characters
+ may be represented as themselves. SPACE and HTAB characters are
+ ignored. Comments may be included by enclosing them in parenthesis.
+ Except within comments, encoded-words such as defined in [7] may NOT
+ be used in xtext.
+
+ "xtext" is formally defined as follows:
+
+ xtext = *( xchar / hexchar / linear-white-space / comment )
+
+ xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
+ except for "+", "\" and "(".
+
+ "hexchar"s are intended to encode octets that cannot be represented
+ as plain text, either because they are reserved, or because they are
+ non-printable. However, any octet value may be represented by a
+ "hexchar".
+
+ hexchar = ASCII "+" immediately followed by two upper case
+ hexadecimal digits
+
+ When encoding an octet sequence as xtext:
+
+ + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\",
+ and "(", MAY be encoded as itself. (Some CHARs in this range may
+ also be encoded as "hexchar"s, at the implementor's discretion.)
+
+ + ASCII CHARs that fall outside the range above must be encoded as
+ "hexchar".
+
+ + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line
+ lengths from becoming excessive.
+
+ + Comments MAY be added to clarify the meaning for human readers.
+
+2.1.2 "*-type" subfields
+
+ Several DSN fields consist of a "-type" subfield, followed by a
+ semicolon, followed by "*text". For these fields, the keyword used
+ in the address-type, diagnostic-type, or MTA-name-type subfield
+ indicates the expected format of the address, status-code, or MTA-
+ name which follows.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 9]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ The "-type" subfields are defined as follows:
+
+(a) An "address-type" specifies the format of a mailbox address. For
+ example, Internet mail addresses use the "rfc822" address-type.
+
+ address-type = atom
+
+(b) A "diagnostic-type" specifies the format of a status code. For
+ example, when a DSN field contains a reply code reported via the
+ Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is
+ used.
+
+ diagnostic-type = atom
+
+(c) An "MTA-name-type" specifies the format of an MTA name. For
+ example, for an SMTP server on an Internet host, the MTA name is the
+ domain name of that host, and the "dns" MTA-name-type is used.
+
+ mta-name-type = atom
+
+ Values for address-type, diagnostic-type, and MTA-name-type are
+ case-insensitive. Thus address-type values of "RFC822" and "rfc822"
+ are equivalent.
+
+ The Internet Assigned Numbers Authority (IANA) will maintain a
+ registry of address-types, diagnostic-types, and MTA-name-types,
+ along with descriptions of the meanings and acceptable values of
+ each, or a reference to a one or more specifications that provide
+ such descriptions. (The "rfc822" address-type, "smtp" diagnostic-
+ type, and "dns" MTA-name-type are defined in [4].) Registration
+ forms for address-type, diagnostic-type, and MTA-name-type appear in
+ section 8 of this document.
+
+ IANA will not accept registrations for any address-type, diagnostic-
+ type, or MTA-name-type name that begins with "X-". These type names
+ are reserved for experimental use.
+
+2.1.3 Lexical tokens imported from RFC 822
+
+ The following lexical tokens, defined in [6], are used in the ABNF
+ grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-
+ white-space, SPACE, text. The date-time lexical token is defined in
+ [8].
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 10]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+2.2 Per-Message DSN Fields
+
+ Some fields of a DSN apply to all of the delivery attempts described
+ by that DSN. These fields may appear at most once in any DSN. These
+ fields are used to correlate the DSN with the original message
+ transaction and to provide additional information which may be useful
+ to gateways.
+
+ per-message-fields =
+ [ original-envelope-id-field CRLF ]
+ reporting-mta-field CRLF
+ [ dsn-gateway-field CRLF ]
+ [ received-from-mta-field CRLF ]
+ [ arrival-date-field CRLF ]
+ *( extension-field CRLF )
+
+2.2.1 The Original-Envelope-Id field
+
+ The optional Original-Envelope-Id field contains an "envelope
+ identifier" which uniquely identifies the transaction during which
+ the message was submitted, and was either (a) specified by the sender
+ and supplied to the sender's MTA, or (b) generated by the sender's
+ MTA and made available to the sender when the message was submitted.
+ Its purpose is to allow the sender (or her user agent) to associate
+ the returned DSN with the specific transaction in which the message
+ was sent.
+
+ If such an envelope identifier was present in the envelope which
+ accompanied the message when it arrived at the Reporting MTA, it
+ SHOULD be supplied in the Original-Envelope-Id field of any DSNs
+ issued as a result of an attempt to deliver the message. Except when
+ a DSN is issued by the sender's MTA, an MTA MUST NOT supply this
+ field unless there is an envelope-identifier field in the envelope
+ which accompanied this message on its arrival at the Reporting MTA.
+
+ The Original-Envelope-Id field is defined as follows:
+
+ original-envelope-id-field =
+ "Original-Envelope-Id" ":" envelope-id
+
+ envelope-id = *text
+
+ There may be at most one Original-Envelope-Id field per DSN.
+
+ The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the
+ original case and spelling of the envelope-id.
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 11]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from
+ the message header. The Message-Id identifies the content of the
+ message, while the Original-Envelope-Id identifies the transaction in
+ which the message is sent.
+
+2.2.2 The Reporting-MTA DSN field
+
+ reporting-mta-field =
+ "Reporting-MTA" ":" mta-name-type ";" mta-name
+
+ mta-name = *text
+
+ The Reporting-MTA field is defined as follows:
+
+ A DSN describes the results of attempts to deliver, relay, or gateway
+ a message to one or more recipients. In all cases, the Reporting-MTA
+ is the MTA which attempted to perform the delivery, relay, or gateway
+ operation described in the DSN. This field is required.
+
+ Note that if an SMTP client attempts to relay a message to an SMTP
+ server and receives an error reply to a RCPT command, the client is
+ responsible for generating the DSN, and the client's domain name will
+ appear in the Reporting-MTA field. (The server's domain name will
+ appear in the Remote-MTA field.)
+
+ Note that the Reporting-MTA is not necessarily the MTA which actually
+ issued the DSN. For example, if an attempt to deliver a message
+ outside of the Internet resulted in a nondelivery notification which
+ was gatewayed back into Internet mail, the Reporting-MTA field of the
+ resulting DSN would be that of the MTA that originally reported the
+ delivery failure, not that of the gateway which converted the foreign
+ notification into a DSN. See Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 12]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+sender's environment recipient's environment
+............................ ..........................................
+ : :
+ (1) : : (2)
+ +-----+ +--------+ +--------+ +---------+ +---------+ +------+
+ | | | | | | |Received-| | | | |
+ | |=>|Original|=>| |->| From |->|Reporting|-->|Remote|
+ | user| | MTA | | | | MTA | | MTA |<No| MTA |
+ |agent| +--------+ |Gateway | +---------+ +----v----+ +------+
+ | | | | |
+ | | <============| |<-------------------+
+ +-----+ | |(4) (3)
+ +--------+
+ : :
+...........................: :.........................................
+
+ Figure 2. DSNs in the presence of gateways
+
+ (1) message is gatewayed into recipient's environment
+ (2) attempt to relay message fails
+ (3) reporting-mta (in recipient's environment) returns nondelivery
+ notification
+ (4) gateway translates foreign notification into a DSN
+
+
+
+ The mta-name portion of the Reporting-MTA field is formatted
+ according to the conventions indicated by the mta-name-type subfield.
+ If an MTA functions as a gateway between dissimilar mail environments
+ and thus is known by multiple names depending on the environment, the
+ mta-name subfield SHOULD contain the name used by the environment
+ from which the message was accepted by the Reporting-MTA.
+
+ Because the exact spelling of an MTA name may be significant in a
+ particular environment, MTA names are CASE-SENSITIVE.
+
+2.2.3 The DSN-Gateway field
+
+ The DSN-Gateway field indicates the name of the gateway or MTA which
+ translated a foreign (non-Internet) delivery status notification into
+ this DSN. This field MUST appear in any DSN which was translated by
+ a gateway from a foreign system into DSN format, and MUST NOT appear
+ otherwise.
+
+ dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 13]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ For gateways into Internet mail, the MTA-name-type will normally be
+ "smtp", and the mta-name will be the Internet domain name of the
+ gateway.
+
+2.2.4 The Received-From-MTA DSN field
+
+ The optional Received-From-MTA field indicates the name of the MTA
+ from which the message was received.
+
+ received-from-mta-field =
+ "Received-From-MTA" ":" mta-name-type ";" mta-name
+
+ If the message was received from an Internet host via SMTP, the
+ contents of the mta-name subfield SHOULD be the Internet domain name
+ supplied in the HELO or EHLO command, and the network address used by
+ the SMTP client SHOULD be included as a comment enclosed in
+ parentheses. (In this case, the MTA-name-type will be "smtp".)
+
+ The mta-name portion of the Received-From-MTA field is formatted
+ according to the conventions indicated by the MTA-name-type subfield.
+
+ Since case is significant in some mail systems, the exact spelling,
+ including case, of the MTA name SHOULD be preserved.
+
+2.2.5 The Arrival-Date DSN field
+
+ The optional Arrival-Date field indicates the date and time at which
+ the message arrived at the Reporting MTA. If the Last-Attempt-Date
+ field is also provided in a per-recipient field, this can be used to
+ determine the interval between when the message arrived at the
+ Reporting MTA and when the report was issued for that recipient.
+
+ arrival-date-field = "Arrival-Date" ":" date-time
+
+ The date and time are expressed in RFC 822 'date-time' format, as
+ modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
+
+2.3 Per-Recipient DSN fields
+
+ A DSN contains information about attempts to deliver a message to one
+ or more recipients. The delivery information for any particular
+ recipient is contained in a group of contiguous per-recipient fields.
+ Each group of per-recipient fields is preceded by a blank line.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 14]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ The syntax for the group of per-recipient fields is as follows:
+
+
+ per-recipient-fields =
+ [ original-recipient-field CRLF ]
+ final-recipient-field CRLF
+ action-field CRLF
+ status-field CRLF
+ [ remote-mta-field CRLF ]
+ [ diagnostic-code-field CRLF ]
+ [ last-attempt-date-field CRLF ]
+ [ will-retry-until-field CRLF ]
+ *( extension-field CRLF )
+
+2.3.1 Original-Recipient field
+
+ The Original-Recipient field indicates the original recipient address
+ as specified by the sender of the message for which the DSN is being
+ issued.
+
+ original-recipient-field =
+ "Original-Recipient" ":" address-type ";" generic-address
+
+ generic-address = *text
+
+ The address-type field indicates the type of the original recipient
+ address. If the message originated within the Internet, the
+ address-type field field will normally be "rfc822", and the address
+ will be according to the syntax specified in [6]. The value
+ "unknown" should be used if the Reporting MTA cannot determine the
+ type of the original recipient address from the message envelope.
+
+ This field is optional. It should be included only if the sender-
+ specified recipient address was present in the message envelope, such
+ as by the SMTP extensions defined in [4]. This address is the same
+ as that provided by the sender and can be used to automatically
+ correlate DSN reports and message transactions.
+
+2.3.2 Final-Recipient field
+
+ The Final-Recipient field indicates the recipient for which this set
+ of per-recipient fields applies. This field MUST be present in each
+ set of per-recipient data.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 15]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ The syntax of the field is as follows:
+
+ final-recipient-field =
+ "Final-Recipient" ":" address-type ";" generic-address
+
+ The generic-address subfield of the Final-Recipient field MUST
+ contain the mailbox address of the recipient (from the transport
+ envelope) as it was when the message was accepted for delivery by the
+ Reporting MTA.
+
+ The Final-Recipient address may differ from the address originally
+ provided by the sender, because it may have been transformed during
+ forwarding and gatewaying into an totally unrecognizable mess.
+ However, in the absence of the optional Original-Recipient field, the
+ Final-Recipient field and any returned content may be the only
+ information available with which to correlate the DSN with a
+ particular message submission.
+
+ The address-type subfield indicates the type of address expected by
+ the reporting MTA in that context. Recipient addresses obtained via
+ SMTP will normally be of address-type "rfc822".
+
+ NOTE: The Reporting MTA is not expected to ensure that the address
+ actually conforms to the syntax conventions of the address-type.
+ Instead, it MUST report exactly the address received in the envelope,
+ unless that address contains characters such as CR or LF which may
+ not appear in a DSN field.
+
+ Since mailbox addresses (including those used in the Internet) may be
+ case sensitive, the case of alphabetic characters in the address MUST
+ be preserved.
+
+2.3.3 Action field
+
+ The Action field indicates the action performed by the Reporting-MTA
+ as a result of its attempt to deliver the message to this recipient
+ address. This field MUST be present for each recipient named in the
+ DSN.
+
+ The syntax for the action-field is:
+
+ action-field = "Action" ":" action-value
+
+ action-value =
+ "failed" / "delayed" / "delivered" / "relayed" / "expanded"
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 16]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ The action-value may be spelled in any combination of upper and lower
+ case characters.
+
+"failed" indicates that the message could not be delivered to the
+ recipient. The Reporting MTA has abandoned any attempts to
+ deliver the message to this recipient. No further
+ notifications should be expected.
+
+"delayed" indicates that the Reporting MTA has so far been unable to
+ deliver or relay the message, but it will continue to
+ attempt to do so. Additional notification messages may be
+ issued as the message is further delayed or successfully
+ delivered, or if delivery attempts are later abandoned.
+
+"delivered" indicates that the message was successfully delivered to
+ the recipient address specified by the sender, which
+ includes "delivery" to a mailing list exploder. It does
+ not indicate that the message has been read. This is a
+ terminal state and no further DSN for this recipient should
+ be expected.
+
+"relayed" indicates that the message has been relayed or gatewayed
+ into an environment that does not accept responsibility for
+ generating DSNs upon successful delivery. This action-
+ value SHOULD NOT be used unless the sender has requested
+ notification of successful delivery for this recipient.
+
+"expanded" indicates that the message has been successfully delivered
+ to the recipient address as specified by the sender, and
+ forwarded by the Reporting-MTA beyond that destination to
+ multiple additional recipient addresses. An action-value
+ of "expanded" differs from "delivered" in that "expanded"
+ is not a terminal state. Further "failed" and/or "delayed"
+ notifications may be provided.
+
+ Using the terms "mailing list" and "alias" as defined in
+ [4], section 7.2.7: An action-value of "expanded" is only
+ to be used when the message is delivered to a multiple-
+ recipient "alias". An action-value of "expanded" SHOULD
+ NOT be used with a DSN issued on delivery of a message to a
+ "mailing list".
+
+ NOTE ON ACTION VS. STATUS CODES: Although the 'action' field might
+ seem to be redundant with the 'status' field, this is not the case.
+ In particular, a "temporary failure" ("4") status code could be used
+ with an action-value of either "delayed" or "failed". For example,
+ assume that an SMTP client repeatedly tries to relay a message to the
+ mail exchanger for a recipient, but fails because a query to a domain
+
+
+
+Moore & Vaudreuil Standards Track [Page 17]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ name server timed out. After a few hours, it might issue a "delayed"
+ DSN to inform the sender that the message had not yet been delivered.
+ After a few days, the MTA might abandon its attempt to deliver the
+ message and return a "failed" DSN. The status code (which would
+ begin with a "4" to indicate "temporary failure") would be the same
+ for both DSNs.
+
+ Another example for which the action and status codes may appear
+ contradictory: If an MTA or mail gateway cannot deliver a message
+ because doing so would entail conversions resulting in an
+ unacceptable loss of information, it would issue a DSN with the
+ 'action' field of "failure" and a status code of 'XXX'. If the
+ message had instead been relayed, but with some loss of information,
+ it might generate a DSN with the same XXX status-code, but with an
+ action field of "relayed".
+
+2.3.4 Status field
+
+ The per-recipient Status field contains a transport-independent
+ status code which indicates the delivery status of the message to
+ that recipient. This field MUST be present for each delivery attempt
+ which is described by a DSN.
+
+ The syntax of the status field is:
+
+ status-field = "Status" ":" status-code
+
+ status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+ ; White-space characters and comments are NOT allowed within a
+ ; status-code, though a comment enclosed in parentheses MAY follow
+ ; the last numeric subfield of the status-code. Each numeric
+ ; subfield within the status-code MUST be expressed without
+ ; leading zero digits.
+
+ Status codes thus consist of three numerical fields separated by ".".
+ The first sub-field indicates whether the delivery attempt was
+ successful (2 = success, 4 = persistent temporary failure, 5 =
+ permanent failure). The second sub-field indicates the probable
+ source of any delivery anomalies, and the third sub-field denotes a
+ precise error condition, if known.
+
+ The initial set of status-codes is defined in [5].
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 18]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+2.3.5 Remote-MTA field
+
+ The value associated with the Remote-MTA DSN field is a printable
+ ASCII representation of the name of the "remote" MTA that reported
+ delivery status to the "reporting" MTA.
+
+ remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
+
+ NOTE: The Remote-MTA field preserves the "while talking to"
+ information that was provided in some pre-existing nondelivery
+ reports.
+
+ This field is optional. It MUST NOT be included if no remote MTA was
+ involved in the attempted delivery of the message to that recipient.
+
+2.3.6 Diagnostic-Code field
+
+ For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
+ contains the actual diagnostic code issued by the mail transport.
+ Since such codes vary from one mail transport to another, the
+ diagnostic-type subfield is needed to specify which type of
+ diagnostic code is represented.
+
+ diagnostic-code-field =
+ "Diagnostic-Code" ":" diagnostic-type ";" *text
+
+ NOTE: The information in the Diagnostic-Code field may be somewhat
+ redundant with that from the Status field. The Status field is
+ needed so that any DSN, regardless of origin, may be understood by
+ any user agent or gateway that parses DSNs. Since the Status code
+ will sometimes be less precise than the actual transport diagnostic
+ code, the Diagnostic-Code field is provided to retain the latter
+ information. Such information may be useful in a trouble ticket sent
+ to the administrator of the Reporting MTA, or when tunneling foreign
+ nondelivery reports through DSNs.
+
+ If the Diagnostic Code was obtained from a Remote MTA during an
+ attempt to relay the message to that MTA, the Remote-MTA field should
+ be present. When interpreting a DSN, the presence of a Remote-MTA
+ field indicates that the Diagnostic Code was issued by the Remote
+ MTA. The absence of a Remote-MTA indicates that the Diagnostic Code
+ was issued by the Reporting MTA.
+
+ In addition to the Diagnostic-Code itself, additional textual
+ description of the diagnostic, MAY appear in a comment enclosed in
+ parentheses.
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 19]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ This field is optional, because some mail systems supply no
+ additional information beyond that which is returned in the 'action'
+ and 'status' fields. However, this field SHOULD be included if
+ transport-specific diagnostic information is available.
+
+2.3.7 Last-Attempt-Date field
+
+ The Last-Attempt-Date field gives the date and time of the last
+ attempt to relay, gateway, or deliver the message (whether successful
+ or unsuccessful) by the Reporting MTA. This is not necessarily the
+ same as the value of the Date field from the header of the message
+ used to transmit this delivery status notification: In cases where
+ the DSN was generated by a gateway, the Date field in the message
+ header contains the time the DSN was sent by the gateway and the DSN
+ Last-Attempt-Date field contains the time the last delivery attempt
+ occurred.
+
+ last-attempt-date-field = "Last-Attempt-Date" ":" date-time
+
+ This field is optional. It MUST NOT be included if the actual date
+ and time of the last delivery attempt are not available (which might
+ be the case if the DSN were being issued by a gateway).
+
+ The date and time are expressed in RFC 822 'date-time' format, as
+ modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
+
+ 3.2.1.5 final-log-id field
+
+ The "final-log-id" field gives the final-log-id of the message that
+ was used by the final-mta. This can be useful as an index to the
+ final-mta's log entry for that delivery attempt.
+
+ final-log-id-field = "Final-Log-ID" ":" *text
+
+ This field is optional.
+
+2.3.8 Will-Retry-Until field
+
+ For DSNs of type "delayed", the Will-Retry-Until field gives the date
+ after which the Reporting MTA expects to abandon all attempts to
+ deliver the message to that recipient. The Will-Retry-Until field is
+ optional for "delay" DSNs, and MUST NOT appear in other DSNs.
+
+ will-retry-until-field = "Will-Retry-Until" ":" date-time
+
+ The date and time are expressed in RFC 822 'date-time' format, as
+ modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 20]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+2.4 Extension fields
+
+ Additional per-message or per-recipient DSN fields may be defined in
+ the future by later revisions or extensions to this specification.
+ Extension-field names beginning with "X-" will never be defined as
+ standard fields; such names are reserved for experimental use. DSN
+ field names NOT beginning with "X-" MUST be registered with the
+ Internet Assigned Numbers Authority (IANA) and published in an RFC.
+
+ Extension DSN fields may be defined for the following reasons:
+
+ (a) To allow additional information from foreign delivery status
+ reports to be tunneled through Internet DSNs. The names of such
+ DSN fields should begin with an indication of the foreign
+ environment name (e.g. X400-Physical-Forwarding-Address).
+
+ (b) To allow the transmission of diagnostic information which is
+ specific to a particular mail transport protocol. The names of
+ such DSN fields should begin with an indication of the mail
+ transport being used (e.g. SMTP-Remote-Recipient-Address). Such
+ fields should be used for diagnostic purposes only and not by
+ user agents or mail gateways.
+
+ (c) To allow transmission of diagnostic information which is specific
+ to a particular message transfer agent (MTA). The names of such
+ DSN fields should begin with an indication of the MTA
+ implementation which produced the DSN. (e.g. Foomail-Queue-ID).
+
+ MTA implementors are encouraged to provide adequate information, via
+ extension fields if necessary, to allow an MTA maintainer to
+ understand the nature of correctable delivery failures and how to fix
+ them. For example, if message delivery attempts are logged, the DSN
+ might include information which allows the MTA maintainer to easily
+ find the log entry for a failed delivery attempt.
+
+ If an MTA developer does not wish to register the meanings of such
+ extension fields, "X-" fields may be used for this purpose. To avoid
+ name collisions, the name of the MTA implementation should follow the
+ "X-", (e.g. "X-Foomail-Log-ID").
+
+3. Conformance and Usage Requirements
+
+ An MTA or gateway conforms to this specification if it generates DSNs
+ according to the protocol defined in this memo. For MTAs and
+ gateways that do not support requests for positive delivery
+ notification (such as in [4]), it is sufficient that delivery failure
+ reports use this protocol.
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 21]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ A minimal implementation of this specification need generate only the
+ Reporting-MTA per-message field, and the Final-Recipient, Action, and
+ Status fields for each attempt to deliver a message to a recipient
+ described by the DSN. Generation of the other fields, when
+ appropriate, is strongly recommended.
+
+ MTAs and gateways MUST NOT generate the Original-Recipient field of a
+ DSN unless the mail transfer protocol provides the address originally
+ specified by the sender at the time of submission. (Ordinary SMTP
+ does not make that guarantee, but the SMTP extension defined in [4]
+ permits such information to be carried in the envelope if it is
+ available.)
+
+ Each sender-specified recipient address SHOULD result in at most one
+ "delivered" or "failed" DSN for that recipient. If a positive DSN is
+ requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient
+ that is forwarded to multiple recipients of an "alias" (as defined in
+ [4], section 7.2.7), the forwarding MTA SHOULD normally issue a
+ "expanded" DSN for the originally-specified recipient and not
+ propagate the request for a DSN to the forwarding addresses.
+ Alternatively, the forwarding MTA MAY relay the request for a DSN to
+ exactly one of the forwarding addresses and not propagate the request
+ to the others.
+
+ By contrast, successful submission of a message to a mailing list
+ exploder is considered final delivery of the message. Upon delivery
+ of a message to a recipient address corresponding to a mailing list
+ exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
+ as if the recipient address were that of an ordinary mailbox.
+
+ NOTE: This is actually intended to make DSNs usable by mailing lists
+ themselves. Any message sent to a mailing list subscriber should
+ have its envelope return address pointing to the list maintainer [see
+ RFC 1123, section 5.3.7(E)]. Since DSNs are sent to the envelope
+ return address, all DSNs resulting from delivery to the recipients of
+ a mailing list will be sent to the list maintainer. The list
+ maintainer may elect to mechanically process DSNs upon receipt, and
+ thus automatically delete invalid addresses from the list. (See
+ section 7 of this memo.)
+
+ This specification places no restrictions on the processing of DSNs
+ received by user agents or distribution lists.
+
+4. Security Considerations
+
+ The following security considerations apply when using DSNs:
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 22]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+4.1 Forgery
+
+ DSNs may be forged as easily as ordinary Internet electronic mail.
+ User agents and automatic mail handling facilities (such as mail
+ distribution list exploders) that wish to make automatic use of DSNs
+ should take appropriate precautions to minimize the potential damage
+ from denial-of-service attacks.
+
+ Security threats related to forged DSNs include the sending of:
+
+(a) A falsified delivery notification when the message is not delivered
+ to the indicated recipient,
+(b) A falsified non-delivery notification when the message was in fact
+ delivered to the indicated recipient,
+(c) A falsified Final-Recipient address,
+(d) A falsified Remote-MTA identification,
+(e) A falsified relay notification when the message is "dead ended".
+(f) Unsolicited DSNs
+
+4.2 Confidentiality
+
+ Another dimension of security is confidentiality. There may be cases
+ in which a message recipient is autoforwarding messages but does not
+ wish to divulge the address to which the messages are autoforwarded.
+ The desire for such confidentiality will probably be heightened as
+ "wireless mailboxes", such as pagers, become more widely used as
+ autoforward addresses.
+
+ MTA authors are encouraged to provide a mechanism which enables the
+ end user to preserve the confidentiality of a forwarding address.
+ Depending on the degree of confidentiality required, and the nature
+ of the environment to which a message were being forwarded, this
+ might be accomplished by one or more of:
+
+(a) issuing a "relayed" DSN (if a positive DSN was requested) when a
+ message is forwarded to a confidential forwarding address, and
+ disabling requests for positive DSNs for the forwarded message,
+
+(b) declaring the message to be delivered, issuing a "delivered" DSN,
+ re-sending the message to the confidential forwarding address, and
+ arranging for no DSNs to be issued for the re-sent message,
+
+(c) omitting "Remote-*" or extension fields of a DSN whenever they would
+ otherwise contain confidential information (such as a confidential
+ forwarding address),
+
+(d) for messages forwarded to a confidential address, setting the
+ envelope return address (e.g. SMTP MAIL FROM address) to the NULL
+
+
+
+Moore & Vaudreuil Standards Track [Page 23]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ reverse-path ("<>") (so that no DSNs would be sent from a downstream
+ MTA to the original sender),
+
+(e) for messages forwarded to a confidential address, disabling delivery
+ notifications for the forwarded message (e.g. if the "next-hop" MTA
+ uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER
+ parameter to the RCPT command), or
+
+(f) when forwarding mail to a confidential address, having the
+ forwarding MTA rewrite the envelope return address for the forwarded
+ message and attempt delivery of that message as if the forwarding
+ MTA were the originator. On its receipt of final delivery status,
+ the forwarding MTA would issue a DSN to the original sender.
+
+ In general, any optional DSN field may be omitted if the Reporting
+ MTA site determines that inclusion of the field would impose too
+ great a compromise of site confidentiality. The need for such
+ confidentiality must be balanced against the utility of the omitted
+ information in trouble reports and DSNs gatewayed to foreign
+ environments.
+
+ Implementors are cautioned that many existing MTAs will send
+ nondelivery notifications to a return address in the message header
+ (rather than to the one in the envelope), in violation of SMTP and
+ other protocols. If a message is forwarded through such an MTA, no
+ reasonable action on the part of the forwarding MTA will prevent the
+ downstream MTA from compromising the forwarding address. Likewise,
+ if the recipient's MTA automatically responds to messages based on a
+ request in the message header (such as the nonstandard, but widely
+ used, Return-Receipt-To extension header), it will also compromise
+ the forwarding address.
+
+4.3 Non-Repudiation
+
+ Within the framework of today's internet mail, the DSNs defined in
+ this memo provide valuable information to the mail user; however,
+ even a "failed" DSN can not be relied upon as a guarantee that a
+ message was not received by the recipient. Even if DSNs are not
+ actively forged, conditions exist under which a message can be
+ delivered despite the fact that a failure DSN was issued.
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 24]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ For example, a race condition in the SMTP protocol allows for the
+ duplication of messages if the connection is dropped following a
+ completed DATA command, but before a response is seen by the SMTP
+ client. This will cause the SMTP client to retransmit the message,
+ even though the SMTP server has already accepted it.[9] If one of
+ those delivery attempts succeeds and the other one fails, a "failed"
+ DSN could be issued even though the message actually reached the
+ recipient.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 25]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+5. Appendix - collected grammar
+
+ NOTE: The following lexical tokens are defined in RFC 822: atom,
+ CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
+ The date-time lexical token is defined in [8].
+
+action-field = "Action" ":" action-value
+
+action-value =
+ "failed" / "delayed" / "delivered" / "relayed" / "expanded"
+
+address-type = atom
+
+arrival-date-field = "Arrival-Date" ":" date-time
+
+delivery-status-content =
+ per-message-fields 1*( CRLF per-recipient-fields )
+
+diagnostic-code-field =
+ "Diagnostic-Code" ":" diagnostic-type ";" *text
+
+diagnostic-type = atom
+
+dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
+
+envelope-id = *text
+
+extension-field = extension-field-name ":" *text
+
+extension-field-name = atom
+
+final-recipient-field =
+ "Final-Recipient" ":" address-type ";" generic-address
+
+generic-address = *text
+
+last-attempt-date-field = "Last-Attempt-Date" ":" date-time
+
+mta-name = *text
+
+mta-name-type = atom
+
+original-envelope-id-field =
+ "Original-Envelope-Id" ":" envelope-id
+
+original-recipient-field =
+ "Original-Recipient" ":" address-type ";" generic-address
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 26]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+per-message-fields =
+ [ original-envelope-id-field CRLF ]
+ reporting-mta-field CRLF
+ [ dsn-gateway-field CRLF ]
+ [ received-from-mta-field CRLF ]
+ [ arrival-date-field CRLF ]
+ *( extension-field CRLF )
+
+per-recipient-fields =
+ [ original-recipient-field CRLF ]
+ final-recipient-field CRLF
+ action-field CRLF
+ status-field CRLF
+ [ remote-mta-field CRLF ]
+ [ diagnostic-code-field CRLF ]
+ [ last-attempt-date-field CRLF ]
+ [ will-retry-until-field CRLF ]
+ *( extension-field CRLF )
+
+received-from-mta-field =
+ "Received-From-MTA" ":" mta-name-type ";" mta-name
+
+remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
+
+reporting-mta-field =
+ "Reporting-MTA" ":" mta-name-type ";" mta-name
+
+status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+ ; White-space characters and comments are NOT allowed within a
+ ; status-code, though a comment enclosed in parentheses MAY follow
+ ; the last numeric subfield of the status-code. Each numeric
+ ; subfield within the status-code MUST be expressed without
+ ; leading zero digits.
+
+status-field = "Status" ":" status-code
+
+will-retry-until-field = "Will-Retry-Until" ":" date-time
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 27]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+6. Appendix - Guidelines for gatewaying DSNs
+
+ NOTE: This section provides non-binding recommendations for the
+ construction of mail gateways that wish to provide semi-transparent
+ delivery reports between the Internet and another electronic mail
+ system. Specific DSN gateway requirements for a particular pair of
+ mail systems may be defined by other documents.
+
+6.1 Gatewaying from other mail systems to DSNs
+
+ A mail gateway may issue a DSN to convey the contents of a "foreign"
+ delivery or non-delivery notification over Internet mail. When there
+ are appropriate mappings from the foreign notification elements to
+ DSN fields, the information may be transmitted in those DSN fields.
+ Additional information (such as might be useful in a trouble ticket
+ or needed to tunnel the foreign notification through the Internet)
+ may be defined in extension DSN fields. (Such fields should be given
+ names that identify the foreign mail protocol, e.g. X400-* for X.400
+ NDN or DN protocol elements)
+
+ The gateway must attempt to supply reasonable values for the
+ Reporting-MTA, Final-Recipient, Action, and Status fields. These
+ will normally be obtained by translating the values from the remote
+ delivery or non-delivery notification into their Internet-style
+ equivalents. However, some loss of information is to be expected.
+ For example, the set of status-codes defined for DSNs may not be
+ adequate to fully convey the delivery diagnostic code from the
+ foreign system. The gateway should assign the most precise code
+ which describes the failure condition, falling back on "generic"
+ codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
+ (permanent failure) when necessary. The actual foreign diagnostic
+ code should be retained in the Diagnostic-Code field (with an
+ appropriate diagnostic-type value) for use in trouble tickets or
+ tunneling.
+
+ The sender-specified recipient address, and the original envelope-id,
+ if present in the foreign transport envelope, should be preserved in
+ the Original-Recipient and Original-Envelope-ID fields.
+
+ The gateway should also attempt to preserve the "final" recipient
+ addresses and MTA names from the foreign system. Whenever possible,
+ foreign protocol elements should be encoded as meaningful printable
+ ASCII strings.
+
+ For DSNs produced from foreign delivery or nondelivery notifications,
+ the name of the gateway MUST appear in the DSN-Gateway field of the
+ DSN.
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 28]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+6.2 Gatewaying from DSNs to other mail systems
+
+ It may be possible to gateway DSNs from the Internet into a foreign
+ mail system. The primary purpose of such gatewaying is to convey
+ delivery status information in a form that is usable by the
+ destination system. A secondary purpose is to allow "tunneling" of
+ DSNs through foreign mail systems, in case the DSN may be gatewayed
+ back into the Internet.
+
+ In general, the recipient of the DSN (i.e., the sender of the
+ original message) will want to know, for each recipient: the closest
+ available approximation to the original recipient address, the
+ delivery status (success, failure, or temporary failure), and for
+ failed deliveries, a diagnostic code that describes the reason for
+ the failure.
+
+ If possible, the gateway should attempt to preserve the Original-
+ Recipient address and Original-Envelope-ID (if present), in the
+ resulting foreign delivery status report.
+
+ When reporting delivery failures, if the diagnostic-type subfield of
+ the Diagnostic-Code field indicates that the original diagnostic code
+ is understood by the destination environment, the information from
+ the Diagnostic-Code field should be used. Failing that, the
+ information in the Status field should be mapped into the closest
+ available diagnostic code used in the destination environment.
+
+ If it is possible to tunnel a DSN through the destination
+ environment, the gateway specification may define a means of
+ preserving the DSN information in the delivery status reports used by
+ that environment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 29]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+7. Appendix - Guidelines for use of DSNs by mailing list exploders
+
+ NOTE: This section pertains only to the use of DSNs by "mailing
+ lists" as defined in [4], section 7.2.7.
+
+ DSNs are designed to be used by mailing list exploders to allow them
+ to detect and automatically delete recipients for whom mail delivery
+ fails repeatedly.
+
+ When forwarding a message to list subscribers, the mailing list
+ exploder should always set the envelope return address (e.g. SMTP
+ MAIL FROM address) to point to a special address which is set up to
+ received nondelivery reports. A "smart" mailing list exploder can
+ therefore intercept such nondelivery reports, and if they are in the
+ DSN format, automatically examine them to determine for which
+ recipients a message delivery failed or was delayed.
+
+ The Original-Recipient field should be used if available, since it
+ should exactly match the subscriber address known to the list. If
+ the Original-Recipient field is not available, the recipient field
+ may resemble the list subscriber address. Often, however, the list
+ subscriber will have forwarded his mail to a different address, or
+ the address may be subject to some re-writing, so heuristics may be
+ required to successfully match an address from the recipient field.
+ Care is needed in this case to minimize the possibility of false
+ matches.
+
+ The reason for delivery failure can be obtained from the Status and
+ Action fields, and from the Diagnostic-Code field (if the status-type
+ is recognized). Reports for recipients with action values other than
+ "failed" can generally be ignored; in particular, subscribers should
+ not be removed from a list due to "delayed" reports.
+
+ In general, almost any failure status code (even a "permanent" one)
+ can result from a temporary condition. It is therefore recommended
+ that a list exploder not delete a subscriber based on any single
+ failure DSN (regardless of the status code), but only on the
+ persistence of delivery failure over a period of time.
+
+ However, some kinds of failures are less likely than others to have
+ been caused by temporary conditions, and some kinds of failures are
+ more likely to be noticed and corrected quickly than others. Once
+ more precise status codes are defined, it may be useful to
+ differentiate between the status codes when deciding whether to
+ delete a subscriber. For example, on a list with a high message
+ volume, it might be desirable to temporarily suspend delivery to a
+ recipient address which causes repeated "temporary" failures, rather
+ than simply deleting the recipient. The duration of the suspension
+
+
+
+Moore & Vaudreuil Standards Track [Page 30]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ might depend on the type of error. On the other hand, a "user
+ unknown" error which persisted for several days could be considered a
+ reliable indication that address were no longer valid.
+
+8. Appendix - IANA registration forms for DSN types
+
+ The forms below are for use when registering a new address-type,
+ diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
+ Authority (IANA). Each piece of information requested by a
+ registration form may be satisfied either by providing the
+ information on the form itself, or by including a reference to a
+ published, publicly available specification which includes the
+ necessary information. IANA MAY reject DSN type registrations
+ because of incomplete registration forms, imprecise specifications,
+ or inappropriate type names.
+
+ To register a DSN type, complete the applicable form below and send
+ it via Internet electronic mail to <IANA@IANA.ORG>.
+
+8.1 IANA registration form for address-type
+
+ A registration for a DSN address-type MUST include the following
+ information:
+
+(a) The proposed address-type name.
+
+(b) The syntax for mailbox addresses of this type, specified using BNF,
+ regular expressions, ASN.1, or other non-ambiguous language.
+
+(c) If addresses of this type are not composed entirely of graphic
+ characters from the US-ASCII repertoire, a specification for how
+ they are to be encoded as graphic US-ASCII characters in a DSN
+ Original-Recipient or Final-Recipient DSN field.
+
+(d) [optional] A specification for how addresses of this type are to be
+ translated to and from Internet electronic mail addresses.
+
+8.2 IANA registration form for diagnostic-type
+
+ A registration for a DSN address-type MUST include the following
+ information:
+
+(a) The proposed diagnostic-type name.
+
+(b) A description of the syntax to be used for expressing diagnostic
+ codes of this type as graphic characters from the US-ASCII
+ repertoire.
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 31]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+(c) A list of valid diagnostic codes of this type and the meaning of
+ each code.
+
+(d) [optional] A specification for mapping from diagnostic codes of this
+ type to DSN status codes (as defined in [5]).
+
+8.3 IANA registration form for MTA-name-type
+
+ A registration for a DSN MTA-name-type must include the following
+ information:
+
+(a) The proposed MTA-name-type name.
+
+(b) A description of the syntax of MTA names of this type, using BNF,
+ regular expressions, ASN.1, or other non-ambiguous language.
+
+(c) If MTA names of this type do not consist entirely of graphic
+ characters from the US-ASCII repertoire, a specification for how an
+ MTA name of this type should be expressed as a sequence of graphic
+ US-ASCII characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 32]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+9. Appendix - Examples
+
+ NOTE: These examples are provided as illustration only, and are not
+ considered part of the DSN protocol specification. If an example
+ conflicts with the protocol definition above, the example is wrong.
+
+ Likewise, the use of *-type subfield names or extension fields in
+ these examples is not to be construed as a definition for those type
+ names or extension fields.
+
+ These examples were manually translated from bounced messages using
+ whatever information was available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 33]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+9.1 This is a simple DSN issued after repeated attempts
+ to deliver a message failed. In this case, the DSN is
+ issued by the same MTA from which the message was originated.
+
+
+ Date: Thu, 7 Jul 1994 17:16:05 -0400
+ From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
+ Message-Id: <199407072116.RAA14128@CS.UTK.EDU>
+ Subject: Returned mail: Cannot send message for 5 days
+ To: <owner-info-mime@cs.utk.edu>
+ MIME-Version: 1.0
+ Content-Type: multipart/report; report-type=delivery-status;
+ boundary="RAA14128.773615765/CS.UTK.EDU"
+
+ --RAA14128.773615765/CS.UTK.EDU
+
+ The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
+ from root@localhost
+
+ ----- The following addresses had delivery problems -----
+ <louisl@larry.slip.umd.edu> (unrecoverable error)
+
+ ----- Transcript of session follows -----
+ <louisl@larry.slip.umd.edu>... Deferred: Connection timed out
+ with larry.slip.umd.edu.
+ Message could not be delivered for 5 days
+ Message will be deleted from queue
+
+ --RAA14128.773615765/CS.UTK.EDU
+ content-type: message/delivery-status
+
+ Reporting-MTA: dns; cs.utk.edu
+
+ Original-Recipient: rfc822;louisl@larry.slip.umd.edu
+ Final-Recipient: rfc822;louisl@larry.slip.umd.edu
+ Action: failed
+ Status: 4.0.0
+ Diagnostic-Code: smtp; 426 connection timed out
+ Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
+
+ --RAA14128.773615765/CS.UTK.EDU
+ content-type: message/rfc822
+
+ [original message goes here]
+ --RAA14128.773615765/CS.UTK.EDU--
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 34]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+9.2 This is another DSN issued by the sender's MTA, which
+ contains details of multiple delivery attempts. Some of
+ these were detected locally, and others by a remote MTA.
+
+
+ Date: Fri, 8 Jul 1994 09:21:47 -0400
+ From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
+ Subject: Returned mail: User unknown
+ To: <owner-ups-mib@CS.UTK.EDU>
+ MIME-Version: 1.0
+ Content-Type: multipart/report; report-type=delivery-status;
+ boundary="JAA13167.773673707/CS.UTK.EDU"
+
+ --JAA13167.773673707/CS.UTK.EDU
+ content-type: text/plain; charset=us-ascii
+
+ ----- The following addresses had delivery problems -----
+ <arathib@vnet.ibm.com> (unrecoverable error)
+ <wsnell@sdcc13.ucsd.edu> (unrecoverable error)
+
+ --JAA13167.773673707/CS.UTK.EDU
+ content-type: message/delivery-status
+
+ Reporting-MTA: dns; cs.utk.edu
+
+ Original-Recipient: rfc822;arathib@vnet.ibm.com
+ Final-Recipient: rfc822;arathib@vnet.ibm.com
+ Action: failed
+ Status: 5.0.0 (permanent failure)
+ Diagnostic-Code: smtp;
+ 550 'arathib@vnet.IBM.COM' is not a registered gateway user
+ Remote-MTA: dns; vnet.ibm.com
+
+ Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
+ Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
+ Action: delayed
+ Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
+
+ Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
+ Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
+ Action: failed
+ Status: 5.0.0
+ Diagnostic-Code: smtp; 550 user unknown
+ Remote-MTA: dns; sdcc13.ucsd.edu
+
+ --JAA13167.773673707/CS.UTK.EDU
+ content-type: message/rfc822
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 35]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ [original message goes here]
+ --JAA13167.773673707/CS.UTK.EDU--
+
+
+9.3 A delivery report generated by Message Router (MAILBUS) and
+ gatewayed by PMDF_MR to a DSN. In this case the gateway did not
+ have sufficient information to supply an original-recipient address.
+
+
+
+ Disclose-recipients: prohibited
+ Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
+ From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
+ Subject: Status of : Re: Battery current sense
+ To: owner-ups-mib@CS.UTK.EDU
+ Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
+ MIME-version: 1.0
+ content-type: multipart/report; report-type=delivery-status;
+ boundary="84229080704991.122306.SYS30"
+
+ --84229080704991.122306.SYS30
+ content-type: text/plain
+
+ Invalid address - nair_s
+ %DIR-E-NODIRMTCH, No matching Directory Entry found
+
+ --84229080704991.122306.SYS30
+ content-type: message/delivery-status
+
+ Reporting-MTA: mailbus; SYS30
+
+ Final-Recipient: unknown; nair_s
+ Status: 5.0.0 (unknown permanent failure)
+ Action: failed
+
+ --84229080704991.122306.SYS30--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 36]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+9.4 A delay report from a multiprotocol MTA. Note that there is no
+ returned content, so no third body part appears in the DSN.
+
+ From: <postmaster@nsfnet-relay.ac.uk>
+ Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
+ Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
+ id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
+ Sun, 10 Jul 1994 00:36:51 +0100
+ To: owner-info-mime@cs.utk.edu
+ Date: Sun, 10 Jul 1994 00:36:51 +0100
+ Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
+ content-type: multipart/report; report-type=delivery-status;
+ boundary=foobar
+
+ --foobar
+ content-type: text/plain
+
+ The following message:
+
+ UA-ID: Reliable PC (...
+ Q-ID: sun2.nsf:77/msg.11820-0
+
+ has not been delivered to the intended recipient:
+
+ thomas@de-montfort.ac.uk
+
+ despite repeated delivery attempts over the past 24 hours.
+
+ The usual cause of this problem is that the remote system is
+ temporarily unavailable.
+
+ Delivery will continue to be attempted up to a total elapsed
+ time of 168 hours, ie 7 days.
+
+ You will be informed if delivery proves to be impossible
+ within this time.
+
+ Please quote the Q-ID in any queries regarding this mail.
+
+ --foobar
+ content-type: message/delivery-status
+
+ Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
+
+ Final-Recipient: rfc822;thomas@de-montfort.ac.uk
+ Status: 4.0.0 (unknown temporary failure)
+ Action: delayed
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 37]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+ --foobar--
+
+10. Acknowledgments
+
+ The authors wish to thank the following people for their reviews of
+ earlier drafts of this document and their suggestions for
+ improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim
+ Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko
+ Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark
+ Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory
+ Sheehan.
+
+11. References
+
+[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
+ RFC 1521, Bellcore, Innosoft, September 1993.
+
+[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting
+ of Mail System Administrative Messages", RFC 1892, Octal Network
+ Services, January 1996.
+
+[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+[4] Moore, K., "SMTP Service Extension for Delivery Status
+ Notifications", RFC 1891, University of Tennessee, January 1996.
+
+[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal
+ Network Services, January 1996.
+
+[6] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two:
+ Message Header Extensions for Non-Ascii Text", RFC 1522, University
+ of Tennessee, September 1993.
+
+[8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, USC/Information Sciences Institute,
+ October 1989.
+
+[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN,
+ February 1988.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 38]
+
+RFC 1894 Delivery Status Notifications January 1996
+
+
+11. Authors' Addresses
+
+ Keith Moore
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville, TN 37996-1301
+ USA
+
+ EMail: moore@cs.utk.edu
+ Phone: +1 615 974 3126
+ Fax: +1 615 974 8296
+
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17080 Dallas Parkway
+ Dallas, TX 75248-1905
+ USA
+
+ EMail: Greg.Vaudreuil@Octel.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 39]
+