Network Working Group Greg Vaudreuil Internet Draft Tigon Expires 3/17/93 September 17, 1993 Delivery Report Content-Type for use with MIME 1. 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". 2. Abstract The memo defines a MIME content type for the return of delivery reports, service availability, and receipt notifications. This content type is intended to be machine processable while remaining human readable. 3. Introduction The current Internet Mail protocol suite is lacking in several features necessary to the management of large mailing lists and for error processing on behalf of a user. There is no standard error report format which would facilitate implementation of user friendly mail interfaces. This content type defines a mechanism for delivery reports which is extensible for a range of system to user notification services such as read receipt delivery, positive delivery acknowledgment, and service non-availability notification. 3.1. Non-Delivery Notification The Internet currently provides for error reports, but in a non-standard and limited use format. This specification is intended to replace these error reports with a more standard mechanism. SMTP provides a standardized status reporting system in the use of numeric reply-codes but these are not generally made available in the error message mailed to the sender. The SMTP error codes do not provide a complete diagnostic record and need to be extended for the purposes of delivery reports to include non-SMTP network and communications errors which may cause non-delivery. 3.2. Positive Delivery Notification The RFC822/MHS mapping standards identify a mechanism for requesting such a delivery notification and this specification provides a mechanism to return such a request. For the purposes of the Delivery Notification, delivery will be considered completed when the message is delivered to the destination mailbox. 3.3 Read Receipt Notification There is a mechanism specified in the RFC822/MHS documents for requesting a read receipt notification. While the specific implementation of such a notification has been contentious, this specification provides a mechanism for sending such a notification if one is to be implemented. The specific meaning of "read" varies by implementation environment and is left undefined. 3.4 Service Notification MIME allows the sending of mixed-media messages and in particular messages which are not text. There is no specific mechanism for reporting to the sender when such a message is deliverable but not readable. 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. Determination of what is a supported and what is an unsupported feature is an implementation issue 4. Delivery Report Framework The delivery report mechanism is implemented by defining two new MIME content-types, Multipart/Delivery-Report and Application/Delivery-Report. The multipart/delivery report is the syntactically the same as a multipart/mixed but contains exactly two parts, the first is the Application/Delivery-Report and the second is a return of content. If return of content is not requested or supported, the Multipart/Delivery Report is not needed. The Application/Delivery-Report contains the specific delivery information, such as error reports, read-receipts, and service notifications. This content-type is formatted according to the Simple Text Interchange Format and contains information for machine processing of the message. STIF Comments are permitted where appropriate for human consumption in the absence of an application capable of interpreting the error report. 5. Multipart/Delivery-Report Mime type name: Multipart Mime Sub-Type name: Delivery-Report Required Parameters: Boundary Optional Parameters: None Encoding Considerations: Quoted-Printable and Base-64 are prohibited. The syntax of a Multipart/Delivery-Report is identical to the Multipart\Mixed content type. The Delivery Report always contains two body parts. The first body part is an Application/Delivery-Report, defined in a subsequent section of this appendix. The second body part may be of any content-type and contains the returned message for which the delivery report is defined. The returned comment will normally be a message/RFC822. If an Application/Delivery-Report does not include returned content, Multipart/Delivery-Report should not be used. 6. Application/Delivery-Report Mime type name: Application Mime Sub-Type name: Delivery-Report Required Parameters: None Optional Parameters: None Encoding Considerations: 7bit is always sufficient. The Application/Delivery-Report body is designed to deliver delivery and non-delivery reports, read-receipts, and service notifications. It is generally used with a Multipart/Delivery-Report when the original content is to be returned to the sender. The Application/Delivery Report is a series of attribute-value pairs formatted as RFC 822 headers. While this body-part is designed to be machine parsable, US-ASCII comments are permitted in each line. Generation of error messages from this error report for user consumption should be based on the error code, not the explanatory text. Choice of an appropriate language and character set is independent of the error. The choice of US ASCII for the explanatory text is based on current practice and is expected to be obsoleted by nationalized user interfaces. 6.1. Required Attributes. o Message-ID: - message id of the message being reported on o Intended-Recipient - a coma separated list of one or more recipient email addresses for which this report applies. o Delivery-Status - This field indicates whether further delivery attempts will be made. (Finished, Continuing) 6.2 Service Specific Attributes o Message-Delivered - Time of message delivery o Message-Not-Delivered - Time of failed attempt o MTA-Error-Code - Error code returned which caused delivery notification to be returned. The set of error codes defined by the SMTP protocol is extended to address general network errors. o Service-Not-Available - MIME content type of service not supported on the destination mailbox. o Message-Read - Time message was read 6.2. MTA Error Codes The following non-delivery error codes are available from SNMP for direct peer-to-peer networking. The 400 series of error codes are "soft" failures, indicating that re-try is reasonable at a later time. 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 The 500 series of error codes are "hard" failures, indicating that the message should be returned to the sender as undeliverable. The listed commands are a subset of the full SNMP diagnostics. 500 Syntax error, command unrecognized This may include errors such as command line too long] 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 550 Requested action not taken: mailbox unavailable, mailbox not found, no access 551 User not local; please try 552 requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 554 Transaction Failed 6.3. Network 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 Application/Delivery-Report content type. A new series of error codes, 6XX is created to report on such failures. 600 Host unreachable. The network address of the host specified is not connected to the MTA. 610 Network Unreachable. The network the host resides upon is either not connected to the MTA. 620 Hostname does not exist. A non existent destination was provided. 630 Service not available. SMTP on TCP port 25 is not available. 7. Return of Content 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. This can be done with the RFC822/MHS header "return content". The three values for this field are "none", "full", and "initial". The default behavior in the absence of this header varies by application and should be set by the MTA. Return of full content uses significant bandwidth but enables review and resending with a different addresses or formats. Return of content can be provided with caching without using additional network bandwidth. Outgoing messages can be cached for a suitable period of time, and if a non-delivery, service notification, or read-receipt is received, it can be matched with the cached message and presented to the user. Return of a partial message segment may be sent to remind the sender of the topic of the message. This saves bandwidth compared with sending the full message, but may either not be enough of the message for context or be unsuitable for further processing. Handling of partial content is tricky in a mixed media environment. Return of partial content may be useless for certain content-types. Each content-type has a natural "unit" which should be respected in returning a partial content. For example, a text message should include enough text to capture at least the first paragraph. A fax content should include sufficient information to print the cover page. A audio segment should contain enough data for several seconds of play time. Each of these units varies in the number of bytes and cannot be implemented in a useful manner by arbitrary truncation. It is recommended that a gateway return full or no content. It should return partial content only if it has knowledge of how to truncate that content. The following are recommended units for truncation. Multipart/* Return first body part Image/* Return one page Audio/* Return 10 seconds Text/* Return 1 page 8. Example Delivery Reports 8.1. Complete Non-Delivery Notification The following error message was sent to the user 2145551212 on message machine HOST1.mycompany.com because the message addressed to 2145551234 does not exist on message machine HOST2.mycompany.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". Note that this is not relevant to the user. To: 2145551212@host1.mycompany.com From: postmaster@host2.mycompany.com Mime-Version: 1.0 Date: Mon, 3 Fri 93 13:39:31 PDT Message-ID: HOST2.mycompany.com-1212121212 Content-type: Multipart/Delivery-Report; boundary = "error-report-boundary" --error-report-boundary content-type: Application/Delivery-Report Message-Id: host1.mycompany.com-123456789 Intended-recipient: 2145551234@host2.mycompany.com Delivery-Status: Finished Message-Not-Delivered: Fri, 3 Sep 93 13:39:31 PDT MTA-Error-Code: 550 (Invalid mailbox) --error-report-boundary Content-type: Audio/U-Law Content-Transfer-Encoding: Base64 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd dflksdlkfIasdrkfpWlqkw3okWlkgf9i345kWlfkg9iugp34k5poi09fg jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW krQgi35oktWldkfbrpouqe5yklm2poTihcvxbQkmstyTi5ryToifnglkj dlkgpokpeowrit09IpokporkgwI== --error-report-boundary-- 8.2. Example Read Receipt Message The following delivery report was sent to user 2145551212 on machine host1.mycompany.com after the message sent to 2145551234 on machine HOST2.mycompany.com was read. No return of content was requested. To: 2145551212@host1.mycompany.com From: 2145551234@host2.mycompany.com Message-ID: HOST2.mycompany.com-1212121212 Mime-Version: 1.0 Date: Mon, 3 Fri 93 13:39:31 PDT Content-type: Application/Delivery-Report Message-Id: host1.mycompany.com-123456789 Intended-recipient: 2145551234@host2.mycompany.com Delivery-Status: Finished Message-Read: Fri, 3 Sep 93 13:39:31 PDT 9. Security Considerations Delivery 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 reports may provide a mechanism for denial-of-service attacks. 10. Authors Address Gregory M. Vaudreuil Tigon Corporation 17060 Dallas Parkway Suite 109 Dallas, Texas 75248-1905 (214) 733 2722 GregV@cnri.reston.va.us