summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3464.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3464.txt')
-rw-r--r--doc/rfc/rfc3464.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc3464.txt b/doc/rfc/rfc3464.txt
new file mode 100644
index 0000000..bacfd41
--- /dev/null
+++ b/doc/rfc/rfc3464.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+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 | <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 that 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.
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 6]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ + 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 that is independent of the mail
+ transport system that issued the DSN. However, if a foreign error
+ 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" sub-field followed by
+ a sub-field whose contents are ordinary text characters, and the
+ format of which is indicated by the "type" sub-field. 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 [REPORT]). 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 [REPORT].
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 7]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ (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.
+
+ 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 that 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 still be issued in response to a single message
+ submission.
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 8]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+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 [RFC822]). 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 that 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 [MIME3].
+
+2.1.2 "*-type" sub-fields
+
+ Several DSN fields consist of a "-type" sub-field, followed by a
+ semicolon, followed by "*text". For these fields, the keyword used
+ in the address-type, diagnostic-type, or MTA-name-type sub-field
+ indicates the expected format of the address, status-code, or
+ MTA-name which follows.
+
+
+
+Moore & Vaudreuil Standards Track [Page 9]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ The "-type" sub-fields 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 [SMTP], 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 one or more specifications that provide such
+ descriptions. (The "rfc822" address-type, "smtp" diagnostic-type,
+ and "dns" MTA-name-type are defined in [DRPT].) Registration forms
+ for address-type, diagnostic-type, and MTA-name-type appear in
+ Appendix D.
+
+ 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 [RFC822], 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 [HOSTREQ].
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 10]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+2.2 Per-Message DSN Fields
+
+ Some fields of a DSN apply to all of the delivery attempts described
+ by that DSN. At most, these fields may appear 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" that 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 that
+ 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
+ that 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 3464 Delivery Status Notifications January 2003
+
+
+ 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 that 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 non-delivery 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 3464 Delivery Status Notifications January 2003
+
+
+ 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 non-delivery
+ 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
+ sub-field. 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 sub-field 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 that
+ translated a foreign (non-Internet) delivery status notification into
+ this DSN. This field MUST appear in any DSN that 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
+
+ For gateways into Internet mail, the MTA-name-type will normally be
+ "dns", and the mta-name will be the Internet domain name of the
+ gateway.
+
+
+
+Moore & Vaudreuil Standards Track [Page 13]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+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 sub-field 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 "dns".)
+
+ The mta-name portion of the Received-From-MTA field is formatted
+ according to the conventions indicated by the MTA-name-type sub-
+ field.
+
+ 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 [HOSTREQ]. 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 3464 Delivery Status Notifications January 2003
+
+
+ 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 ]
+ [ final-log-id-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 will normally be "rfc822", and the address will be
+ according to the syntax specified in [RFC822]. 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 [DRPT]. 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 3464 Delivery Status Notifications January 2003
+
+
+ The syntax of the field is as follows:
+
+ final-recipient-field =
+ "Final-Recipient" ":" address-type ";" generic-address
+
+ The generic-address sub-field of the Final-Recipient field MUST
+ contain the mailbox address of the recipient (from the transport
+ envelope), as it was when the Reporting MTA accepted the message for
+ delivery.
+
+ 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 a 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 sub-field 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 are
+ not allowed 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"
+
+ The action-value may be spelled in any combination of upper and lower
+ case characters.
+
+
+
+Moore & Vaudreuil Standards Track [Page 16]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ "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 [DRPT],
+ 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 name server timed out.
+
+
+
+Moore & Vaudreuil Standards Track [Page 17]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ 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 that 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 sub-field of the status-code.
+ ; Each numeric sub-field 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 [STATUS].
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 18]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+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 sub-field 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
+ non-delivery 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 3464 Delivery Status Notifications January 2003
+
+
+ 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 [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
+ used.
+
+2.3.8 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.9 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
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 20]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ The date and time are expressed in RFC 822 'date-time' format, as
+ modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
+ used.
+
+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 that produced the DSN. (e.g., Foomail-Queue-ID).
+
+ MTA implementers 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 that 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").
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 21]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+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 [DRPT]), it is sufficient that delivery
+ failure reports use this protocol.
+
+ 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
+ [DRPT] 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
+ [DRPT], 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.)
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 22]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ 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:
+
+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:
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 23]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ (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 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.
+
+ Implementers are cautioned that many existing MTAs will send non-
+ delivery 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.
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 24]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+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.
+
+ 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 [SMTPDUP]. 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.
+
+5. Normative References
+
+ [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
+ Notifications", RFC 3461, January 2003.
+
+ [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
+ for Delivery Status Notifications", RFC 1894, January 1996.
+
+ [HOSTREQ] Braden, R. (ed.), "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+ Part Three: Message Header Extensions for Non-ASCII Text",
+ RFC 2047, November 1996.
+
+ [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
+ Reporting of Mail System Administrative Messages", RFC
+ 3462, January 2003.
+
+ [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+
+
+Moore & Vaudreuil Standards Track [Page 25]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ [SMTPDUP] Partridge, C., "Duplicate Messages and SMTP", RFC 1047,
+ February 1988.
+
+ [STATUS] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
+ 3463, January 2003.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+6. Acknowledgments
+
+ The authors wish to thank the following people for their reviews of
+ early drafts of RFC 1894, of which this document is a revision, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 26]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+Appendix A - 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 [HOSTREQ].
+
+ 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
+
+ final-log-id-field = "Final-Log-ID" ":" *text
+
+ 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
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 27]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ original-recipient-field =
+ "Original-Recipient" ":" address-type ";" generic-address
+
+ 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 ]
+ [ final-log-id-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
+ ; a status-code, though a comment enclosed in parentheses
+ ; MAY follow the last numeric sub-field of the status-code.
+ ; Each numeric sub-field 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 28]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+Appendix B - 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.
+
+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 29]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+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 sub-field 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.
+
+Appendix C - Guidelines for use of DSNs by mailing list exploders
+
+ 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
+ receive non-delivery reports. A "smart" mailing list exploder can
+ therefore intercept such non-delivery reports, and if they are in the
+ DSN format, automatically examine them to determine for which
+ recipients a message delivery failed or was delayed.
+
+
+
+Moore & Vaudreuil Standards Track [Page 30]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ 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
+ might depend on the type of error. On the other hand, a "user
+ unknown" error that persisted for several days could be considered a
+ reliable indication that address were no longer valid.
+
+Appendix D - 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.
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 31]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ To register a DSN type, complete the applicable form below and send
+ it via Internet electronic mail to <IANA@IANA.ORG>.
+
+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.
+
+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.
+
+ (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]).
+
+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.
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 32]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ (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.
+
+Appendix E - Examples
+
+ 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 sub-field 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 3464 Delivery Status Notifications January 2003
+
+
+Simple DSN
+
+ 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 3464 Delivery Status Notifications January 2003
+
+
+Multi-Recipient DSN
+
+ 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 3464 Delivery Status Notifications January 2003
+
+
+ [original message goes here]
+
+ --JAA13167.773673707/CS.UTK.EDU--
+
+DSN from gateway to foreign system
+
+ 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
+ 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 3464 Delivery Status Notifications January 2003
+
+
+Delayed DSN
+
+ A delay report from a multiprotocol MTA. Note that there is no
+ returned content, so no third body part appears in the DSN.
+
+ MIME-Version: 1.0
+ 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, i.e., 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
+
+
+
+Moore & Vaudreuil Standards Track [Page 37]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+ Status: 4.0.0 (unknown temporary failure)
+ Action: delayed
+
+ --foobar--
+
+Appendix F - Changes from RFC 1894
+
+ Changed Authors contact information
+
+ Updated required standards boilerplate
+
+ Edited the text to make it spell-checker and grammar checker
+ compliant
+
+ Updated references to point to later, more mature documents, changed
+ reference enumeration scheme.
+
+ Fixed paragraph numbering on page 20
+
+ Fixed Delayed DSN example
+
+ Added Table of Contents
+
+ Moved Appendices to the end of the document
+
+ Changed the MTA-name-Type for gateways into Internet mail, the
+ MTA-name-type from "SMTP" to "dns".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 38]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+Authors' Addresses
+
+ Keith Moore
+ University of Tennessee
+ 1122 Volunteer Blvd, Suite 203
+ Knoxville TN 37996-3450
+ USA
+
+ Phone: +1-865-974-3126
+ Fax: +1-865-974-8296
+ EMail: moore@cs.utk.edu
+
+
+ Gregory M. Vaudreuil
+ Lucent Technologies
+ 7291 Williamson Rd
+ Dallas, Tx. 75214
+ USA
+
+ Phone: +1 214 823 9325
+ EMail: GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 39]
+
+RFC 3464 Delivery Status Notifications January 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil Standards Track [Page 40]
+