Network Working Group Keith Moore Internet Draft University of Tennessee Expires: May 20, 1995 Greg Vaudreuil Octel Network Services November 20, 1994 An Extensible Message Format for Delivery Status Notifications draft-ietf-notary-mime-delivery-03.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is meant to be a machine-processable alternative to the full range of electronic mail delivery status notifications currently in use in the Internet. 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]. Moore/Vaudreuil Expires 20 May 1995 [Page 1]
Delivery Status Notifications 20 November 1994 Because many messages are sent between the MIME-capable world and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is intended to be useful in a multi-protocol messaging environment. To this end, the DSN protocol provides for the carriage of "foreign" addresses and error codes, in addition to the addresses and error codes normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through MIME-capable systems using the DSN protocol. 2. Requirements The DSNs defined in this memo are expected to serve several purposes: + Inform human beings of the status of message delivery processing, as well as the reasons for any delivery problems or outright failures + Allow mail user agents to keep track of the delivery status of messages sent + Allow mailing list expanders to automatically maintain their subscriber lists when delivery attempts fail + Convey delivery and non-delivery notifications resulting from attempts to deliver messages to "foreign" mail systems via a gateway + 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; and + Provide sufficient information to remote MTA maintainers so that they understand the nature of reported errors. This feature is used in the case that failure to deliver a message is due to the malfunction of a remote MTA and the sender wants to report the problem to the remote MTA administrator. These purposes place the following constraints on the notification protocol: + It must be readable by humans as well as being machine-parsable. + 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. + It must be able to preserve the information associated with a delivery attempt in a remote messaging system, using the "language" (addresses and status codes) of that remote system. Moore/Vaudreuil Expires 20 May 1995 [Page 2]
Delivery Status Notifications 20 November 1994 + 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 original system, so that the "foreign" attributes mentioned above may be correctly interpreted. A DSN consists of a set of per-message fields to 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. A message that is either gatewayed between dissimilar messaging systems or auto-forwarded to an alternate recipient address may have its sender or recipient addresses changed during transit. For any particular recipient, up to three different formats of an address are of interest: "original" The recipient address as originally specified by the sender. "final" The recipient address as it was when the message was presented to the "final" MTA to handle the message for that recipient (i.e., the one which is issuing the DSN). "remote" If an attempt was made by the "final" MTA to relay the message to yet another MTA, and a DSN is issued by the "final" MTA based on the response of the "remote" (next-hop) MTA, the address presented to the "remote" MTA, along with the status code returned by that MTA, may also be of interest. Figure 1 may be useful in explaining the difference between the "original", "final", and "remote" MTAs: +-----+ +--------+ +-----------+ +-----+ +------+ | | => |Original| => ... => |penultimate| => |Final| ===> |Remote| | user| | MTA | | MTA | | MTA | <No! | MTA | |agent| +--------+ +-----------+ +--v--+ +------+ | | | | | <-------------------------------------------+ +-----+ (DSN returned to sender by Final MTA) Figure 1. Illustration of Original, Final, and Remote MTAs In the diagram, the "original" MTA is the one which accepts the message from the sender's user agent. The message successfully passes through perhaps several other MTAs until it arrives at the "final" MTA, which for some reason needs to issue a DSN. The DSN is returned to the sender. (By definition, the MTA that issues a DSN is always the "final" MTA.) Moore/Vaudreuil Expires 20 May 1995 [Page 3]
Delivery Status Notifications 20 November 1994 If the "final" MTA is issuing the DSN based on information obtained from some other MTA downstream (for example, because the downstream MTA refused to accept responsibility for delivery of a message), then the MTA which reported that information is the "remote" MTA. (If the "final" MTA issues the DSN based on information obtained locally, as in the case of delivery to a local user, there is no "remote" MTA.) Each of these addresses is useful under some circumstances: + The DSN must contain the original recipient address (rather than a forwarding address or some modified version of the original address), so that the recipient address in the DSN can be compared with the recipient address as specified by the sender when the original message was sent. + The "final" form of the address is needed when reporting a problem to the postmaster of the site where message delivery failed, so that she can attempt to reproduce the conditions that caused the failure. + When interpreting a DSN, the sender's user agent will want the latest possible (i.e. "remote") status code if it is available. However, this code may either not be available, or it might be from a foreign mail system whose codes are not understood by the sender's user agent. In these cases the "final" code might be more useful. + When gatewaying a DSN into a foreign MTS, the gateway may use either the "remote" or "final" status codes and recipient addresses, depending on circumstances. Similarly, it may be appropriate to use either the original or the current recipient address for any particular recipient. This situation is described in more detail in Appendix 13. Since different values for "sender address", "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 allows each of several different forms of the sender address, recipient address, and status code to be conveyed. 3. Format of a Delivery Status Notification A complete DSN is a MIME message with a top-level content-type of multipart/report (defined in [2]). For a DSN, the report-type parameter of the multipart/report content is "delivery-status". 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 Moore/Vaudreuil Expires 20 May 1995 [Page 4]
Delivery Status Notifications 20 November 1994 particular recipient may be delayed), multiple DSNs may be still be issued. The DSN is addressed (in both the header and envelope) to the return address from the envelope of the message for which the DSN is being generated. The From header field of the DSN contains the address of a human who is responsible for maintaining the mail system at the final MTA site (e.g. Postmaster), while the envelope sender address of the DSN is set up to ensure that no delivery status reports will be issued in response to the DSN itself. (For example, in SMTP, the MAIL FROM address should be an empty string.) 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 the same information. In particular, it is very desirable to preserve the subject, date, and message-id (or equivalent) fields from the original message. 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 should be used to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 6 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 [5]). The per-message fields appear first. 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 ) These fields are described in detail below. Note: 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 TAB. Text which appears in parenthesis 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 Moore/Vaudreuil Expires 20 May 1995 [Page 5]
Delivery Status Notifications 20 November 1994 fields may use the "encoded-word" construct defined in [6]. Several fields exist to identify the "MTS type" of the original, final, or remote MTA. For the purpose of this specification, a "message transfer system" (MTS) is a service which transfers electronic mail messages from one user (the sender) to one or more users (recipients). A particular MTS will have its own protocols for (a) electronic mail addresses for senders and recipients, (b) names of MTAs, (c) the format of electronic mail messages, (d) transferring messages and responsibility for message delivery from one MTA to another, and (e) communicating delivery status conditions. An MTS-type is a identifier for a particular message transfer system. A registry of MTS-types is maintained by the Internet Assigned Numbers Authority (IANA). IANA will not register MTS-type names beginning with "X-"; these are reserved for experimental use. The syntax for an MTS-type is: mts-type = atom Because DSNs may be issued for messages that originated in foreign mail systems, or gatewayed from delivery status reports that were issued in foreign mail systems, many of the address and status codes fields may be in some format other than that normally used in the Internet. The various MTS-type fields are used to identify the mail system in which a particular address or status code appeared. For example, if the final- mts-type is X400, the final-recipient address must be an X.400 recipient address, and the final-status code must be an X.400-style error code. Like notification field names, MTS-type names are also case-insensitve. A number of DSN fields are defined to have a field body consisting of "xtext". Within such fields, the normal RFC 822 special characters are not used. Portions of "xtext" enclosed in paraenthesis are treated as comments, but such comments are not considered separators for the purpose of lexical analysis. Except for comments and escaped-crlf's, all characters are significant. RFC 1522 encoded-words may NOT be used in xtext. "xtext" is defined as follows: xtext = *( xchar / hexchar / escaped-crlf ) xchar = any ASCII CHAR between SPACE (32) and TILDE (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 Moore/Vaudreuil Expires 20 May 1995 [Page 6]
Delivery Status Notifications 20 November 1994 hexadecimal digits An escaped-crlf may appear at the end of a line to allow the field to be continued to the next line without inserting any white space. escaped-crlf = "\" immediately followed by the characters: CR LF SPACE When encoding a field whose body is defined as "xtext", a SPACE which immediately precedes a CR LF pair should be encoded either as a "hexchar", or as an "escaped-crlf" followed by a SPACE. When decoding a field whose body is defined as "xtext", any number of SPACEs which immediately precede a CR LF pair (i.e. end of line) should be ignored. 3.1 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. With the exception of the original-mts-type field itself, the format of each of the per-message fields is specific to the original-mts-type. per-message-fields = [ original-mts-type-field CRLF ] [ original-envelope-id-field CRLF ] final-mts-type-field CRLF final-mta-field CRLF [ received-from-field CRLF ] [ arrival-date-field CRLF ] *( extension-field CRLF ) 3.1.1 The Original-MTS-Type field original-mts-type-field = "Original-MTS-Type" ":" MTS-type The original-mts-type field contains the MTS-type name of the MTS in which the message was submitted. This name MUST be an IANA-registered MTS-type name, unless it begins with "X-". This field is required if the original-envelope-id field or any original-recipient field is present. If neither of these fields is present, the original-mts-type field may be omitted. 3.1.2 The Original-Envelope-Id field Moore/Vaudreuil Expires 20 May 1995 [Page 7]
Delivery Status Notifications 20 November 1994 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. The original-envelope-id line is defined as follows: original-envelope-id-field = "Original-Envelope-Id" ":" envelope-id envelope-id = xtext There may be at most one original-envelope-id field per DSN. If an original "envelope identifier" is not available when a DSN is issued, the original-envelope-id DSN field MUST NOT be included in the DSN. NOTE IN DRAFT: This last sentence may be a bit too strong. The intent is to prevent an MTA from simply concocting an envelope-id for a message. For the envelope-id field to be useful, it must be unique for each message transmission, known by the sender of the original message when the message was sent, and be transmitted along with the message envelope. However, the MTA issuing the DSN has no way of knowing whether the envelope-id it received in a message envelope is the same as the "original" one known by the message sender. Some mail protocols require an envelope-id or similar token, and a gateway into such an environemnt will have to concoct one without the sender's knowledge. If a DSN is issued for such a message, it will contain an envelope-id which is not specified by the sender. In general this seems unavoidable. The envelope-id is NOT case-insensitive. The DSN must preserve the original case and spelling of the envelope-id. NOTE: The original-envelope-id is NOT to be confused with 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. 3.1.3 The Final-MTS-Type DSN field final-mts-type-field = "Final-MTS-Type" ":" MTS-type The final-mts-type field contains the name of the MTS via which the message arrived at the final MTA. The MTS-type MUST be registered with IANA, unless it begins with "X-". NOTE WELL: If the final MTA is actually a multi-protocol MTA or mail gateway, the final-mts-type is the name of the MTS by which the message Moore/Vaudreuil Expires 20 May 1995 [Page 8]
Delivery Status Notifications 20 November 1994 ARRIVED at that MTA. The final-mts-type field is REQUIRED. 3.1.4 The Final-MTA DSN field final-mta-field = "Final-MTA" ":" xtext The final-mta field contains the name of the MTA which issued the DSN. This field is REQUIRED. This is not necessarily the MTA which reported the success or failure of a delivery attempt. For example, 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 final-mta field. The contents of the final-mta field are formatted according to the conventions of the "final" MTS, as indicated by the final-mts-type field. Because the exact spelling of an MTA name may be significant in a particular environment, MTA names must be considered case-sensitive. 3.1.5 The Received-From DSN field The optional Received-From field indicates the name of the MTA from which the message was received. (In Figure 1, this MTA is labelled the "penultimate" MTA.) received-from-field = "Received-From" ":" xtext If the message was received from an Internet host, the contents of the Received-From field should be the Internet domain name corresponding to the network address of that host. Otherwise, the contents of this field may be any printable string identifying the MTA from which the message was received. The contents of the received-from field are formatted according to the conventions of the "final" MTS, as indicated by the final-mts-type field. Since case is significant in some mail systems, the exact spelling, including case, of the MTA name should be preserved. 3.1.6 The Arrival-Date DSN field The optional Arrival-Date field indicates the date and time at which the message arrived at the final MTA. If the Date field is also provided in a per-recipient field, this can be used to determine the interval Moore/Vaudreuil Expires 20 May 1995 [Page 9]
Delivery Status Notifications 20 November 1994 between when the message arrived at the final 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. Numeric timezones ([+/-]HHMM format) MUST be used. 3.1.7 Extension fields Additional per-message DSN fields may be defined in the future, if necessary to tunnel MTS-specific delivery for a particular MTS-type or by any extension to this memo which is published as an RFC. extension-field = extension-field-name ":" xtext extension-field-name = atom 3.2 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. The syntax for the group of per-recipient fields is as follows: per-recipient-fields = basic-fields mts-specific-fields basic-fields = recipient-field CRLF action-field CRLF status-field CRLF [ date-field CRLF ] [ final-log-id-field CRLF ] [ expiry-date-field CRLF ] mts-specific-fields = [ original-recipient-field CRLF ] [ final-recipient-field CRLF ] [ final-status-field CRLF ] [ remote-mts-type-field CRLF ] [ remote-mta-field CRLF ] [ remote-recipient-field CRLF ] [ remote-status-field CRLF ] *( extension-field CRLF ) The "basic" fields are generic in nature and are always defined according to Internet mail conventions. Except for the "date" field, these fields are required for each recipient listed in a DSN. When mts- specific fields are either not available or not usable (say, by a gateway to a different environment), the "basic" fields provide fallback Moore/Vaudreuil Expires 20 May 1995 [Page 10]
Delivery Status Notifications 20 November 1994 values with a known syntax. The syntax of each mts-specific field is specific to the mts-type for which that field applies. For example, the format of the final- recipient, final-mta, and final-status fields are given by the final- mts-type field. This combined approach allows "foreign" information to be preserved in DSNs for messages that are gatewayed in or out of the Internet, while retaining a set of "canonical" information which will always be present, and which can provide minimum functionality. 3.2.1 Basic per-recipient fields 3.2.1.1 Recipient field The 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. The syntax of the field is as follows: recipient-field = "Recipient" ":" [route] addr-spec The value following the Recipient field contains the RFC 822 mailbox of the recipient address. The address MUST be in RFC 822 "addr-spec" format (with an optional "route" prefix), and MUST contain the fully- qualified domain name of the recipient's domain. (EXCEPTION: If the DSN is being issued for this recipient, because of an improperly formatted address or incomplete domain name, the recipient DSN field may contain the illegal address or the address with the incomplete domain name.) NOTE IN DRAFT: There is a conflict here between having a "failed" DSN report exactly the conditions that cause an error, or having a rigorously formatted field that contains the failed address (even if the problem is masked when the address is reformatted). To this author (KM), the former goal seems more important. Delivery failure is often caused by bad address rewriting, and the portion of an MTA that generates a DSN can hardly be expected to be better at such rewriting (while attempting to translate a foreign address into 822 syntax) than the portion of the MTA that rewrites such addresses for the message envelope. The best way to solve the address rewriting problem would seem to be to make the source of the problem obvious via accurate error reporting using DSNs. NOTE: Although RFC 1123 [7] discourages explicit source routing in SMTP, and allows SMTPs to route directly to the final domain, source Moore/Vaudreuil Expires 20 May 1995 [Page 11]
Delivery Status Notifications 20 November 1994 routes are still allowed. If the recipient address as originally specified is available in RFC 822 addr-spec format, the Recipient field should contain that address. Otherwise, the Recipient field should contain the closest available recipient address to that specified by the sender, as expressed in RFC 822 addr-spec format. This address may not correspond to the address as originally sent because it may have been transformed during forwarding and gatewaying into an totally unrecognizable mess. In the absence of the optional original-recipient field, the Recipient field and any returned content may be all the information available to correlate the DSN with a particular message transaction. Although domain names are case-insensitive, the case of alphabetic characters in the local-part of the addr-spec must be preserved. 3.2.1.2 action field The action field indicates the reason the DSN was issued. 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" 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 final MTA has abandoned any attempts to deliver the message to this recipient. No further notifications should be expected. "delayed" indicates that the final 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 expander. 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. Moore/Vaudreuil Expires 20 May 1995 [Page 12]
Delivery Status Notifications 20 November 1994 "relayed" indicates that the message has been relayed or gatewayed into an environment that does not accept responsibility for generating DSNs according to this specification. Additional notification messages may be provided by the "remote" environment that may or may not conform to this specification. (However, for subsequent notifications, the 'original-recipient' field will almost certainly not be included because it will no longer be available.) NOTE ON ACTION VS. STATUS CODES: Although the 'action' field appears to be redundant with the 'status' field, this is not the case. In particular, a 4XX status value could be used with an action-value of either "delayed" or "failed". 3.2.1.3 status field The per-recipient status field contains a 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 = 3*DIGIT "status" uses the set of reply codes from SMTP [3] and its extensions ([8], [9]), with additions to support indication of error conditions that can never result from an SMTP dialogue. If an SMTP reply code is not available, the closest match should be chosen from either the set of SMTP reply codes or the additional codes listed in an appendix. Although status-codes are purely numeric, explanatory text may be included as a comment in parentheses following the status-code. NOTE: These "new" codes should only appear in delivery status notifications. The creation of "new" status-codes for delivery status notifications DOES NOT extend the legal set of reply codes to be used with the SMTP protocol. The structure of DSN status-codes is described in an appendix to this memo. 3.2.1.4 date field The "date" field gives the date and time of the last delivery attempt (whether successful or unsuccessful) by the final MTA. Note that this may not be the same as the date header field of the message used to transmit this delivery status notification. In cases where the DSN was Moore/Vaudreuil Expires 20 May 1995 [Page 13]
Delivery Status Notifications 20 November 1994 generated by a gateway, the RFC 822 header will contain the time the message was sent and the DSN date field should be the time the notification event occurred. date-field = "Date" ":" date-time This field is optional. It SHOULD 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. 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" ":" xtext This field is optional. 3.2.1.6 expiry-date field For DSNs of type "delay", the "expiry-date" field gives the date after which the final MTA expects to abandon all attempts to deliver the message to that recipient. expiry-date-field = "Expiry-Date" ":" date-time The date and time are expressed in RFC 822 'date-time' format. Numeric timezones ([+/-]HHMM format) MUST be used. 3.2.2 MTS-specific Per-recipient fields NOTE: Unless otherwise stated, the syntax for a MTS-specific Per- recipient field is: mts-specific-field = field-name ":" xtext This reflects the ability to carry any kind of addresses, MTA names, or status codes. A particular MTS-type may place restrictions on the allowable values for MTS-specific fields when that MTS-type is used. With the exception of MTS-type fields, all MTS-specific fields are case sensitive. The final-MTA must not change the case of any values reported in these fields. Moore/Vaudreuil Expires 20 May 1995 [Page 14]
Delivery Status Notifications 20 November 1994 3.2.2.5 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. If the message originated outside of the Internet, the original- recipient field will not necessarily contain an RFC 822-style recipient address. However, if the original-mts-type field is present, the original-recipient address MUST conform to the conventions of the the original-mts-type. 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 ESMTP 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. 3.2.2.6 final-recipient field The final-recipient field contains the electronic mail address of the recipient at the time the message was accepted for delivery by the final MTA. This field is optional. If the final-mts-type field is present, the syntax of the final- recipient field MUST conform to the syntax for that MTS-type. 3.2.2.7 final-status field The value associated with the final-status DSN field should be a printable ASCII representation of a MTS-specific status code that indicates the final MTA's precise reason for the success or failure to to this recipient. The possible values for this field are specific to the final-mts-type. This field is optional. 3.2.2.8 remote-mts-type field The value associated with remote-mts-type DSN field is the MTS type of the "remote" MTA, as defined in section 2 of this document. This field is optional. It SHOULD NOT be included if no remote MTA was involved in the attempted delivery of the message to that recipient. 3.2.2.9 remote-mta field Moore/Vaudreuil Expires 20 May 1995 [Page 15]
Delivery Status Notifications 20 November 1994 The value associated with the remote-mta DSN field should be a printable ASCII representation of the name of the "remote" MTA that reported delivery status to the "final" MTA. NOTE: The remote-mta field preserves the "while talking to" information that was provided in some pre-existing non-delivery reports. This field is optional. It SHOULD NOT be included if no remote MTA was involved in the attempted delivery of the message to that recipient. The conventions for the name of the remote-mta field are specific to the remote MTS-type. 3.2.2.10 remote-recipient field The value associated with the remote-recipient DSN field should be a printable ASCII representation of the recipient address as presented to the "remote" MTA in an attempt by the "final" MTA to relay the message. The conventions of the remote-recipient address are specific to the remote MTS-type. This field is optional. It SHOULD NOT be included if its value is the same as that of the final-recipient DSN field. 3.2.2.11 remote-status field The value associated with the remote-status DSN field should be a printable ASCII representation of the status value returned by the remote MTA to the final MTA in response to the final MTA's attempt to relay the message to the remote MTA. The conventions for interpreting the remote-status DSN field are specific to the remote MTS-type. This field is optional, because some mail systems supply no additional information beyond that which is returned in the 'action' and 'status' fields. 3.2.2.12 Extension fields Per-recipient extension fields may also be defined, using the same syntax as for per-message extension field. 4. Extension Mechanism for DSNs The DSN body part includes several extensible fields. The extensible fields are: Moore/Vaudreuil Expires 20 May 1995 [Page 16]
Delivery Status Notifications 20 November 1994 (a) New Status Codes New status codes may be defined to reflect error conditions which are not covered either by existing SMTP reply codes or by the additional codes defined in section 10.1 of this memo. New codes must be consistent with the theory of status codes defined in section 10, and MUST be defined in a published RFC. NOTE IN DRAFT: I (KM) am leaving this section as-is until the WG gets consensus on whether to define a new status code scheme or extend the existing SMTP scheme. (b) New MTS types New MTS-type names may be defined to allow the carriage of foreign address and status code information in mts-specific DSN fields. New MTS-types must be defined in a published RFC, which ideally should include a complete specification for exchanging mail between the Internet and the foreign MTS-type. At a minimum, the definition of an additional MTS-type should include: (1) the proposed MTS-type name (2) the syntax of addresses for that MTS-type, as they are to be represented in DSN fields (3) the syntax of MTA names for that MTS-type (4) the syntax of status codes for that MTS-type, along with a list of the codes that are valid NOTE: A definition for the INTERNET MTS-type appears in section 11 of this memo. (c) New DSN Fields Additional per-message or per-recipient DSN fields may be defined by any extension to this memo that is published as an RFC. These fields should be used only to contain additional information needed to tunnel or report information from foreign systems. In the event the DSN fields defined in this memo are insufficient for reporting delivery attempts in Internet mail, this specification as a whole should be revised. Extension field names that are specific to a particular MTS-type should begin with the MTS-type name and a hyphen. For example: a field called "X400-Remote-MTA-Brain-Death" would be specific to the "X400" MTS-type. Extension field names beginning with "X-" are reserved for experimental use. 5. Conformance and Usage Requirements Moore/Vaudreuil Expires 20 May 1995 [Page 17]
Delivery Status Notifications 20 November 1994 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. A minimal implementation of this specification will generate only the Recipient, Action, and Status fields. However, generation of the other fields is strongly recommended. MTAs and gateways MUST NOT generate the "original-recipient" field of a DSN unless the mail transfer protocol ensures that the address provided is the one 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 DSN is requested for a message that is forwarded to multiple recipients, the forwarding MTA should normally issue a "relayed" DSN for the originally-specified recipient and not propagate the request for a DSN to the forwarding addresses. Alternatively, the forwarding MTA can relay the request for a DSN to exactly one of the forwarding addresses and not propagate the request to the others. 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 expander, the final 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 Appendix 14.) This specification places no restrictions on the processing of DSNs received by user agents or distribution lists. 6. Security considerations The following security considerations apply when using DSNs: 6.1 Forgery Moore/Vaudreuil Expires 20 May 1995 [Page 18]
Delivery Status Notifications 20 November 1994 DSNs may be forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list expanders) 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 receipt of: + A falsified delivery notification when the message as not delivered, + A falsified non-delivery notification when the message was delivered, + A falsified final recipient address, + A falsified remote-mta identification, + A falsified relay notification when the message is "dead ended". + Unsolicited DSNs 6.2 Confidentality 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 messaes 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 confidentality 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 were requested) when a message were forwarded to a confidential forwarding address, and disabling requests for positive DSNs for the forwarded message, b) omitting the "remote-*" fields of a DSN whenever they would otherwise contain a confidential forwarding address, c) for messages forwarded to a confidential address, setting the envelope return address (e.g. SMTP MAIL FROM address) to the empty string (so that no DSNs could be issued), or d) 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 it were the originator. After obtaining final delivery status, it would issue a "proxy" DSN to the original sender. 6.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 "failure" DSN can not be relied upon as a guarantee that a message was Moore/Vaudreuil Expires 20 May 1995 [Page 19]
Delivery Status Notifications 20 November 1994 not received by the recipient. Even if DSNs are not actively forged, conditions exist under which a message can be delivered despite the fact that a failure DSN was issued. For example, a race condition in the SMTP protocol allows for the duplication of messages if the connection is dropped following a completed DATA command, but before a response is seen by the SMTP client. This will cause the SMTP client to retransmit the message, even though the SMTP server has already accepted it. If one of those delivery attempts succeeds and the other one fails, a "failure" DSN could be issued even though the message actually reached the recipient. 7. Acknowledgments The authors wish to thank the following people for their reviews of earlier drafts of this document and their suggestions for improvement: Harald Alvestrand, Allan Cargille, Jim Conklin, Ned Freed, John Klensin, Mark Nahabedian, Jean Charles Roy, and Gregory Sheehan. 8. References [1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993. [2] Moore, K., Vaudreuil, G. "Multipart/Report", Internet-Draft. [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", Internet-Draft. [5] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [6] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-Ascii Text", RFC 1522, University of Tennessee, September 1993. [7] Braden, R. "Requirements for Internet Hosts - Application and Support" RFC 1123, October 1989. [8] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. "SMTP Service Extensions" RFC 1651, MCI, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc, July 1994. [9] Klensin, J., Freed, N., Moore, K. "SMTP Service Extension for Message Size Declaration" RFC 1653, MCI, Innosoft International, Moore/Vaudreuil Expires 20 May 1995 [Page 20]
Delivery Status Notifications 20 November 1994 Inc., University of Tennessee, July 1994. 9. Author's Addresses Keith Moore University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA email: moore@cs.utk.edu Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA email: Greg.Vaudreuil@Octel.Com Moore/Vaudreuil Expires 20 May 1995 [Page 21]
Delivery Status Notifications 20 November 1994 10. Appendix - Theory of status-codes The first digit of the status-code is defined as follows: 2yz Positive Completion status Final delivery of the message has been successfully completed. 4yz Transient Negative Completion status Attempts to deliver the message have been abandoned because of the persistence of "transient" failures. However, the error condition appears to be temporary and the sender may wish to resend the message. In SMTP, 4yz reply codes indicate conditions where the SMTP client is allowed to "try again later" to deliver a message. However, if delivery attempts continue to fail, eventually the client will "give up". At this the client should issue a DSN. The last 4yz reply code obtained from the SMTP server should be reported as the status-code. 5yz Permanent Negative Completion status The message could not be delivered because of some permanent error associated with the recipient address. The sender should not attempt to resend the message to that recipient. 6yz Indeterminate Completion status This group of status codes is used when a message is relayed or gatewayed into a mail system from which any requested DSNs may not be returned. No further notifications should be expected for this message and recipient. However, they may be issued, perhaps with incomplete information. The second digit of the status-code is defined as follows: x0z Syntax These replies refer to syntax errors, syntactically-correct commands that don't fit any functional category, and unimplemented or superfluous commands. x2z Connections These replies refer to the transmission channel. x5z Mail system These replies indicate the status of the receiver mail system vis- Moore/Vaudreuil Expires 20 May 1995 [Page 22]
Delivery Status Notifications 20 November 1994 a-vis the requested transfer or other mail system action. x6z External servers These replies indicate the status of any external servers that are not an integral part of the mail system but whose operation is necessary for the correct delivery of mail. The third digit of the status-code gives a finer gradation of meaning. 10.1 New status-codes for DSNs In addition to the reply codes defined for SMTP, the following codes are usable as status-codes in DSNs: 400 Unspecified temporary failure This code is a "fallback" to be used when translating temporary failure codes from foreign mail systems, when no more precise status-code is available. 426 Temporary communications failure This code indicates a "temporary" failure to establish communications with a host or network for which communications is necessary to deliver the message. Such failures would include "host unreachable", "network unreachable", and "connection refused" codes. 466 Temporary routing lookup failure This code indicates a "temporary" failure to locate information necessary to route a message. Such failures would include unanswered Domain Name Server queries, or other queries of database servers that are necessary to route a message. 500 Unspecified permanent failure This code is a "fallback" to be used when translating permanent failure codes from foreign mail systems when no better status-code is available. 601 Message relayed; expect no further notifications This code is issued for messages for which a positive DSN was requested but which were successfully relayed or gatewayed into an environment which does not support such notifications. Moore/Vaudreuil Expires 20 May 1995 [Page 23]
Delivery Status Notifications 20 November 1994 11. Appendix - definition of the INTERNET MTS-type The INTERNET MTS-type is hereby defined to refer to what is commonly known as Internet mail. This includes all electronic mail systems which (a) use the RFC 822 and/or MIME protocols for the message content, (b) use RFC 822-style sender and recipient addresses in their envelopes, with domains registered in the Internet domain name system (DNS) (including domains registered under "wildcard" mail exchanger (MX) records), and (c) exchange such messages with the IP-connected Internet. The INTERNET MTS is not limited to those systems using SMTP. MTS-type-name: INTERNET Address-syntax: Addresses for the INTERNET MTS must be in the "addr- spec" format defined in RFC 822 (with an optional "route" prefix), using fully-qualified domain names which are registered with the DNS. MTA-name-syntax: An INTERNET MTA-name shall be the fully-qualified domain name of the MTA issuing the DSN. The address Postmaster@{mta- name} must be a valid address by which the maintainer of that MTA may be reached. Status-codes: Status codes for the INTERNET MTS consist of three decimal digits. The initial set of status codes consists of the the set of SMTP reply codes (including those defined by SMTP extensions), along with the additional codes defined in appendix 10 of this memo. Moore/Vaudreuil Expires 20 May 1995 [Page 24]
Delivery Status Notifications 20 November 1994 12. Appendix - collected grammar delivery-status-content = per-message-fields *( CRLF per-recipient-fields ) per-message-fields = [ original-mts-type-field CRLF ] [ original-envelope-id-field CRLF ] [ final-mts-type-field CRLF ] final-mta-field CRLF [ received-from-field CRLF ] [ arrival-date-field CRLF ] *( extension-field CRLF ) original-mts-type-field = "Original-MTS-Type" ":" mts-type original-envelope-id-field = "Original-Envelope-Id" ":" envelope-id envelope-id = xtext final-mts-type-field = "Final-MTS-Type" ":" mts-type final-mta-field = "Final-MTA" ":" xtext arrival-date-field = "Arrival-Date" ":" date-time extension-field = extension-field-name ":" xtext extension-field-name = atom per-recipient-fields = basic-fields mts-specific-fields basic-fields = recipient-field CRLF action-field CRLF status-field CRLF [ date-field CRLF ] [ final-log-id-field CRLF ] [ expiry-date-field CRLF ] mts-specific-fields = [ original-recipient-field CRLF ] [ final-recipient-field CRLF ] [ final-status-field CRLF ] [ remote-mts-type-field CRLF ] [ remote-mta-field CRLF ] [ remote-recipient-field CRLF ] [ remote-status-field CRLF ] *( extension-field CRLF ) recipient-field = "Recipient" ":" [route] addr-spec action-field = "Action" ":" action-value Moore/Vaudreuil Expires 20 May 1995 [Page 25]
Delivery Status Notifications 20 November 1994 status-field = "Status" ":" status-code date-field = "Date" ":" date-time final-log-id-field = "Final-Log-ID" ":" xtext expiry-date-field = "Expiry-Date" ":" date-time original-recipient-field = "Original-Recipient" ":" xtext final-recipient-field = "Final-Recipient" ":" xtext final-status-field = "Final-Status" ":" xtext remote-mts-type-field = "Remote-MTS-Type" ":" mts-type remote-mta-field = "Remote-MTA" ":" xtext remote-recipient-field = "Remote-Recipient" ":" xtext remote-status-field = "Remote-Status" ":" xtext action-value = "failed" / "delayed" / "delivered" / "relayed" status-code = 3*DIGIT mts-type = atom ; NOTE: For fields whose field-body is defined as 'xtext', ; the normal RFC 822 special characters are not used. ; text enclosed in paraenthesis is treated as a comment, ; but such comments are not considered separators for ; the purpose of lexical analysis. Except for comments ; and escaped-crlf's, all characters are significant. ; RFC 1522 encoded-words may NOT be used in xtext. xtext = *( xchar / hexchar / escaped-crlf ) xchar = any ASCII CHAR between SPACE (32) and TILDE (126) inclusive, except for "#", "\" and "(". ; "hexchar"s are used to encode octets that cannot be represented ; as plain text, either because they are reserved, or because ; they are non-printable. hexchar = ASCII "#" immediately followed by two upper case hexadecimal digits ; An escaped-crlf may appear at the end of a line to allow the ; field to be continued to the next line without inserting any ; white space. Moore/Vaudreuil Expires 20 May 1995 [Page 26]
Delivery Status Notifications 20 November 1994 escaped-crlf = "\" immediately followed by the characters: CR LF SPACE Moore/Vaudreuil Expires 20 May 1995 [Page 27]
Delivery Status Notifications 20 November 1994 13. 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. 13.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. The information may be transmitted in the mts-specific fields of a DSN that are defined in this memo, or if necessary, in extension fields. The gateway MUST attempt to supply reasonable values for the per- recipient 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 status from the foreign system. In this case, the gateway should make a best effort, falling back on "generic" codes such as 200 (success), 400 (temporary failure), and 500 (permanent failure) when necessary. The sender-specified recipient address, if available, should be preserved in the original-recipient field. The gateway should also attempt to preserve the "final" recipient addresses, mta names, and status codes from the foreign system. Because DSN fields are limited to the ASCII character set, it may be necessary to encode foreign protocol elements as printable ASCII values. The encoding method is specific to the MTS-type from which the delivery report is being received. "remote" values, when available, should be similarly preserved. If it is desirable to provide transparent tunneling of the foreign delivery status notifications through Internet mail, the gateway specification may define per-recipient extension fields to carry additional mts-specific information as necessary. 13.2 Gatewaying from DSNs to other mail systems A DSN may be gatewayed from the Internet to 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. Moore/Vaudreuil Expires 20 May 1995 [Page 28]
Delivery Status Notifications 20 November 1994 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, and the latest available delivery status code. Each of these must be in the original sender's format. If the original-recipient address is available, and the original-mts- type matches the destination MTS, the original-recipient address should be provided in the resulting foreign delivery status report. Otherwise, the gateway may translate the "canonical" recipient address into the convention required by the destination system. The final- or remote- recipient addresses may also be used. However, due to address translation and mail forwarding, these may have little or no resemblance to the original recipient address. If the remote-status code is available and the remote-mts-type matches the MTS to which the DSN is being gatewayed, the remote-status code can be used directly. Otherwise, if the final-mts-type matches the destination MTS, the final-status code may be used. Failing that, the "canonical" status-code may be mapped into the set of status codes used by the destination MTS. If it is possible to tunnel a DSN through the destination MTS, the gateway specification may define a means of preserving the DSN information in the delivery status reports used by the destination MTS. Such encapsulation will necessarily be specific to that particular MTS. Moore/Vaudreuil Expires 20 May 1995 [Page 29]
Delivery Status Notifications 20 November 1994 14. Appendix - Guidelines for use of DSNs by mailing list expanders DSNs are designed to be used by mailing list expanders 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 expander 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 expander 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 one of the 'status' codes and the 'action' field. Recipients with action values other than "failed" can generally be ignored; in particular, subscribers should not be removed from a list due to "delayed" DSNs. The latest possible status code understood by the list expander should be used; the 'remote- status' code is best, followed by the 'final-status' code (if the codes for the final or remote MTS-type are understood by the list expander), and finally the 'status' code. In general, almost any failure status code (even a "permanent" one) can result from a temporary condition. It is therefore recommended that a list expander not delete a subscriber based on any single failed 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. When choosing whether to delete a subscriber, it may be useful to differentiate between the status codes. For example, on a list with a high message volume, it might be desirable to temporarily suspend delivery to a recipient address which causes repeated "temporary" failures, rather than simply deleting the recipient. The duration of the suspension might depend on the type of error. On the other hand, a "user unknown" error which persists for several days can usually be considered a reliable that that address is no longer valid. Moore/Vaudreuil Expires 20 May 1995 [Page 30]
Delivery Status Notifications 20 November 1994 Moore/Vaudreuil Expires 20 May 1995 [Page 31]
Delivery Status Notifications 20 November 1994 15. 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 MTS-type names or extension fields in these examples is not to be construed as a definition for those MTS-types or extension fields. These examples were manually translated from bounced messages using whatever information was available. Moore/Vaudreuil Expires 20 May 1995 [Page 32]
Delivery Status Notifications 20 November 1994 15.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 Original-MTS-Type: INTERNET Final-MTS-Type: INTERNET Final-MTA: cs.utk.edu Recipient: louisl@larry.slip.umd.edu Action: failed Status: 426 (connection timed out) Date: Thu, 7 Jul 1994 17:15:49 -0400 Original-Recipient: louisl@larry.slip.umd.edu --RAA14128.773615765/CS.UTK.EDU content-type: message/rfc822 [original message goes here] --RAA14128.773615765/CS.UTK.EDU-- Moore/Vaudreuil Expires 20 May 1995 [Page 33]
Delivery Status Notifications 20 November 1994 15.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 Original-MTS-Type: INTERNET Final-MTA: cs.utk.edu Final-MTS-Type: INTERNET Recipient: arathib@vnet.ibm.com Action: failed Status: 550 ('arathib@vnet.IBM.COM' is not a registered gateway user) Remote-MTS-Type: INTERNET Remote-MTA: vnet.ibm.com Original-Recipient: arathib@vnet.ibm.com Recipient: johnh@hpnjld.njd.hp.com Action: delayed Status: 466 (hpnjld.njd.jp.com: host name lookup failure) Original-Recipient: johnh@hpnjld.njd.hp.com Recipient: wsnell@sdcc13.ucsd.edu Action: failed Status: 550 (user unknown) Remote-MTS-Type: INTERNET Remote-MTA: sdcc13.ucsd.edu Original-Recipient: wsnell@sdcc13.ucsd.edu --JAA13167.773673707/CS.UTK.EDU content-type: message/rfc822 [original message goes here] --JAA13167.773673707/CS.UTK.EDU-- Moore/Vaudreuil Expires 20 May 1995 [Page 34]
Delivery Status Notifications 20 November 1994 Moore/Vaudreuil Expires 20 May 1995 [Page 35]
Delivery Status Notifications 20 November 1994 15.3 A delivery report generated by Message Router (MAILBUS) and gatewayed by PMDF_MR to a DSN. I assume that PMDF_MR could have preserved the MAILBUS status code in the DSN (NOTE IN DRAFT: right Ned?), I just don't know what it would be. 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 Final-MTA: SYS30 Final-MTS-Type: mailbus Recipient: nair_s@SYS30.timeplex.com Status: 500 (unknown failure) Action: failed Final-Recipient: nair_s Final-Status: ??? (no matching directory entry found) --[;84229080704991/122306@SYS30]-- Moore/Vaudreuil Expires 20 May 1995 [Page 36]
Delivery Status Notifications 20 November 1994 15.4 A delay report from a multiprotocol MTA. Note that there is no returned content; so no third body part 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 Final-MTS-Type: INTERNET Final-MTA: sun2.nsfnet-relay.ac.uk Recipient: thomas@de-montfort.ac.uk Status: 400 (unknown temporary failure) Action: delayed --foobar-- Moore/Vaudreuil Expires 20 May 1995 [Page 37]
Delivery Status Notifications 20 November 1994 15.5 A DSN gatewayed from a X.400 nondelivery notification From: "UK.AC.NSF MTA" <postmaster@nsfnet-relay.ac.uk> To: na-digest-bounces@netlib2.cs.utk.edu Subject: Delivery Report (failure) for sdz009@prime.napier.ac.uk Date: Mon, 11 Jul 1994 02:09:43 +0100 Message-ID: <"sun3.nsfne.309:11.06.94.01.09.27"@nsfnet-relay.ac.uk> content-type: multipart/report; report-type=delivery-status; boundary=foobar --foobar content-type: text/plain This report relates to your message: Subject: NA Digest, V. 94, # 27, Message-ID: <199407031824.OAA23971@localhost>, To: na-digest list:; of Sun, 3 Jul 1994 19:47:56 +0100 Your message was not delivered to sdz009@prime.napier.ac.uk for the following reason: Message timed out --foobar content-type: message/delivery-status Final-MTS-Type: X400 Final-MTA: sun3.nsfnet-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/ Recipient: sdz009@prime.napier.ac.uk Action: failed Status: 400 (unknown temporary failure) Final-Recipient: /S=sdz009/OU=prime/O=napier/PRMD=UK.AC/ADMD= /C=GB/ Final-Status: 1/5 (unable-to-transfer/maximum-time-expired) X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD= /C=gb/ arrival Sun, 3 Jul 1994 19:47:56 +0100 action Relayed X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD= /C=gb/ arrival Sun, 3 Jul 1994 19:24:03 +0100 action Relayed --foobar content-type: message/rfc822 [returned content] --foobar-- Moore/Vaudreuil Expires 20 May 1995 [Page 38]
Delivery Status Notifications 20 November 1994 16. Appendix - changes since the July 14 draft 1. Title and order of paragraphs in section 3 changed to describe the overall structure of the message before the description of the message/delivery-status content-type. 2. Some text added to section 3 to explicitly state that comments and continuation lines are allowed in the same manner as in RFC 822. 3. Some fields are now explicitly marked as case-sensitive or case-insensitive. 4. "Rcpt" is now spelled "Recipient" in notification fields, and the "INET" MTS-Type is now "INTERNET". 5. "X-" MTS-types are now allowed. 6. Received-From field added. 7. Section 3.2.1.2: added example to show how action and status-codes work, contrasting conversion-with-loss with conversion-prohibited. 8. Changed 'xchar' grammar to disallow the characters "(", "#", and "\"; added "#"XX notation for hexadecimal encoding; added "\" CR LF SPACE notation to allow transparent continuation of lines. 9. Section 3.2.1.3: clarified "MUST be present for each recipient" -> "MUST be present for each delivery attempt...". 10. Section 3.2.2.6: deleted the text which said that the final-recipient field shouldn't appear if it is redundant with either original-recipient or recipient. 11. Section 3.2.2.11: fixed incomplete sentence. 12. Section 5: added note about the use of DSNs by mailing lists. 13. Appendix 10: removed description of x1z status-codes; these are useful in SMTP (e.g. HELP command) but are not applicable to delivery status reports. 15. Added text to clarify the difference between original, final, and remote MTAs. 15. Add text to suggest that subject, date, and message-id be retained in the third (returned content) body part of a DSN. 16. Added some prose to (sort-of) define "MTS". 17. Added Arrival-date per-message field. Moore/Vaudreuil Expires 20 May 1995 [Page 39]
Delivery Status Notifications 20 November 1994 18. Added Expiry-date per-recipient field. 19. Added more prose to say that (a) a single DSN can describe delivery status for multiple recipients of the same message, but (b) the delivery status for all recipients of the same message doesn't have to be in a single DSN, and (c) a single DSN cannot describe delivery events for multiple messages. 20. Expanded the security considerations section. 21. Explicitly allow the first body part of a DSN to be a multipart/alternative. 22. Add a note to the effect that comments may be used in the status-code field. 23. Added an appendix about use of DSNs by mailing lists. 24. Renumbered references. 25. Added prose in the acknowledgements section. (Please let me know if I've left anybody out! -km) 26. Explicitly allow encoded-words in comments. 27. Allow an optional "route" to appear in the 'recipient' field, and in {final,remote}-recipient fields of the "internet" mts-type. 28. Fix a few troff glitches. STILL TO DO 1. Change "original-xxx" to "earliest-xxx" (if I can find the right words...) 2. Figure out and describe how to treat DSNs which result from multi-recipient mail forwarding. Intentions: (a) make the result unambiguous and meaningful to the sender, (b) uniform handling - don't make handing of "delivered" DSNs too different from "relayed/delayed/failed" DSNs. Moore/Vaudreuil Expires 20 May 1995 [Page 40]