Network Working Group Keith Moore Internet Draft University of Tennessee Expires: January 14, 1995 Greg Vaudreuil Octel Network Services July 14, 1994 An Extensible Message Format for Delivery Status Notifications draft-ietf-notary-mime-delivery-02.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 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 a "work in progress". Abstract This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or inter-network 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 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 [8]. This memo defines only the format of the notifications. An extension to the Simple Message Transfer Protocol (SMTP) to fully support such notifications is the subject of a separate memo [5]. 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 Moore/Vaudreuil Expires 14 January 1995 [Page 1] Delivery Status Notifications 14 July 1994 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 a message delivery, as well as the reasons for any delivery 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 a remote MTA maintainer so that she understands 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 the sender of a message (or his user agent) 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 + 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. Moore/Vaudreuil Expires 14 January 1995 [Page 2] Delivery Status Notifications 14 July 1994 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. Each of these addresses is useful under some circumstances. The original recipient address is needed by the message sender to be able to associate a DSN with the recipient specified in the message. The "final" form of the address is needed when reporting a problem to a remote postmaster. When interpreting a DSN, the sender's user agent will want the "remote" status code if it is available. Either the "final" form or the "remote" form of an address may be useful to a gateway which must translate a MIME DSN into the format required by a foreign mail system. 3. 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 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". Moore/Vaudreuil Expires 14 January 1995 [Page 3] Delivery Status Notifications 14 July 1994 A complete DSN is a MIME message with a top-level content-type of multipart/report. 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.) The first component of the multipart/report should be a human- readable text message that summarizes, in prose, the delivery status information that is presented in detail in the message/delivery-status component. The second component of the multipart/report must be the message/delivery-status content described in section 3 of this memo. The third and final component of the multipart/report should contain either the entire message as received by the final MTA or, if at all possible, the headers of that message. 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 should be omitted. The body of a message/delivery-status consists of one or more "fields" formatted according to the ABNF of RFC 822 header "fields". 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 *( CRLF per-recipient-fields ) These fields are described in detail below. Several fields exist to identify the "MTS type" of the original, final, or remote MTA. An MTS-type is a identifier for a particular mail system which is registered with the Internet Assigned Numbers Authority (IANA). 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-rcpt address must be an X.400 recipient address, and the final-status code must be an X.400-style error code. Moore/Vaudreuil Expires 14 January 1995 [Page 4] Delivery Status Notifications 14 July 1994 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 ] *( 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. This field is optional. 3.1.2 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. There may be at most one original-envelope-id field per DSN. The original-envelope-id line is defined as follows: original-envelope-id-field = "Original-Envelope-Id" ":" envelope-id envelope-id = xtext 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. Moore/Vaudreuil Expires 14 January 1995 [Page 5] Delivery Status Notifications 14 July 1994 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-mta-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. 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 ARRIVED at that MTA. 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 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 3.1.5. 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. Moore/Vaudreuil Expires 14 January 1995 [Page 6] Delivery Status Notifications 14 July 1994 The syntax for the group of per-recipient fields is as follows: per-recipient-fields = basic-fields mts-specific-fields basic-fields = rcpt-field CRLF action-field CRLF status-field CRLF [ date-field CRLF ] [ final-log-id-field CRLF ] mts-specific-fields = [ original-rcpt-field CRLF ] [ final-rcpt-field CRLF ] [ final-status-field CRLF ] [ remote-mts-type-field CRLF ] [ remote-mta-field CRLF ] [ remote-rcpt-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 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-rcpt, 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 Rcpt field The Rcpt 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: rcpt-field = "Rcpt" ":" addr-spec Moore/Vaudreuil Expires 14 January 1995 [Page 7] Delivery Status Notifications 14 July 1994 The value following the Rcpt field contains the RFC 822 mailbox of the recipient address. The address MUST be in RFC 822 "addr-spec" format, and MUST contain the fully-qualified domain name of the recipient's domain. If the recipient address as originally specified is available in RFC 822 addr-spec format, the Rcpt field should contain that address. Otherwise, the Rcpt field should contain the closest available recipient address to that specified by the sender. 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-rcpt field, the Rcpt field and any returned content may be all the information available to correlate the DSN with a particular message transaction. 3.2.1.2 action field The action field indicates the reason the DSN was issued. This field MUST be present for each recipient. 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. "relayed" indicates that the message has been relayed or gatewayed Moore/Vaudreuil Expires 14 January 1995 [Page 8] Delivery Status Notifications 14 July 1994 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-rcpt' field will not be included.) NOTE: 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 recipient. 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 and its extensions, 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. 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 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 Moore/Vaudreuil Expires 14 January 1995 [Page 9] Delivery Status Notifications 14 July 1994 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.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, as long as they can be represented as printable ASCII characters. A particular MTS-type may place restrictions on the allowable values for MTS-specific fields when that MTS-type is used. 3.2.2.5 original-rcpt field The "original-rcpt" 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-rcpt field will not necessarily contain an RFC 822-style recipient address. However, if the original-mts-type field is present, the original-rcpt 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 [5]. This address is the same as that provided by the sender and can be used to automatically correlate DSN reports and message transactions. Moore/Vaudreuil Expires 14 January 1995 [Page 10] Delivery Status Notifications 14 July 1994 3.2.2.6 final-rcpt field The final-rcpt 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-rcpt field MUST conform to the syntax for that MTS-type. The final-rcpt field SHOULD NOT be included if either (a) the 'original- rcpt' field is present for this recipient and its value is the same as the final-rcpt value, or (b) the value specified in the 'rcpt' field is the same as the final-rcpt value. 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, that is, the one that reported the result of the delivery attempt to the "final" MTA which issued the DSN. This field is optional. It SHOULD NOT be included in a DSN if the final MTA had ultimate responsibility for delivery of the message. 3.2.2.9 remote-mta field The value associated with the remote-mta DSN field should be a printable ASCII representation 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 in the DSN fields for a recipient unless the final MTA had ultimate responsibility for the delivery of the message to that recipient. The conventions for the name of the remote-mta field are specific to the remote MTS-type. Moore/Vaudreuil Expires 14 January 1995 [Page 11] Delivery Status Notifications 14 July 1994 3.2.2.10 remote-rcpt field The value associated with the remote-rcpt 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-rcpt 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-rcpt 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 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: (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. (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 Moore/Vaudreuil Expires 14 January 1995 [Page 12] Delivery Status Notifications 14 July 1994 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 INET 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: MTS-type. Extension field names beginning with "X-" are reserved for experimental use. 5. Conformance and Usage Requirements An MTA or gateway conforms to this specification if it generates DSNs according to the protocol defined in this memo. For MTAs and gateways that do not support requests for positive delivery notification (such as in [5]), it is sufficient that delivery failure reports use this protocol. A minimal implementation of this specification will generate only the Rcpt, Action, and Status fields. However, generation of the other fields is strongly recommended. MTAs and gateways MUST NOT generate the "original-rcpt" 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 [5] 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 Moore/Vaudreuil Expires 14 January 1995 [Page 13] Delivery Status Notifications 14 July 1994 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. This specification places no restrictions on the processing of DSNs received by user agents or distribution lists. 6. Security considerations 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. 7. Acknowledgments (watch this space) 8. References [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] Westine, A., Postel, J. "Problems with the Maintenance of Large Mailing Lists", RFC 1211, USC/Information Sciences Institute, March 1991. [4] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992. [5] Moore, K. "SMTP Service Extension for Delivery Status Notifications", Internet Draft. [6] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. "SMTP Service Extensions" RFC 1425, United Nations University, Innosoft Moore/Vaudreuil Expires 14 January 1995 [Page 14] Delivery Status Notifications 14 July 1994 International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. [7] Klensin, J., Freed, N., Moore, K. "SMTP Service Extension for Message Size Declaration" RFC 1427, United Nations University, Innosoft International, Inc., University of Tennessee, February 1993. [8] Moore, K., Vaudreuil, G. "Multipart/Report", Internet-Draft (in preparation) 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 14 January 1995 [Page 15] Delivery Status Notifications 14 July 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. x1z Information These are replies to requests for information, such as status or help. x2z Connections Moore/Vaudreuil Expires 14 January 1995 [Page 16] Delivery Status Notifications 14 July 1994 These replies refer to the transmission channel. x5z Mail system These replies indicate the status of the receiver mail system vis- 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 Moore/Vaudreuil Expires 14 January 1995 [Page 17] Delivery Status Notifications 14 July 1994 requested but which were successfully relayed or gatewayed into an environment which does not support such notifications. Moore/Vaudreuil Expires 14 January 1995 [Page 18] Delivery Status Notifications 14 July 1994 11. Appendix - definition of the INET MTS-type The INET MTS-type 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), and (c) exchange such messages with the IP-connected Internet. The INET MTS is not limited to those systems using SMTP. MTS-type-name: INET Address-syntax: Addresses for the INET MTS must be in the "addr-spec" format defined in RFC 822, using fully-qualified domain names which are registered with the DNS. MTA-name-syntax: An INET 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 INET 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 14 January 1995 [Page 19] Delivery Status Notifications 14 July 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 ] *( 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 extension-field = extension-field-name ":" xtext extension-field-name = atom per-recipient-fields = basic-fields mts-specific-fields basic-fields = rcpt-field CRLF action-field CRLF status-field CRLF [ date-field CRLF ] [ final-log-id-field CRLF ] mts-specific-fields = [ original-rcpt-field CRLF ] [ final-rcpt-field CRLF ] [ final-status-field CRLF ] [ remote-mts-type-field CRLF ] [ remote-mta-field CRLF ] [ remote-rcpt-field CRLF ] [ remote-status-field CRLF ] *( extension-field CRLF ) rcpt-field = "Rcpt" ":" addr-spec action-field = "Action" ":" action-value status-field = "Status" ":" status-code date-field = "Date" ":" date-time final-log-id-field = "Final-Log-ID" ":" xtext Moore/Vaudreuil Expires 14 January 1995 [Page 20] Delivery Status Notifications 14 July 1994 original-rcpt-field = "Original-Rcpt" ":" xtext final-rcpt-field = "Final-Rcpt" ":" xtext final-status-field = "Final-Status" ":" xtext remote-mts-type-field = "Remote-MTS-Type" ":" mts-type remote-mta-field = "Remote-MTA" ":" xtext remote-rcpt-field = "Remote-Rcpt" ":" 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', ; special characters and comments are NOT recognized. ; encoded-words may NOT be used in xtext xtext = *(any ASCII CHAR between SPACE (32) through TILDE (126) inclusive) Moore/Vaudreuil Expires 14 January 1995 [Page 21] Delivery Status Notifications 14 July 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 Rcpt, 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-rcpt 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 14 January 1995 [Page 22] Delivery Status Notifications 14 July 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-rcpt address is available, and the original-mts-type matches the destination MTS, the original-rcpt address should be provided in the resulting foreign delivery status report. Otherwise, the gateway may translate the "canonical" rcpt address into the convention required by the destination system. The final- or remote- rcpt 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 14 January 1995 [Page 23] Delivery Status Notifications 14 July 1994 14. 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 14 January 1995 [Page 24] Delivery Status Notifications 14 July 1994 14.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 Original-MTS-Type: INET Final-MTS-Type: INET Final-MTA: cs.utk.edu Rcpt: louisl@larry.slip.umd.edu Action: failed Status: 426 (connection timed out) Date: Thu, 7 Jul 1994 17:15:49 -0400 Original-Rcpt: 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 14 January 1995 [Page 25] Delivery Status Notifications 14 July 1994 14.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 Original-MTS-Type: INET Final-MTA: cs.utk.edu Final-MTS-Type: INET Rcpt: arathib@vnet.ibm.com Action: failed Status: 550 ('arathib@vnet.IBM.COM' is not a registered gateway user) Remote-MTS-Type: INET Remote-MTA: vnet.ibm.com Original-Rcpt: arathib@vnet.ibm.com Rcpt: johnh@hpnjld.njd.hp.com Action: delayed Status: 466 (hpnjld.njd.jp.com: host name lookup failure) Original-Rcpt: johnh@hpnjld.njd.hp.com Rcpt: wsnell@sdcc13.ucsd.edu Action: failed Status: 550 (user unknown) Remote-MTS-Type: INET Remote-MTA: sdcc13.ucsd.edu Original-Rcpt: 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 14 January 1995 [Page 26] Delivery Status Notifications 14 July 1994 Moore/Vaudreuil Expires 14 January 1995 [Page 27] Delivery Status Notifications 14 July 1994 14.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 (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 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 Rcpt: nair_s@SYS30.timeplex.com Status: 500 (unknown failure) Action: failed Final-Rcpt: nair_s Final-Status: ??? (no matching directory entry found) --[;84229080704991/122306@SYS30]-- Moore/Vaudreuil Expires 14 January 1995 [Page 28] Delivery Status Notifications 14 July 1994 14.4 A delay report from a multiprotocol MTA. Note that there is no returned content; so no third body part 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 Final-MTS-Type: INET Final-MTA: sun2.nsfnet-relay.ac.uk Rcpt: thomas@de-montfort.ac.uk Status: 400 (unknown temporary failure) Action: delayed --foobar-- Moore/Vaudreuil Expires 14 January 1995 [Page 29] Delivery Status Notifications 14 July 1994 14.5 A DSN gatewayed from a X.400 nondelivery notification From: "UK.AC.NSF MTA" 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/ Rcpt: sdz009@prime.napier.ac.uk Action: failed Status: 400 (unknown temporary failure) Final-Rcpt: /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 14 January 1995 [Page 30]