idnits 2.17.1 draft-ietf-notary-mime-delivery-05.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-20) 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 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 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 4 characters in excess of 72. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 281: '...The DSN MUST be addressed (in both the...' RFC 2119 keyword, line 287: '...e header of the DSN SHOULD contain the...' RFC 2119 keyword, line 292: '...address, the From field of the DSN MAY...' RFC 2119 keyword, line 296: '...dress of the DSN SHOULD be chosen to e...' RFC 2119 keyword, line 298: '...and MUST be chosen so that DSNs will n...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1453 has weird spacing: '...The usual cau...' == Line 1459 has weird spacing: '...You will be ...' -- 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 (29 May 1995) is 10554 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) == Outdated reference: A later version (-05) exists of draft-ietf-notary-mime-report-03 ** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821) == Outdated reference: A later version (-05) exists of draft-ietf-notary-smtp-drpt-04 ** 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) ** Downref: Normative reference to an Unknown state RFC: RFC 1047 (ref. '9') Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: 29 November 1995 Greg Vaudreuil 4 Octel Network Services 5 29 May 1995 7 An Extensible Message Format 8 for Delivery Status Notifications 10 draft-ietf-notary-mime-delivery-05.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 1. Introduction 50 This memo defines a MIME [1] content-type for delivery status 51 notifications (DSNs). A DSN can be used to notify the sender of a 52 message of any of several conditions: failed delivery, delayed 53 delivery, successful delivery, or the gatewaying of a message into an 54 environment that may not support DSNs. The "message/delivery-status" 55 content-type defined herein is intended for use within the framework of 56 the "multipart/report" content type defined in [2]. 58 This memo defines only the format of the notifications. An extension to 59 the Simple Message Transfer Protocol (SMTP) [3] to fully support such 60 notifications is the subject of a separate memo [4]. 62 1.1 Purposes 64 The DSNs defined in this memo are expected to serve several purposes: 66 (a) Inform human beings of the status of message delivery processing, as 67 well as the reasons for any delivery problems or outright failures, 68 in a manner which is largely independent of human language; 70 (b) Allow mail user agents to keep track of the delivery status of 71 messages sent, by associating returned DSNs with earlier message 72 transmissions; 74 (c) Allow mailing list exploders to automatically maintain their 75 subscriber lists when delivery attempts repeatedly fail; 77 (d) Convey delivery and non-delivery notifications resulting from 78 attempts to deliver messages to "foreign" mail systems via a 79 gateway; 81 (e) Allow "foreign" notifications to be tunneled through a MIME-capable 82 message system and back into the original messaging system that 83 issued the original notification, or even to a third messaging 84 system; 86 (f) Allow language-independent, yet reasonably precise, indications of 87 the reason for the failure of a message to be delivered (once status 88 codes of sufficient precision are defined); and 90 (g) Provide sufficient information to remote MTA maintainers (via 91 "trouble tickets") so that they can understand the nature of 92 reported errors. This feature is used in the case that failure to 93 deliver a message is due to the malfunction of a remote MTA and the 94 sender wants to report the problem to the remote MTA administrator. 96 1.2 Requirements 98 These purposes place the following constraints on the notification 99 protocol: 101 (a) It must be readable by humans as well as being machine-parsable. 103 (b) It must provide enough information to allow message senders (or the 104 user agents) to unambiguously associate a DSN with the message that 105 was sent and the original recipient address for which the DSN is 106 issued (if such information is available), even if the message was 107 forwarded to another recipient address. 109 (c) It must be able to preserve the reason for the success or failure of 110 a delivery attempt in a remote messaging system, using the 111 "language" (mailbox addresses and status codes) of that remote 112 system. 114 (d) It must also be able to describe the reason for the success or 115 failure of a delivery attempt, independent of any particular human 116 language or of the "language" of any particular mail system. 118 (e) It must preserve enough information to allow the maintainer of a 119 remote MTA to understand (and if possible, reproduce) the conditions 120 that caused a delivery failure at that MTA. 122 (f) For any notifications issued by foreign mail systems, which are 123 translated by a mail gateway to the DSN format, the DSN must 124 preserve the "type" of the foreign addresses and error codes, so 125 that these may be correctly interpreted by gateways. 127 A DSN contains a set of per-message fields which identify the message 128 and the transaction during which the message was submitted, along with 129 other fields that apply to all delivery attempts described by the DSN. 130 The DSN also includes a set of per-recipient fields to convey the result 131 of the attempt to deliver the message to each of one or more recipients. 133 1.3 Terminology 135 A message may be transmitted through several message transfer agents 136 (MTAs) on its way to a recipient. For a variety of reasons, recipient 137 addresses may be rewritten during this process, so each MTA may 138 potentially see a different recipient address. Depending on the purpose 139 for which a DSN is used, different formats of a particular recipient 140 address will be needed. 142 Several DSN fields are defined in terms of the view from a particular 143 MTA in the transmission. The MTAs are assigned the following names: 145 (a) Original MTA 147 The Original MTA is the one to which the message is submitted for 148 delivery by the sender of the message. 150 Note: Each time a message is re-sent to a completely different set of 151 recipients (say to the subscribers of a mailing list), the Original MTA 152 for the new recipients of that message is the one to which the message 153 is initially submitted for delivery to the new list of recipients. 155 (b) Reporting MTA 157 For any DSN, the Reporting MTA is the one which is reporting the results 158 of delivery attempts described in the DSN. 160 If the delivery attempts described occurred in a "foreign" (non- 161 Internet) mail system, and the DSN was produced by translating the 162 foreign notice into DSN format, the Reporting MTA will still identify 163 the "foreign" MTA where the delivery attempts occurred. 165 (c) Received-From MTA 167 The Received-From MTA is the MTA from which the Reporting MTA received 168 the message, and accepted responsibility for delivery of the message. 170 (d) Remote MTA 172 If an MTA determines that it must relay a message to one or more 173 recipients, but the message cannot be transferred to its "next hop" MTA, 174 or if the "next hop" MTA refuses to accept responsibility for delivery 175 of the message to one or more of its intended recipients, the relaying 176 MTA may need to issue a DSN on behalf of the recipients for whom the 177 message cannot be delivered. In this case the relaying MTA is the 178 Reporting MTA, and the "next hop" MTA is known as the Remote MTA. 180 Figure 1 illustrates the relationship between the various MTAs. 182 +-----+ +--------+ +---------+ +---------+ +------+ 183 | | | | |Received-| | | | | 184 | | => |Original| => ... => | From | => |Reporting| ===> |Remote| 185 | user| | MTA | | MTA | | MTA | ". 302 A particular DSN describes the delivery status for exactly one message. 303 However, an MTA MAY report on the delivery status for several recipients 304 of the same message in a single DSN. Due to the nature of the mail 305 transport system (where responsibility for delivery of a message to its 306 recipients may be split among several MTAs, and delivery to any 307 particular recipient may be delayed), multiple DSNs may be still be 308 issued in response to a single message submission. 310 2.1 The message/delivery-status content-type 312 The message/delivery-status content-type is defined as follows: 314 MIME type name: message 315 MIME subtype name: delivery-status 316 Optional parameters: none 317 Encoding considerations: "7bit" encoding is sufficient and 318 MUST be used to maintain readability 319 when viewed by non-MIME mail 320 readers. 321 Security considerations: discussed in section 4 of this memo. 323 The message/delivery-status report type for use in the multipart/report 324 is "delivery-status". 326 The body of a message/delivery-status consists of one or more "fields" 327 formatted according to the ABNF of RFC 822 header "fields" (see [6]). 328 The per-message fields appear first, followed by a blank line. 329 Following the per-message fields are one or more groups of per-recipient 330 fields. Each group of per-recipient fields is preceded by a blank line. 331 Using the ABNF of RFC 822, the syntax of the message/delivery-status 332 content is as follows: 334 delivery-status-content = 335 per-message-fields 1*( CRLF per-recipient-fields ) 337 The per-message fields are described in section 2.2. The per-recipient 338 fields are described in section 2.3. 340 2.1.1 General conventions for DSN fields 342 Since these fields are defined according to the rules of RFC 822, the 343 same conventions for continuation lines and comments apply. 344 Notification fields may be continued onto multiple lines by beginning 345 each additional line with a SPACE or HTAB. Text which appears in 346 parentheses is considered a comment and not part of the contents of that 347 notification field. Field names are case-insensitive, so the names of 348 notification fields may be spelled in any combination of upper and lower 349 case letters. Comments in DSN fields may use the "encoded-word" 350 construct defined in [7]. 352 2.1.2 "*-type" subfields 354 Several DSN fields consist of a "-type" subfield, followed by a 355 semicolon, followed by "*text". For these fields, the keyword used in 356 the address-type, diagnostic-type, or MTA-name-type subfield indicates 357 the expected format of the address, status-code, or MTA-name which 358 follows. 360 The "-type" subfields are defined as follows: 362 (a) An "address-type" specifies the format of a mailbox address. For 363 example, Internet mail addresses use the "rfc822" address-type. 365 address-type = atom 367 (b) A "diagnostic-type" specifies the format of a status code. For 368 example, when a DSN field contains a reply code reported via the 369 Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is 370 used. 372 diagnostic-type = atom 374 (c) An "MTA-name-type" specifies the format of an MTA name. For 375 example, for an SMTP server on an Internet host, the MTA name is the 376 domain name of that host, and the "dns" MTA-name-type is used. 378 mta-name-type = atom 380 Values for address-type, diagnostic-type, and MTA-name-type are case- 381 insensitive. Thus address-type values of "RFC822" and "rfc822" are 382 equivalent. 384 The Internet Assigned Numbers Authority (IANA) will maintain a registry 385 of address-types, diagnostic-types, and MTA-name-types, along with 386 descriptions of the meanings and acceptable values of each, or a 387 reference to a one or more specifications that provide such 388 descriptions. (The "rfc822" address-type, "smtp" diagnostic-type, and 389 "dns" MTA-name-type are defined in [4].) Registration forms for 390 address-type, diagnostic-type, and MTA-name-type appear in section 8 of 391 this document. 393 IANA will not accept registrations for any address-type, diagnostic- 394 type, or MTA-name-type name that begins with "X-". These type names are 395 reserved for experimental use. 397 2.1.3 Lexical tokens imported from RFC 822 399 The following lexical tokens, defined in [6], are used in the ABNF 400 grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- 401 white-space, SPACE, text. The date-time lexical token is defined in 402 [8]. 404 2.2 Per-Message DSN Fields 406 Some fields of a DSN apply to all of the delivery attempts described by 407 that DSN. These fields may appear at most once in any DSN. These 408 fields are used to correlate the DSN with the original message 409 transaction and to provide additional information which may be useful to 410 gateways. 412 per-message-fields = 413 [ original-envelope-id-field CRLF ] 414 reporting-mta-field CRLF 415 [ dsn-gateway-field CRLF ] 416 [ received-from-mta-field CRLF ] 417 [ arrival-date-field CRLF ] 418 *( extension-field CRLF ) 420 2.2.1 The Original-Envelope-Id field 422 The optional Original-Envelope-Id field contains an "envelope 423 identifier" which uniquely identifies the transaction during which the 424 message was submitted, and was either (a) specified by the sender and 425 supplied to the sender's MTA, or (b) generated by the sender's MTA and 426 made available to the sender when the message was submitted. Its 427 purpose is to allow the sender (or her user agent) to associate the 428 returned DSN with the specific transaction in which the message was 429 sent. 431 If such an envelope identifier was present in the envelope which 432 accompanied the message when it arrived at the Reporting MTA, it SHOULD 433 be supplied in the Original-Envelope-Id field of any DSNs issued as a 434 result of an attempt to deliver the message. Except when a DSN is 435 issued by the sender's MTA, an MTA MUST NOT supply this field unless 436 there is an envelope-identifier field in the envelope which accompanied 437 this message on its arrival at the Reporting MTA. 439 The Original-Envelope-Id field is defined as follows: 441 original-envelope-id-field = 442 "Original-Envelope-Id" ":" envelope-id 444 envelope-id = *text 446 There may be at most one Original-Envelope-Id field per DSN. 448 The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the original 449 case and spelling of the envelope-id. 451 NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from 452 the message header. The Message-Id identifies the content of the 453 message, while the Original-Envelope-Id identifies the transaction in 454 which the message is sent. 456 2.2.2 The Reporting-MTA DSN field 458 reporting-mta-field = 459 "Reporting-MTA" ":" mta-name-type ";" mta-name 461 mta-name = *text 463 The Reporting-MTA field is defined as follows: 465 A DSN describes the results of attempts to deliver, relay, or gateway a 466 message to one or more recipients. In all cases, the Reporting-MTA is 467 the MTA which attempted to perform the delivery, relay, or gateway 468 operation described in the DSN. This field is required. 470 Note that if an SMTP client attempts to relay a message to an SMTP 471 server and receives an error reply to a RCPT command, the client is 472 responsible for generating the DSN, and the client's domain name will 473 appear in the Reporting-MTA field. (The server's domain name will 474 appear in the Remote-MTA field.) 476 Note that the Reporting-MTA is not necessarily the MTA which actually 477 issued the DSN. For example, if an attempt to deliver a message outside 478 of the Internet resulted in a nondelivery notification which was 479 gatewayed back into Internet mail, the Reporting-MTA field of the 480 resulting DSN would be that of the MTA that originally reported the 481 delivery failure, not that of the gateway which converted the foreign 482 notification into a DSN. See Figure 2. 484 sender's environment recipient's environment 485 ............................ .......................................... 486 : : 487 (1) : : (2) 488 +-----+ +--------+ +--------+ +---------+ +---------+ +------+ 489 | | | | | | |Received-| | | | | 490 | |=>|Original|=>| |->| From |->|Reporting|-->|Remote| 491 | user| | MTA | | | | MTA | | MTA |") (so that no DSNs would be sent from a downstream 968 MTA to the original sender), 970 (e) for messages forwarded to a confidential address, disabling delivery 971 notifications for the forwarded message (e.g. if the "next-hop" MTA 972 using ESMTP and supports the DSN extension, by using the 973 NOTIFY=NEVER parameter to the RCPT command), or 975 (f) when forwarding mail to a confidential address, having the 976 forwarding MTA rewrite the envelope return address for the forwarded 977 message and attempt delivery of that message as if the forwarding 978 MTA were the originator. On its receipt of final delivery status, 979 the forwarding MTA would issue a "proxy" DSN to the original sender. 981 In general, any optional DSN field may be omitted if the Reporting MTA 982 site determines that inclusion of the field would impose too great a 983 compromise of site confidentiality. The need for such confidentiality 984 must be balanced against the utility of the omitted information in 985 trouble reports and DSNs gatewayed to foreign environments. 987 Implementors are cautioned that many existing MTAs will send nondelivery 988 notifications to a return address in the message header (rather than to 989 the one in the envelope), in violation of SMTP and other protocols. If 990 a message is forwarded through such an MTA, no reasonable action on the 991 part of the forwarding MTA will prevent the downstream MTA from 992 compromising the forwarding address. Likewise, if the recipient's MTA 993 automatically responds to messages based on a request in the message 994 header (such as the nonstandard, but widely used, Return-Receipt-To 995 extension header), it will also compromise the forwarding address. 997 4.3 Non-Repudiation 999 Within the framework of today's internet mail, the DSNs defined in this 1000 memo provide valuable information to the mail user; however, even a 1001 "failed" DSN can not be relied upon as a guarantee that a message was 1002 not received by the recipient. Even if DSNs are not actively forged, 1003 conditions exist under which a message can be delivered despite the fact 1004 that a failure DSN was issued. 1006 For example, a race condition in the SMTP protocol allows for the 1007 duplication of messages if the connection is dropped following a 1008 completed DATA command, but before a response is seen by the SMTP 1009 client. This will cause the SMTP client to retransmit the message, even 1010 though the SMTP server has already accepted it.[9] If one of those 1011 delivery attempts succeeds and the other one fails, a "failed" DSN could 1012 be issued even though the message actually reached the recipient. 1014 5. Appendix - collected grammar 1016 NOTE: The following lexical tokens are defined in RFC 822: atom, CHAR, 1017 comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The 1018 date-time lexical token is defined in [8]. 1020 action-field = "Action" ":" action-value 1022 action-value = 1023 "failed" / "delayed" / "delivered" / "relayed" / "expanded" 1025 address-type = atom 1027 arrival-date-field = "Arrival-Date" ":" date-time 1029 delivery-status-content = 1030 per-message-fields 1*( CRLF per-recipient-fields ) 1032 diagnostic-code-field = 1033 "Diagnostic-Code" ":" diagnostic-type ";" *text 1035 diagnostic-type = atom 1037 dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name 1039 envelope-id = *text 1041 extension-field = extension-field-name ":" *text 1043 extension-field-name = atom 1045 final-recipient-field = 1046 "Final-Recipient" ":" address-type ";" generic-address 1048 generic-address = *text 1050 last-attempt-date-field = "Last-Attempt-Date" ":" date-time 1052 mta-name = *text 1054 mta-name-type = atom 1056 original-envelope-id-field = 1057 "Original-Envelope-Id" ":" envelope-id 1059 original-recipient-field = 1060 "Original-Recipient" ":" address-type ";" generic-address 1062 per-message-fields = 1063 [ original-envelope-id-field CRLF ] 1064 reporting-mta-field CRLF 1065 [ dsn-gateway-field CRLF ] 1066 [ received-from-mta-field CRLF ] 1067 [ arrival-date-field CRLF ] 1068 *( extension-field CRLF ) 1070 per-recipient-fields = 1071 [ original-recipient-field CRLF ] 1072 final-recipient-field CRLF 1073 action-field CRLF 1074 status-field CRLF 1075 [ remote-mta-field CRLF ] 1076 [ diagnostic-code-field CRLF ] 1077 [ last-attempt-date-field CRLF ] 1078 [ will-retry-until-field CRLF ] 1079 *( extension-field CRLF ) 1081 received-from-mta-field = 1082 "Received-From-MTA" ":" mta-name-type ";" mta-name 1084 remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name 1086 reporting-mta-field = 1087 "Reporting-MTA" ":" mta-name-type ";" mta-name 1089 status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT 1091 ; White-space characters and comments are NOT allowed within a 1092 ; status-code, though a comment enclosed in parentheses MAY follow 1093 ; the last numeric subfield of the status-code. Each numeric 1094 ; subfield within the status-code MUST be expressed without 1095 ; leading zero digits. 1097 status-field = "Status" ":" status-code 1099 will-retry-until-field = "Will-Retry-Until" ":" date-time 1100 6. Appendix - Guidelines for gatewaying DSNs 1102 NOTE: This section provides non-binding recommendations for the 1103 construction of mail gateways that wish to provide semi-transparent 1104 delivery reports between the Internet and another electronic mail 1105 system. Specific DSN gateway requirements for a particular pair of mail 1106 systems may be defined by other documents. 1108 6.1 Gatewaying from other mail systems to DSNs 1110 A mail gateway may issue a DSN to convey the contents of a "foreign" 1111 delivery or non-delivery notification over Internet mail. When there 1112 are appropriate mappings from the foreign notification elements to DSN 1113 fields, the information may be transmitted in those DSN fields. 1114 Additional information (such as might be useful in a trouble ticket or 1115 needed to tunnel the foreign notification through the Internet) may be 1116 defined in extension DSN fields. (Such fields should be given names 1117 that identify the foreign mail protocol, e.g. X400-* for X.400 NDN or DN 1118 protocol elements) 1120 The gateway must attempt to supply reasonable values for the Reporting- 1121 MTA, Final-Recipient, Action, and Status fields. These will normally be 1122 obtained by translating the values from the remote delivery or non- 1123 delivery notification into their Internet-style equivalents. However, 1124 some loss of information is to be expected. For example, the set of 1125 status-codes defined for DSNs may not be adequate to fully convey the 1126 delivery diagnostic code from the foreign system. The gateway should 1127 assign the most precise code which describes the failure condition, 1128 falling back on "generic" codes such as 2.0.0 (success), 4.0.0 1129 (temporary failure), and 5.0.0 (permanent failure) when necessary. The 1130 actual foreign diagnostic code should be retained in the Diagnostic-Code 1131 field (with an appropriate diagnostic-type value) for use in trouble 1132 tickets or tunneling. 1134 The sender-specified recipient address, and the original envelope-id, if 1135 present in the foreign transport envelope, should be preserved in the 1136 Original-Recipient and Original-Envelope-ID fields. 1138 The gateway should also attempt to preserve the "final" recipient 1139 addresses and MTA names from the foreign system. Whenever possible, 1140 foreign protocol elements should be encoded as meaningful printable 1141 ASCII strings. 1143 For DSNs produced from foreign delivery or nondelivery notifications, 1144 the name of the gateway MUST appear in the DSN-Gateway field of the DSN. 1146 6.2 Gatewaying from DSNs to other mail systems 1148 It may be possible to gateway DSNs from the Internet into a foreign mail 1149 system. The primary purpose of such gatewaying is to convey delivery 1150 status information in a form that is usable by the destination system. 1151 A secondary purpose is to allow "tunneling" of DSNs through foreign mail 1152 systems, in case the DSN may be gatewayed back into the Internet. 1154 In general, the recipient of the DSN (i.e., the sender of the original 1155 message) will want to know, for each recipient: the closest available 1156 approximation to the original recipient address, the delivery status 1157 (success, failure, or temporary failure), and for failed deliveries, a 1158 diagnostic code that describes the reason for the failure. 1160 If possible, the gateway should attempt to preserve the Original- 1161 Recipient address and Original-Envelope-ID (if present), in the 1162 resulting foreign delivery status report. 1164 When reporting delivery failures, if the diagnostic-type subfield of the 1165 Diagnostic-Code field indicates that the original diagnostic code is 1166 understood by the destination environment, the information from the 1167 Diagnostic-Code field should be used. Failing that, the information in 1168 the Status field should be mapped into the closest available diagnostic 1169 code used in the destination environment. 1171 If it is possible to tunnel a DSN through the destination environment, 1172 the gateway specification may define a means of preserving the DSN 1173 information in the delivery status reports used by that environment. 1175 7. Appendix - Guidelines for use of DSNs by mailing list exploders 1177 NOTE: This section pertains only to the use of DSNs by "mailing lists" 1178 as defined in [4], section 7.2.7. 1180 DSNs are designed to be used by mailing list exploders to allow them to 1181 detect and automatically delete recipients for whom mail delivery fails 1182 repeatedly. 1184 When forwarding a message to list subscribers, the mailing list exploder 1185 should always set the envelope return address (e.g. SMTP MAIL FROM 1186 address) to point to a special address which is set up to received 1187 nondelivery reports. A "smart" mailing list exploder can therefore 1188 intercept such nondelivery reports, and if they are in the DSN format, 1189 automatically examine them to determine for which recipients a message 1190 delivery failed or was delayed. 1192 The Original-Recipient field should be used if available, since it 1193 should exactly match the subscriber address known to the list. If the 1194 Original-Recipient field is not available, the recipient field may 1195 resemble the list subscriber address. Often, however, the list 1196 subscriber will have forwarded his mail to a different address, or the 1197 address may be subject to some re-writing, so heuristics may be required 1198 to successfully match an address from the recipient field. Care is 1199 needed in this case to minimize the possibility of false matches. 1201 The reason for delivery failure can be obtained from the Status and 1202 Action fields, and from the Diagnostic-Code field (if the status-type is 1203 recognized). Reports for recipients with action values other than 1204 "failed" can generally be ignored; in particular, subscribers should not 1205 be removed from a list due to "delayed" reports. 1207 In general, almost any failure status code (even a "permanent" one) can 1208 result from a temporary condition. It is therefore recommended that a 1209 list exploder not delete a subscriber based on any single failure DSN 1210 (regardless of the status code), but only on the persistence of delivery 1211 failure over a period of time. 1213 However, some kinds of failures are less likely than others to have been 1214 caused by temporary conditions, and some kinds of failures are more 1215 likely to be noticed and corrected quickly than others. Once more 1216 precise status codes are defined, it may be useful to differentiate 1217 between the status codes when deciding whether to delete a subscriber. 1218 For example, on a list with a high message volume, it might be desirable 1219 to temporarily suspend delivery to a recipient address which causes 1220 repeated "temporary" failures, rather than simply deleting the 1221 recipient. The duration of the suspension might depend on the type of 1222 error. On the other hand, a "user unknown" error which persisted for 1223 several days could be considered a reliable indication that address were 1224 no longer valid. 1226 8. Appendix - IANA registration forms for DSN types 1228 The forms below are for use when registering a new address-type, 1229 diagnostic-type, or MTA-name-type with the Internet Assigned Numbers 1230 Authority (IANA). Each piece of information requested by a registration 1231 form may be satisfied either by providing the information on the form 1232 itself, or by including a reference to a published, publicly available 1233 specification which includes the necessary information. IANA MAY reject 1234 DSN type registrations because of incomplete registration forms, 1235 imprecise specifications, or inappropriate type names. 1237 To register a DSN type, complete the applicable form below and send it 1238 via Internet electronic mail to . 1240 8.1 IANA registration form for address-type 1242 A registration for a DSN address-type MUST include the following 1243 information: 1245 (a) The proposed address-type name. 1247 (b) The syntax for mailbox addresses of this type, specified using BNF, 1248 regular expressions, ASN.1, or other non-ambiguous language. 1250 (c) If addresses of this type are not composed entirely of graphic 1251 characters from the US-ASCII repertoire, a specification for how 1252 they are to be encoded as graphic US-ASCII characters in a DSN 1253 Original-Recipient or Final-Recipient DSN field. 1255 (d) [optional] A specification for how addresses of this type are to be 1256 translated to and from Internet electronic mail addresses. 1258 8.2 IANA registration form for diagnostic-type 1260 A registration for a DSN address-type MUST include the following 1261 information: 1263 (a) The proposed diagnostic-type name. 1265 (b) A description of the syntax to be used for expressing diagnostic 1266 codes of this type as graphic characters from the US-ASCII 1267 repertoire. 1269 (c) A list of valid diagnostic codes of this type and the meaning of 1270 each code. 1272 (d) [optional] A specification for mapping from diagnostic codes of this 1273 type to DSN status codes (as defined in [5]). 1275 8.3 IANA registration form for MTA-name-type 1277 A registration for a DSN MTA-name-type must include the following 1278 information: 1280 (a) The proposed MTA-name-type name. 1282 (b) A description of the syntax of MTA names of this type, using BNF, 1283 regular expressions, ASN.1, or other non-ambiguous language. 1285 (c) If MTA names of this type do not consist entirely of graphic 1286 characters from the US-ASCII repertoire, a specification for how an 1287 MTA name of this type should be expressed as a sequence of graphic 1288 US-ASCII characters. 1290 9. Appendix - Examples 1292 NOTE: These examples are provided as illustration only, and are not 1293 considered part of the DSN protocol specification. If an example 1294 conflicts with the protocol definition above, the example is wrong. 1296 Likewise, the use of *-type subfield names or extension fields in these 1297 examples is not to be construed as a definition for those type names or 1298 extension fields. 1300 These examples were manually translated from bounced messages using 1301 whatever information was available. 1303 9.1 This is a simple DSN issued after repeated attempts to deliver a 1304 message failed. In this case, the DSN is issued by the same MTA from 1305 which the message was originated. 1307 Date: Thu, 7 Jul 1994 17:16:05 -0400 1308 From: Mail Delivery Subsystem 1309 Message-Id: <199407072116.RAA14128@CS.UTK.EDU> 1310 Subject: Returned mail: Cannot send message for 5 days 1311 To: 1312 MIME-Version: 1.0 1313 Content-Type: multipart/report; report-type=delivery-status; 1314 boundary="RAA14128.773615765/CS.UTK.EDU" 1316 --RAA14128.773615765/CS.UTK.EDU 1318 The original message was received at Sat, 2 Jul 1994 17:10:28 -0400 1319 from root@localhost 1321 ----- The following addresses had delivery problems ----- 1322 (unrecoverable error) 1324 ----- Transcript of session follows ----- 1325 ... Deferred: Connection timed out 1326 with larry.slip.umd.edu. 1327 Message could not be delivered for 5 days 1328 Message will be deleted from queue 1330 --RAA14128.773615765/CS.UTK.EDU 1331 content-type: message/delivery-status 1333 Reporting-MTA: dns; cs.utk.edu 1335 Original-Recipient: rfc822; louisl@larry.slip.umd.edu 1336 Final-Recipient: rfc822; louisl@larry.slip.umd.edu 1337 Action: failure 1338 Status: 4.0.0 1339 Diagnostic-Code: smtp; 426 connection timed out 1340 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1342 --RAA14128.773615765/CS.UTK.EDU 1343 content-type: message/rfc822 1345 [original message goes here] 1346 --RAA14128.773615765/CS.UTK.EDU-- 1347 9.2 This is another DSN issued by the sender's MTA, which contains 1348 details of multiple delivery attempts. Some of these were detected 1349 locally, and others by a remote MTA. 1351 Date: Fri, 8 Jul 1994 09:21:47 -0400 1352 From: Mail Delivery Subsystem 1353 Subject: Returned mail: User unknown 1354 To: 1355 MIME-Version: 1.0 1356 Content-Type: multipart/report; report-type=delivery-status; 1357 boundary="JAA13167.773673707/CS.UTK.EDU" 1359 --JAA13167.773673707/CS.UTK.EDU 1360 content-type: text/plain; charset=us-ascii 1362 ----- The following addresses had delivery problems ----- 1363 (unrecoverable error) 1364 (unrecoverable error) 1366 --JAA13167.773673707/CS.UTK.EDU 1367 content-type: message/delivery-status 1369 Reporting-MTA: dns; cs.utk.edu 1371 Original-Recipient: rfc822 ; arathib@vnet.ibm.com 1372 Final-Recipient: rfc822 ; arathib@vnet.ibm.com 1373 Action: failure 1374 Status: 5.0.0 (permanent failure) 1375 Diagnostic-Code: smtp; 1376 550 'arathib@vnet.IBM.COM' is not a registered gateway user 1377 Remote-MTA: dns; vnet.ibm.com 1379 Original-Recipient: rfc822; johnh@hpnjld.njd.hp.com 1380 Final-Recipient: rfc822; johnh@hpnjld.njd.hp.com 1381 Action: delayed 1382 Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure) 1384 Original-Recipient: rfc822; wsnell@sdcc13.ucsd.edu 1385 Final-Recipient: rfc822; wsnell@sdcc13.ucsd.edu 1386 Action: failure 1387 Status: 5.0.0 1388 Diagnostic-Code: smtp; 550 user unknown 1389 Remote-MTA: dns; sdcc13.ucsd.edu 1391 --JAA13167.773673707/CS.UTK.EDU 1392 content-type: message/rfc822 1394 [original message goes here] 1395 --JAA13167.773673707/CS.UTK.EDU-- 1396 9.3 A delivery report generated by Message Router (MAILBUS) and 1397 gatewayed by PMDF_MR to a DSN. In this case the gateway did not have 1398 sufficient information to supply an original-recipient address. 1400 Disclose-recipients: prohibited 1401 Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT) 1402 From: Message Router Submission Agent 1403 Subject: Status of : Re: Battery current sense 1404 To: owner-ups-mib@CS.UTK.EDU 1405 Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com> 1406 MIME-version: 1.0 1407 content-type: multipart/report; report-type=delivery-status; 1408 boundary="84229080704991.122306.SYS30" 1410 --84229080704991.122306.SYS30 1411 content-type: text/plain 1413 Invalid address - nair_s 1414 %DIR-E-NODIRMTCH, No matching Directory Entry found 1416 --84229080704991.122306.SYS30 1417 content-type: message/delivery-status 1419 Reporting-MTA: mailbus; SYS30 1421 Final-Recipient: unknown; nair_s 1422 Status: 5.0.0 (unknown permanent failure) 1423 Action: failure 1424 --84229080704991.122306.SYS30-- 1425 9.4 A delay report from a multiprotocol MTA. Note that there is no 1426 returned content, so no third body part appears in the DSN. 1428 From: 1429 Message-Id: <199407092338.TAA23293@CS.UTK.EDU> 1430 Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk 1431 id ; 1432 Sun, 10 Jul 1994 00:36:51 +0100 1433 To: owner-info-mime@cs.utk.edu 1434 Date: Sun, 10 Jul 1994 00:36:51 +0100 1435 Subject: WARNING: message delayed at "nsfnet-relay.ac.uk" 1436 content-type: multipart/report; report-type=delivery-status; 1437 boundary=foobar 1439 --foobar 1440 content-type: text/plain 1442 The following message: 1444 UA-ID: Reliable PC (... 1445 Q-ID: sun2.nsf:77/msg.11820-0 1447 has not been delivered to the intended recipient: 1449 thomas@de-montfort.ac.uk 1451 despite repeated delivery attempts over the past 24 hours. 1453 The usual cause of this problem is that the remote system is 1454 temporarily unavailable. 1456 Delivery will continue to be attempted up to a total elapsed 1457 time of 168 hours, ie 7 days. 1459 You will be informed if delivery proves to be impossible 1460 within this time. 1462 Please quote the Q-ID in any queries regarding this mail. 1464 --foobar 1465 content-type: message/delivery-status 1467 Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk 1469 Final-Recipient: rfc822; thomas@de-montfort.ac.uk 1470 Status: 4.0.0 (unknown temporary failure) 1471 Action: delayed 1473 --foobar-- 1474 10. Acknowledgments 1476 The authors wish to thank the following people for their reviews of 1477 earlier drafts of this document and their suggestions for improvement: 1478 Eric Allman, Harald Alvestrand, Allan Cargille, Jim Conklin, Peter 1479 Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve 1480 Kille, John Klensin, John Gardiner Myers, Mark Nahabedian, Julian 1481 Onions, Jacob Palme, Jean Charles Roy, and Gregory Sheehan. 1483 11. References 1485 [1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", 1486 RFC 1521, Bellcore, Innosoft, September 1993. 1488 [2] Vaudreuil, G. "The Multipart/Report Content Type for the Reporting 1489 of Mail System Administrative Messages", Internet-Draft draft-ietf- 1490 notary-mime-report-03.txt, 5 May 1995. 1492 [3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1493 USC/Information Sciences Institute, August 1982. 1495 [4] Moore, K. "SMTP Service Extension for Delivery Status 1496 Notifications", Internet-Draft draft-ietf-notary-smtp-drpt-04.txt, 1497 29 May 1995. 1499 [5] Vaudreuil, G. "Enhanced Mail System Status Codes", Internet-Draft 1500 draft-ietf-notary-status-03.txt, 5 May 1995. 1502 [6] Crocker, D., "Standard for the Format of ARPA Internet Text 1503 Messages", STD 11, RFC 822, UDEL, August 1982. 1505 [7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two: 1506 Message Header Extensions for Non-Ascii Text", RFC 1522, University 1507 of Tennessee, September 1993. 1509 [8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and 1510 Support", RFC 1123, October 1989. 1512 [9] Partridge, C. "Duplicate messages and SMTP", RFC 1047, February 1513 1988. 1515 11. Author's Addresses 1517 Keith Moore 1518 University of Tennessee 1519 107 Ayres Hall 1520 Knoxville, TN 37996-1301 1521 USA 1522 email: moore@cs.utk.edu 1523 voice: +1 615 974 3126 1524 fax: +1 615 974 8296 1526 Gregory M. Vaudreuil 1527 Octel Network Services 1528 17080 Dallas Parkway 1529 Dallas, TX 75248-1905 1530 USA 1531 email: Greg.Vaudreuil@Octel.Com