HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:58:21 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 21 Nov 1994 23:00:00 GMT ETag: "304aa2-12bad-2ed12670" Accept-Ranges: bytes Content-Length: 76717 Connection: close Content-Type: text/plain 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 | 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: 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 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: 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 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: 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: 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" 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]