diff options
| author | Graham Wilson <graham@mknod.org> | 2004-11-29 16:40:04 +0000 |
|---|---|---|
| committer | Graham Wilson <graham@mknod.org> | 2004-11-29 16:40:04 +0000 |
| commit | fdec8d6cf10bfd061d98d8b790bb71985ed36e3a (patch) | |
| tree | 5dcdc4652472a06e8be717237d66b17e74708666 /RFC/rfc1894.txt | |
| parent | 100fa76e5f1675dd18b9d35e5c7e88699a57ba7d (diff) | |
| download | fetchmail-fdec8d6cf10bfd061d98d8b790bb71985ed36e3a.tar.gz fetchmail-fdec8d6cf10bfd061d98d8b790bb71985ed36e3a.tar.bz2 fetchmail-fdec8d6cf10bfd061d98d8b790bb71985ed36e3a.zip | |
Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file.
svn path=/trunk/; revision=4013
Diffstat (limited to 'RFC/rfc1894.txt')
| -rw-r--r-- | RFC/rfc1894.txt | 2187 |
1 files changed, 0 insertions, 2187 deletions
diff --git a/RFC/rfc1894.txt b/RFC/rfc1894.txt deleted file mode 100644 index f1fc90d4..00000000 --- a/RFC/rfc1894.txt +++ /dev/null @@ -1,2187 +0,0 @@ - - - - - - -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] - |