Network Working Group Greg Vaudreuil Internet-Draft Tigon Corporation Expires 7/22/94 January 22th, 1993 An Extensible Message Format for Delivery Status Notifications Note: See Appendix for changes from previous version. 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 The memo defines a MIME content type for the return of non- delivery, delayed message, service availability, and other message status notifications to the sender. This content type is intended to be a machine processable alternative to the full range of error messages currently sent on the Internet and to provide a general mechanism for reporting message status information to a users mail agent. 1.Introduction The current Internet mail protocol suite is lacking in standard mechanism for the handling of mail system errors, both on behalf of users and for computer assisted management of large mailing lists. There are few standards which would facilitate implementation of user friendly mail interfaces. This document defines an extensible format for the exchange of delivery status notifications. The current Internet mail system returns unsolicited non-delivery notifications. This document defined a mechanism whereby these notifications can be implemented using this format. This document also provides for a mechanism for reporting two new classes of non-delivery notifications expected to become common with the deployment of the Multipurpose Internet Mail Extensions (MIME) and Privacy Enhanced Mail (PEM). It is likely that new delivery report types will be needed, including positive delivery acknowledgment and read receipt notification. As these new delivery report types are defined, and in particular, as the mechanism for requesting those reports Internet Draft Delivery Status November 22, 1993 are specified, the values for the delivery service notification can be extended. 2.Delivery Status Notification Framework The Delivery Status mechanism is implemented by defining two new MIME content-types, Multipart/Delivery-Status and Text/Delivery- Status. The Multipart/Delivery-Status is syntactically the same as a multipart/mixed but contains exactly two parts, the first is the Text/Delivery-Status and the second is a return of content. If return of content is not requested or supported, the Text/Delivery-Status may be send without Multipart/Delivery- Status. The Text/Delivery-Status contains the specific service notification information, such as error reports, read-receipts, and service unsupported notifications. This content-type is formatted according to the rules for RFC 822 headers and contains information for machine processing of the message. RFC 822 comments are permitted where appropriate for human consumption in the absence of a parser capable of interpreting the service notification. Note: Limitations in the format for RFC 822 headers and the necessity in places to structure sets of recipient addresses may argue for use of the Structured Text Interchange Format (STIF) or a lightweight SGML implementation - Please comment. (This means you DCrocker!) Return of content may be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally the sender should choose the appropriate strategy and inform the recipient of the required level of returned content required. In the absence of any clear mechanism for requesting a level of return of content, the agent which generated the delivery service notification should return the full message content. Vaudreuil Expires 7/22/94 [Page 2] Internet Draft Delivery Status November 22, 1993 3.Multipart/Delivery-Status Mime type name: Multipart Mime Sub-Type name: Delivery-Status Required Parameters: Boundary Optional Parameters: None Encoding Considerations: Quoted-Printable and Base-64 are prohibited. The syntax of a Multipart/Delivery-Status is identical to the Multipart/Mixed content type. The Delivery Status may contain two or three body parts. If present, a text/plain body part with a human friendly text description of the error should be the first body part. The next, or first body part, if the text/plain part is present, is an Text/Delivery-Status, defined in a subsequent section of this appendix. The last body part may be of any content-type and contains the returned message for which the Delivery Status is defined. The returned comment will normally be a message/RFC822, or the content type message/sample defined in this document. If an Text/Delivery-Status does not include returned content, or a text description of the error, Multipart/Delivery-Status should not be used. Vaudreuil Expires 7/22/94 [Page 3] Internet Draft Delivery Status November 22, 1993 4.Text/Delivery-Status Mime type name: Text Mime Sub-Type name: Delivery-Status Required Parameters: None Optional Parameters: None Encoding Considerations: 7bit is always sufficient. The Text/Delivery-Status body provides delivery status notifications. It is generally used with a Multipart/Delivery- Status when the original content is to be returned to the sender. The Text/Delivery-Status is a series of attribute-value pairs formatted as RFC 822 headers. While this body-part is designed to be machine parsable, RFC 822 comments are permitted in each line. Text values in character sets other than US ASCII must be formatted using the RFC 1522 encoded-word. Generation of error messages from this error report for user consumption should be based on the notification code, not the explanatory text. Choice of an appropriate language and character set is independent of the error. Applications implementing this delivery status notification body part are expected to provided localized descriptions of the errors based on the notification code. The choice of US ASCII for the explanatory text in comments is an interim measure based on current practice for ease of transition. 4.1. Generic Service Notification Attributes The following notification attributes are defined for all delivery status notifications. o Message-ID: - The RFC 822 message-id of the message causing this delivery service notification. o Envelope-Identifier: - The serial identifier of the message envelope if one exists. This corresponds to the X.400 MTS Identifier. o Intended-Recipient:- A coma separated list of one or more recipient email addresses for which this report applies. These are the addresses as presented by the (E)SMTP envelope RCPT-TO commands. o Original-Recipients: - A coma separated list of one or more recipient email addresses as specified in the original SMTP envelope. These addresses if included must correspond on a one to one basis with the intended recipient attributes. o Recipient-Tags: - A coma separated list of one or more recipient address tags. These tags are used by X.400 to identify recipients and correlate error reports. When Vaudreuil Expires 7/22/94 [Page 4] Internet Draft Delivery Status November 22, 1993 provided, these tags must correspond on a one to one basis with the intended recipients attributes. o Sending-MTA: - The fully qualified domain address of the MTA originating the message notification. o Date: - The date and time according to the RFC822 "date-time" of the notification event. o Action: - The service notification type. The initially defined action type is "Failed", that is, the message could not be delivered. o MTA-Notification-Code: - The response code returned which caused message notification to be returned. The set of response codes defined by the SMTP protocol is extended to address general network notification events. 4.2. Extension Mechanism for Delivery Status Notifications The delivery status notification body part include several generic attribute value fields needed to correlate incoming service delivery reports to the originally sent message and recipients. The following mechanisms are permitted for extension. o New attributes may be defined as needed to convey information beyond that possible with the generic attributes. o New action keywords may be defined to indicate the current message status. o New MTA notification-codes may be defined as needed to indicate the specific event resulting in the delivery status notification. New mechanisms for correlating error reports, notification events, and indicating the intended recipients are prohibited. This is necessary to insure that new delivery service notifications are compatible with and generally useful without understanding the specific notification provided. In the event the generic attributes are insufficient for this task, this specification as a whole should be revised. Vaudreuil Expires 7/22/94 [Page 5] Internet Draft Delivery Status November 22, 1993 5.Message/Sample Mime type name: Message Mime Sub-Type name: Sample Required Parameters: None Optional Parameters: None Encoding Considerations: Any suitable content-transfer encoding may be used. The message/sample is defined as containing the returned headers and body of an RFC 822 message which cannot be guaranteed to be complete or which cannot be returned without transfer encoding. A message transfer agent or a mail gateway may receive a message fragment which should be returned to the sender. If there is no guarantee that the message is a complete untruncated message, labeling it as Message/RFC822 may be incorrect. In the case where the message is a multipart message formatted according to the MIME conventions, a truncated message may no longer be parsable as indicated in the content-type. Message/RFC822 messages may also not be transfer encoded. A MTA or gateway which has received a returned message may not be able to determine the content-type when required to return the message. The message/sample may be encoded as needed to return the message to the sender. Vaudreuil Expires 7/22/94 [Page 6] Internet Draft Delivery Status November 22, 1993 6.Initially defined Delivery Status Notification Types 6.1. MTA Non Delivery Notifications The Internet currently provides non-delivery reports, but in a non-standard and difficult to use format. This specification is intended to replace these error reports with a standard mechanism. SMTP provides a standardized status reporting system in the use of numeric reply-codes. The delivery status notification mechanism provides a mechanism to make these error codes available to the sender. Because the SMTP response codes do not provide a complete diagnostic record, this specification has extended the set of response codes to include non-SMTP network and communications conditions which may cause non-delivery. 6.1.1. Framework for the MTA Failure notification type The following delivery service notification is defined: o The name of the delivery service notification is "MTA Failure". o The list of response codes includes all permanent SMTP and ESMTP error codes and the additional codes defined in this document. o No additional attributed types are defined. o No additional action types are defined. Non-delivery notifications must be implemented in such a manner that only a single delivery notification is generated per message. The non-delivery notification should be send only when further delivery attempts will not be performed. 6.1.2. SMTP/ESMTP Error Codes SMTP provides a rich set of non-delivery error codes for reporting on the status of a SMTP transaction. The 500 series of error codes are "hard" failures, indicating that the command cannot be completed. Not all these errors require reporting the message as undeliverable. The listed commands are a subset of the full SMTP diagnostics useful in the Delivery-Status context. 550 Requested action not taken: mailbox unavailable, mailbox not found, no access 552 Requested mail action aborted: exceeded storage allocation Vaudreuil Expires 7/22/94 [Page 7] Internet Draft Delivery Status November 22, 1993 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 554 Transaction Failed 6.1.3. Network or System Error Codes Often mail transfer failures result from network or transport level conditions which are not part of the SMTP protocol. These errors are generally made known in current error reports, but need to be assigned numeric codes to be used in the Text/Delivery-Status content type. The following error codes are defined to communicate these system failures. These are derived from the SMTP error code convention of permanent (5XX) connection (X2X) errors. 522 Host unreachable. The host specified is not connected to the MTA. 522 Network Unreachable. The network the host resides upon is either not connected to the MTA or unreachable due to routing problems. 523 Host name does not exist. A non existent destination was provided. 524 Service not available. SMTP on TCP port 25 is not available. Vaudreuil Expires 7/22/94 [Page 8] Internet Draft Delivery Status November 22, 1993 6.1.4. Example Non-Delivery Message The following error message was sent to the user Keith on message machine cs.utk.edu because the message addressed to Greg was mis- addressed and does not exist on message machine Tigon.com. The error message was sent by the mail program itself and not on behalf of a particular user and therefor has the From: address of "Postmaster". To: Moore@cs.utk.edu From: postmaster@Tigon.com Mime-Version: 1.0 Date: Mon, 3 Fri 93 13:39:31 PDT Message-ID: Tigon.com-1212121212 Content-type: Multipart/Delivery-Status; boundary = "service-notification-boundary" --service-notification-boundary content-type: Text/Delivery-Status Message-Id: cs.utk.edu-123456789 Intended-recipient: GregZ@Tigon.com Action: Failed Date: Fri, 3 Sep 93 13:39:31 PDT MTA-Notification-Code: 550 (Invalid mailbox) Sending-MTA: Tigon.com --service-notification-boundary Content-type: Message/Sample Content-Transfer-Encoding: 7bit Received: ...... Received: ...... To: GregZ@Tigon.com From: Moore@cs.utk.edu Subject: This is a test of your new address Date: Fri, 3 Sep 93 13:36:12 PDT This is a test message Keith --service-notification-boundary-- Vaudreuil Expires 7/22/94 [Page 9] Internet Draft Delivery Status November 22, 1993 6.2. Unsupported Service Notification The Multi-purpose Internet Mail Extensions (MIME) protocol enables the sending of rich multi-media messages. The lack of directory services makes it likely that a message will be sent which cannot be viewed or converted to a media type which can be viewed. There is no defined mechanism for reporting to the sender when such a message is deliverable but not readable or processable. In many messaging environments, it may be useful to return a message to the sender indicating that the specified content-type is unsupported. It is expected that this information will be cached, either informally by a human user, or by a local directory for use by the user agent. This unsupported service notification extension provides a mechanism to report media conversion errors. At this time there is no defined mechanism to request or prohibit message conversion. Even in the absence of any defined mechanism, this notification type is useful for reporting failures when a recipient may attempt to convert a content as required for successful delivery. 6.2.1. Framework for the Unsupported Service Notifications The following delivery service notification is defined: o The name of this delivery service notification is "Service Failure". o The list of response codes is extended by this service notification type. o One additional attributed types is defined, "Service-Not- Available". This attribute may contain one or more coma separate MIME content type designators which could not be viewed by the recipient. o No additional action types are defined. Determination of what is a supported and what is an unsupported feature and the mechanisms by which a user agent may report non- support of content is left as an implementation choice. Note that a user may have resources beyond his mail reading program by which to process new content-types. Only one service notification may be sent per message. Service notifications are to be generated in such a manner that subsequent delivery or read attempts will not result in additional service notifications. Vaudreuil Expires 7/22/94 [Page 10] Internet Draft Delivery Status November 22, 1993 6.2.2. Service Failure Codes A new series of error codes is defined to report these errors. These errors are permanent (5XX) service (X6X) errors. 560 Content not supported. 561 Implicit conversion to a media type usable by the recipient is prohibited by the sender. 562 Conversion to a media type supported by the recipient is not possible. 563 Conversion to a media type supported by the recipient is not practical. Vaudreuil Expires 7/22/94 [Page 11] Internet Draft Delivery Status November 22, 1993 6.2.3. Example Unsupported Service Message The following Delivery Status Notification was sent to user Keith on machine cs.utk.edu when his fax image message sent to Greg on machine Tigon.com could not be viewed. No return of content was requested. To: Moore@cs.utk.edu From: GregV@Tigon.com Message-ID: Tigon.com-1212121212 Mime-Version: 1.0 Date: Mon, 3 Fri 93 13:39:31 PDT Content-type: Multipart/Delivery-Status; boundary = "service-notification-boundary" --service-notification-boundary content-type: Text/Delivery-Status Message-Id: cs.utk.edu-123456789 Intended-recipient: GregV@Tigon.com Action: Failed MTA-Notification-code: 560 (Media type is not supported) Date: Fri, 3 Sep 93 13:39:31 PDT Sending-MTA: Tigon.com Service-Not-Available: Image/G3fax --service-notification-boundary Content-type: Message/Sample Content-Transfer-Encoding: 7bit Received: ...... To: GregV@Tigon.com From: Moore@cs.utk.edu Subject: This is a test of your new address Date: Fri, 3 Sep 93 13:36:12 PDT Mime-Version: 1.0 Content-Type: Image/G3Fax Content-Transfer-Encoding: Base-64 ...... --service-notification-boundary-- Vaudreuil Expires 7/22/94 [Page 12] Internet Draft Delivery Status November 22, 1993 6.3. Delayed Message Notifications It is common practice in the Internet to send a notification to the message originator when a message is delayed beyond a reasonable time. While these messages are simply advisory, it is useful to report the delay in a standardized format to enable automated sorting and if reasonable, discard. Multiple delayed message notifications may be sent as the delay accumulates. 6.3.1. Framework for Delayed Message Notifications The following delivery service notification is defined: o The name of this delivery service notification is "Delayed Message". o The list of response codes include all temporary failure response codes from SMTP and ESMTP and the new codes defined in this document. o One additional attributed types is defined, "Message-Status". This attribute will indicate the additional time for which future delivery attempts will be made. The value is a positive integer representing the number of hours the message will remain in queue. o One new action type is defined, "Delayed". This action type indicates that the message has been queued for further processing. o Return of content is not appropriate for this delivery service notification type. 6.3.2. Delayed Message Codes The 400 series of response codes are "soft" failures, indicating that re-try is reasonable at a later time. These errors should only be reported if the message is queued for future delivery attempts. If these conditions are permanent, they must be reported as a non-delivery notification using 5XX codes . 421 Service not available, [This may be a reply to any command if the service knows it must shut down] 450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage Vaudreuil Expires 7/22/94 [Page 13] Internet Draft Delivery Status November 22, 1993 Often mail transfer delays result from network or transport level conditions which are not part of the SMTP protocol. These conditions are generally made known in current error reports, but need to be assigned numeric codes to be used in the Text/Delivery-Status content type. The following error codes are defined to communicate these system delays. These are derived from the SMTP error code convention of temporary (4XX) connection (X2X) errors. 424 Service not available. SMTP on TCP port 25 is not available. 422 Host unreachable. The host specified is not connected to the MTA. 6.3.3. Example Delayed Message Notice The following message was sent to Keith on machine cs.utk.edu reporting that the mail machine Tigon.com was temporarily unavailable and that delivery attempts will continue for 3 days. To: Moore@cs.utk.edu From: GregV@Tigon.com Message-ID: Tigon.com-1212121212 Mime-Version: 1.0 Date: Mon, 3 Fri 93 13:39:31 PDT Content-type: Text/Delivery-Status Action: Delayed Intended-recipient: GregV@Tigon.com Message-Status: 72 (Delivery attempts will continue for 3 days) Date: Fri, 3 Sep 93 13:39:31 PDT MTA-Notification-Code: 422 (Host unreachable) Message-Id: cs.utk.edu-123456789 Sending-MTA: Tigon.com Vaudreuil Expires 7/22/94 [Page 14] Internet Draft Delivery Status November 22, 1993 6.4. Security Failure Notification Type Privacy Enhanced Mail and other mail security protocols provide the ability to protect a message content from modification. This protection may render a message unsuitable for gatewaying into a new environment or unreadable by a recipient without the appropriate security keys. 6.4.1. Framework for Security Failure Message Notifications The following delivery service notification is defined: o The name of this delivery service notification is "Delayed Message". o The list of response codes include all temporary failure response codes from SMTP, ESMTP, and the MTA Failure service notification type. o No additional attributed types is defined. o No additional action type is defined. 6.4.2. Security Failure Codes A new series of error codes is defined to report these conditions. These response codes are permanent (5XX) security- related (X7X) errors. 570 Message could not viewed due to security protection 571 Message could not be relayed due to security protection Vaudreuil Expires 7/22/94 [Page 15] Internet Draft Delivery Status November 22, 1993 7.Security Considerations Message notifications are only as secure as the mechanism by which they have been sent. It is important to note that automatic deletion of an address from a mailing list based on delivery status notifications may provide a mechanism for denial- of-service attacks. 8.Authors Address Gregory M. Vaudreuil Tigon Corporation 17060 Dallas Parkway Suite 109 Dallas, Texas 75248-1905 (214) 733 2722 Gvaudre@cnri.reston.va.us Vaudreuil Expires 7/22/94 [Page 16] Internet Draft Delivery Status November 22, 1993 Appendix - Changes from previous draft o An optional Text/Plain body part can now be included in the multipart/Delivery-Report. The text attributed has been deleted in favor of this optional description. The text/plain body part facilitates the use of non-ascii based languages and is not subject to the formatting requirements of the attribute/value syntax. Vaudreuil Expires 7/22/94 [Page 17]