idnits 2.17.1 draft-ietf-notary-mime-delivery-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 32 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 286: '...The DSN MUST be addressed (in both the...' RFC 2119 keyword, line 292: '...e header of the DSN SHOULD contain the...' RFC 2119 keyword, line 297: '...address, the From field of the DSN MAY...' RFC 2119 keyword, line 301: '...dress of the DSN SHOULD be chosen to e...' RFC 2119 keyword, line 305: '...and MUST be chosen so that DSNs will n...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1482 has weird spacing: '... The usual...' == Line 1488 has weird spacing: '... You will ...' == Line 1523 has weird spacing: '...ered to sdz0...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 January 1995) is 10682 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1521 (ref. '1') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 822 (ref. '6') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1522 (ref. '7') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet Draft University of Tennessee 3 Expires: 20 July 1995 Greg Vaudreuil 4 Octel Network Services 5 20 January 1995 7 An Extensible Message Format 8 for Delivery Status Notifications 10 draft-ietf-notary-mime-delivery-04.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This memo defines a MIME content-type that may be used by a message 33 transfer agent (MTA) or electronic mail gateway to report the result of 34 an attempt to deliver a message to one or more recipients. This 35 content-type is intended as a machine-processable replacement for the 36 various types of delivery status notifications currently used in 37 Internet electronic mail. 39 Because many messages are sent between the Internet and other messaging 40 systems (such as X.400 or the so-called "LAN-based" systems), the DSN 41 protocol is designed to be useful in a multi-protocol messaging 42 environment. To this end, the protocol described in this memo provides 43 for the carriage of "foreign" addresses and error codes, in addition to 44 those normally used in Internet mail. Additional attributes may also be 45 defined to support "tunneling" of foreign notifications through Internet 46 mail. 48 Delivery Status Notifications 20 January 1995 50 1. Introduction 52 This memo defines a MIME [1] content-type for delivery status 53 notifications (DSNs). A DSN can be used to notify the sender of a 54 message of any of several conditions: failed delivery, delayed 55 delivery, successful delivery, or the gatewaying of a message into an 56 environment that may not support DSNs. The "message/delivery-status" 57 content-type defined herein is intended for use within the framework of 58 the "multipart/report" content type defined in [2]. 60 This memo defines only the format of the notifications. An extension to 61 the Simple Message Transfer Protocol (SMTP) [3] to fully support such 62 notifications is the subject of a separate memo [4]. 64 1.1. Purposes 66 The DSNs defined in this memo are expected to serve several purposes: 68 + Inform human beings of the status of message delivery processing, as 69 well as the reasons for any delivery problems or outright failures, in 70 a manner which is largely language-independent; 72 + Allow mail user agents to keep track of the delivery status of 73 messages sent, by associating returned DSNs with earlier message 74 transmissions; 76 + Allow mailing list expanders to automatically maintain their 77 subscriber lists when delivery attempts repeatedly fail; 79 + Convey delivery and non-delivery notifications resulting from attempts 80 to deliver messages to "foreign" mail systems via a gateway; 82 + Allow "foreign" notifications to be tunneled through a MIME-capable 83 message system and back into the original messaging system that issued 84 the original notification, or even to a third messaging system; 86 + Allow language-independent, yet reasonably precise, indications of the 87 reason for the failure of a message to be delivered (once status codes 88 of sufficient precision are defined); and 90 + Provide sufficient information to remote MTA maintainers (via "trouble 91 tickets") so that they can understand the nature of reported errors. 92 This feature is used in the case that failure to deliver a message is 93 due to the malfunction of a remote MTA and the sender wants to report 94 the problem to the remote MTA administrator. 96 Delivery Status Notifications 20 January 1995 98 1.2. Requirements 100 These purposes place the following constraints on the notification 101 protocol: 103 + It must be readable by humans as well as being machine-parsable. 105 + It must provide enough information to allow message senders (or the 106 user agents) to unambiguously associate a DSN with the message that 107 was sent and the original recipient address for which the DSN is 108 issued (if such information is available), even if the message was 109 forwarded to another recipient address. 111 + It must be able to preserve the reason for the success or failure of a 112 delivery attempt in a remote messaging system, using the "language" 113 (mailbox addresses and status codes) of that remote system. 115 + It must also be able to describe the reason for the success or failure 116 of a delivery attempt, independent of any particular human language or 117 of the "language" of any particular mail system. 119 + It must preserve enough information to allow the maintainer of a 120 remote MTA to understand (and if possible, reproduce) the conditions 121 that caused a delivery failure at that MTA. 123 + For any notifications issued by foreign mail systems, which are 124 translated by a mail gateway to the DSN format, the DSN must preserve 125 the "type" of the foreign addresses and error codes, so that these may 126 be correctly interpreted by gateways. 128 A DSN contains a set of per-message fields which identify the message 129 and the transaction during which the message was submitted, along with 130 other fields that apply to all delivery attempts described by the DSN. 131 The DSN also includes a set of per-recipient fields to convey the result 132 of the attempt to deliver the message to each of one or more recipients. 134 1.3. Terminology 136 A message may be transmitted through several message transfer agents 137 (MTAs) on its way to a recipient. For a variety of reasons, recipient 138 addresses may be rewritten during this process, so each MTA may 139 potentially see a different recipient address. Depending on the purpose 140 for which a DSN is used, different formats of a particular recipient 141 address will be needed. 143 Several DSN fields are defined in terms of the view from a particular 144 MTA in the transmission. The MTAs are assigned the following names: 146 Delivery Status Notifications 20 January 1995 148 a. Original MTA 150 The Original MTA is the one to which the message is submitted for 151 delivery by the sender of the message. 153 Note: Each time a message is re-sent to a completely different set of 154 recipients (say to the subscribers of a mailing list), the Original MTA 155 for the new recipients of that message is the one to which the message 156 is initially submitted for delivery to the new list of recipients. 158 b. Reporting MTA 160 For any DSN, the Reporting MTA is the one which is reporting the results 161 of delivery attempts described in the DSN. 163 If the delivery attempts described occurred in a "foreign" (non- 164 Internet) mail system, and the DSN was produced by translating the 165 foreign notice into DSN format, the Reporting MTA will still identify 166 the "foreign" MTA where the delivery attempts occurred. 168 c. Preceding MTA 170 The Preceding MTA is the MTA from which the Reporting MTA received the 171 message, and accepted responsibility for delivery of the message. 173 d. Remote MTA 175 If an MTA determines that it must relay a message to one or more 176 recipients, but the message cannot be transferred to its "next hop" MTA, 177 or if the "next hop" MTA refuses to accept responsibility for delivery 178 of the message to one or more of its intended recipients, the relaying 179 MTA may need to issue a DSN on behalf of the recipients for whom the 180 message cannot be delivered. In this case the relaying MTA is the 181 Reporting MTA, and the "next hop" MTA is known as the Remote MTA. 183 Figure 1 illustrates the relationship between the various MTAs: 185 +-----+ +--------+ +---------+ +---------+ +------+ 186 | | => |Original| => ... => |Preceding| => |Reporting| ===> |Remote| 187 | user| | MTA | | MTA | | MTA | 1330 Message-Id: <199407072116.RAA14128@CS.UTK.EDU> 1331 Subject: Returned mail: Cannot send message for 5 days 1332 To: 1333 MIME-Version: 1.0 1334 Content-Type: multipart/report; report-type=delivery-status; 1335 boundary="RAA14128.773615765/CS.UTK.EDU" 1337 --RAA14128.773615765/CS.UTK.EDU 1338 The original message was received at Sat, 2 Jul 1994 17:10:28 -0400 1339 from root@localhost 1341 ----- The following addresses had delivery problems ----- 1342 (unrecoverable error) 1344 ----- Transcript of session follows ----- 1345 ... Deferred: Connection timed out 1346 with larry.slip.umd.edu. 1347 Message could not be delivered for 5 days 1348 Message will be deleted from queue 1350 --RAA14128.773615765/CS.UTK.EDU 1351 content-type: message/delivery-status 1353 Final-MTA: dns; cs.utk.edu 1355 Original-Recipient: rfc822; louisl@larry.slip.umd.edu 1356 Final-Recipient: rfc822; louisl@larry.slip.umd.edu 1357 Action: failure 1358 Status: 4.0.0 1359 Diagnostic-Code: smtp; 426 (connection timed out) 1360 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1362 --RAA14128.773615765/CS.UTK.EDU 1363 content-type: message/rfc822 1365 [original message goes here] 1366 --RAA14128.773615765/CS.UTK.EDU-- 1368 Delivery Status Notifications 20 January 1995 1370 11.2 This is another DSN issued by the sender's MTA, which 1371 contains details of multiple delivery attempts. Some of these were 1372 detected locally, and others by a remote MTA. 1374 Date: Fri, 8 Jul 1994 09:21:47 -0400 1375 From: Mail Delivery Subsystem 1376 Subject: Returned mail: User unknown 1377 To: 1378 MIME-Version: 1.0 1379 Content-Type: multipart/report; report-type=delivery-status; 1380 boundary="JAA13167.773673707/CS.UTK.EDU" 1382 --JAA13167.773673707/CS.UTK.EDU 1383 content-type: text/plain; charset=us-ascii 1384 ----- The following addresses had delivery problems ----- 1385 (unrecoverable error) 1386 (unrecoverable error) 1388 --JAA13167.773673707/CS.UTK.EDU 1389 content-type: message/delivery-status 1391 Final-MTA: dns; cs.utk.edu 1393 Original-Recipient: rfc822 ; arathib@vnet.ibm.com 1394 Final-Recipient: rfc822 ; arathib@vnet.ibm.com 1395 Action: failure 1396 Status: 5.0.0 (permanent failure) 1397 Diagnostic-Code: smtp; 550 1398 ('arathib@vnet.IBM.COM' is not a registered gateway user) 1399 Remote-MTA: dns; vnet.ibm.com 1401 Original-Recipient: rfc822; johnh@hpnjld.njd.hp.com 1402 Final-Recipient: rfc822; johnh@hpnjld.njd.hp.com 1403 Action: delayed 1404 Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure) 1406 Original-Recipient: rfc822; wsnell@sdcc13.ucsd.edu 1407 Final-Recipient: rfc822; wsnell@sdcc13.ucsd.edu 1408 Action: failure 1409 Status: 5.0.0 1410 Diagnostic-Code: smtp; 550 (user unknown) 1411 Remote-MTA: dns; sdcc13.ucsd.edu 1413 --JAA13167.773673707/CS.UTK.EDU 1414 content-type: message/rfc822 1416 [original message goes here] 1417 --JAA13167.773673707/CS.UTK.EDU-- 1419 Delivery Status Notifications 20 January 1995 1421 11.3 A delivery report generated by Message Router (MAILBUS) and 1422 gatewayed by PMDF_MR to a DSN. In this case the gateway did not 1423 have sufficient information to supply an original-recipient 1424 address. 1426 Disclose-recipients: prohibited 1427 Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT) 1428 From: Message Router Submission Agent 1429 Subject: Status of : Re: Battery current sense 1430 To: owner-ups-mib@CS.UTK.EDU 1431 Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com> 1432 MIME-version: 1.0 1433 content-type: multipart/report; report-type=delivery-status; 1434 boundary="[;84229080704991/122306@SYS30]" 1436 --[;84229080704991/122306@SYS30] 1437 content-type: text/plain 1439 Invalid address - nair_s 1440 %DIR-E-NODIRMTCH, No matching Directory Entry found 1442 --[;84229080704991/122306@SYS30] 1443 content-type: message/delivery-status 1445 Final-MTA: mailbus; SYS30 1447 Final-Recipient: unknown; nair_s 1448 Status: 5.0.0 (unknown permanent failure) 1449 Action: failure 1450 --[;84229080704991/122306@SYS30]-- 1452 Delivery Status Notifications 20 January 1995 1454 11.4 A delay report from a multiprotocol MTA. Note that there is 1455 no returned content, so no third body part appears in the DSN. 1457 From: 1458 Message-Id: <199407092338.TAA23293@CS.UTK.EDU> 1459 Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk 1460 id ; 1461 Sun, 10 Jul 1994 00:36:51 +0100 1462 To: owner-info-mime@cs.utk.edu 1463 Date: Sun, 10 Jul 1994 00:36:51 +0100 1464 Subject: WARNING: message delayed at "nsfnet-relay.ac.uk" 1465 content-type: multipart/report; report-type=delivery-status; 1466 boundary=foobar 1468 --foobar 1469 content-type: text/plain 1471 The following message: 1473 UA-ID: Reliable PC (... 1474 Q-ID: sun2.nsf:77/msg.11820-0 1476 has not been delivered to the intended recipient: 1478 thomas@de-montfort.ac.uk 1480 despite repeated delivery attempts over the past 24 hours. 1482 The usual cause of this problem is that the remote system is 1483 temporarily unavailable. 1485 Delivery will continue to be attempted up to a total elapsed 1486 time of 168 hours, ie 7 days. 1488 You will be informed if delivery proves to be impossible 1489 within this time. 1491 Please quote the Q-ID in any queries regarding this mail. 1493 --foobar 1494 content-type: message/delivery-status 1496 Final-MTA: dns; sun2.nsfnet-relay.ac.uk 1498 Final-Recipient: rfc822; thomas@de-montfort.ac.uk 1499 Status: 4.0.0 (unknown temporary failure) 1500 Action: delayed 1501 --foobar-- 1503 Delivery Status Notifications 20 January 1995 1505 11.5 A DSN gatewayed from a X.400 nondelivery notification 1507 From: "UK.AC.NSF MTA" 1508 To: na-digest-bounces@netlib2.cs.utk.edu 1509 Subject: Delivery Report (failure) for sdz009@prime.napier.ac.uk 1510 Date: Mon, 11 Jul 1994 02:09:43 +0100 1511 Message-ID: <"sun3.nsfne.309:11.06.94.01.09.27"@nsfnet-relay.ac.uk> 1512 content-type: multipart/report; report-type=delivery-status; 1513 boundary=foobar 1515 --foobar 1516 content-type: text/plain 1518 This report relates to your message: Subject: NA Digest, V. 94, # 27, 1519 Message-ID: <199407031824.OAA23971@localhost>, 1520 To: na-digest list:; 1521 of Sun, 3 Jul 1994 19:47:56 +0100 1523 Your message was not delivered to sdz009@prime.napier.ac.uk 1524 for the following reason: 1525 Message timed out 1527 --foobar 1528 content-type: message/delivery-status 1530 Final-MTA: dns; sun3.nsfnet-relay.ac.uk 1531 (in /PRMD=uk.ac/ADMD= /C=gb/) 1533 Original-Recipient: rfc822; sdz009@prime.napier.ac.uk 1534 Final-Recipient: x400; 1535 /S=sdz009/OU=prime/O=napier/PRMD=UK.AC/ADMD=+20/C=GB/ 1536 Action: failure 1537 Status: 4.0.0 1538 Diagnostic-Code: x400 ; 1/5 1539 (unable-to-transfer/maximum-time-expired) 1540 X400-Subject-Intermediate-Trace-Information: 1541 /PRMD=uk.ac/ADMD= /C=gb/ 1542 arrival Sun, 3 Jul 1994 19:47:56 +0100 action Relayed 1543 X400-Subject-Intermediate-Trace-Information: 1544 /PRMD=uk.ac/ADMD= /C=gb/ 1545 arrival Sun, 3 Jul 1994 19:24:03 +0100 action Relayed 1547 --foobar 1548 content-type: message/rfc822 1550 [returned content] 1551 --foobar--