From fdec8d6cf10bfd061d98d8b790bb71985ed36e3a Mon Sep 17 00:00:00 2001 From: Graham Wilson Date: Mon, 29 Nov 2004 16:40:04 +0000 Subject: 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 --- RFC/rfc1894.txt | 2187 ------------------------------------------------------- 1 file changed, 2187 deletions(-) delete mode 100644 RFC/rfc1894.txt (limited to 'RFC/rfc1894.txt') 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 - . Requests to subscribe to the mailing - list should be addressed to . - 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 | ". - - 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 |") (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 . - -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 - Message-Id: <199407072116.RAA14128@CS.UTK.EDU> - Subject: Returned mail: Cannot send message for 5 days - To: - 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 ----- - (unrecoverable error) - - ----- Transcript of session follows ----- - ... 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 - Subject: Returned mail: User unknown - To: - 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 ----- - (unrecoverable error) - (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 - 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: - Message-Id: <199407092338.TAA23293@CS.UTK.EDU> - Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk - id ; - 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] - -- cgit v1.2.3