idnits 2.17.1 draft-ietf-notary-mime-delivery-06.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-24) 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 284: '...The DSN MUST be addressed (in both the...' RFC 2119 keyword, line 290: '...e header of the DSN SHOULD contain the...' RFC 2119 keyword, line 295: '...address, the From field of the DSN MAY...' RFC 2119 keyword, line 299: '...dress of the DSN SHOULD be chosen to e...' RFC 2119 keyword, line 301: '...and MUST be chosen so that DSNs will n...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1454 has weird spacing: '...The usual cau...' == Line 1460 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 (21 June 1995) is 10535 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: 21 December 1995 Greg Vaudreuil 4 Octel Network Services 5 21 June 1995 7 An Extensible Message Format 8 for Delivery Status Notifications 10 draft-ietf-notary-mime-delivery-06.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 Any questions, comments, and reports of defects or ambiguities in this 31 specification may be sent to the mailing list for the NOTARY working 32 group of the IETF, using the address . 33 Requests to subscribe to the mailing list should be addressed to 34 . Implementors of this specification 35 are encouraged to subscribe to the mailing list, so that they will 36 quickly be informed of any problems which might hinder interoperability. 38 Abstract 40 This memo defines a MIME content-type that may be used by a message 41 transfer agent (MTA) or electronic mail gateway to report the result of 42 an attempt to deliver a message to one or more recipients. This 43 content-type is intended as a machine-processable replacement for the 44 various types of delivery status notifications currently used in 45 Internet electronic mail. 47 Because many messages are sent between the Internet and other messaging 48 systems (such as X.400 or the so-called "LAN-based" systems), the DSN 49 protocol is designed to be useful in a multi-protocol messaging 50 environment. To this end, the protocol described in this memo provides 51 for the carriage of "foreign" addresses and error codes, in addition to 52 those normally used in Internet mail. Additional attributes may also be 53 defined to support "tunneling" of foreign notifications through Internet 54 mail. 56 1. Introduction 58 This memo defines a MIME [1] content-type for delivery status 59 notifications (DSNs). A DSN can be used to notify the sender of a 60 message of any of several conditions: failed delivery, delayed 61 delivery, successful delivery, or the gatewaying of a message into an 62 environment that may not support DSNs. The "message/delivery-status" 63 content-type defined herein is intended for use within the framework of 64 the "multipart/report" content type defined in [2]. 66 This memo defines only the format of the notifications. An extension to 67 the Simple Message Transfer Protocol (SMTP) [3] to fully support such 68 notifications is the subject of a separate memo [4]. 70 1.1 Purposes 72 The DSNs defined in this memo are expected to serve several purposes: 74 (a) Inform human beings of the status of message delivery processing, as 75 well as the reasons for any delivery problems or outright failures, 76 in a manner which is largely independent of human language; 78 (b) Allow mail user agents to keep track of the delivery status of 79 messages sent, by associating returned DSNs with earlier message 80 transmissions; 82 (c) Allow mailing list exploders to automatically maintain their 83 subscriber lists when delivery attempts repeatedly fail; 85 (d) Convey delivery and non-delivery notifications resulting from 86 attempts to deliver messages to "foreign" mail systems via a 87 gateway; 89 (e) Allow "foreign" notifications to be tunneled through a MIME-capable 90 message system and back into the original messaging system that 91 issued the original notification, or even to a third messaging 92 system; 94 (f) Allow language-independent, yet reasonably precise, indications of 95 the reason for the failure of a message to be delivered (once status 96 codes of sufficient precision are defined); and 98 (g) Provide sufficient information to remote MTA maintainers (via 99 "trouble tickets") so that they can understand the nature of 100 reported errors. This feature is used in the case that failure to 101 deliver a message is due to the malfunction of a remote MTA and the 102 sender wants to report the problem to the remote MTA administrator. 104 1.2 Requirements 106 These purposes place the following constraints on the notification 107 protocol: 109 (a) It must be readable by humans as well as being machine-parsable. 111 (b) It must provide enough information to allow message senders (or the 112 user agents) to unambiguously associate a DSN with the message that 113 was sent and the original recipient address for which the DSN is 114 issued (if such information is available), even if the message was 115 forwarded to another recipient address. 117 (c) It must be able to preserve the reason for the success or failure of 118 a delivery attempt in a remote messaging system, using the 119 "language" (mailbox addresses and status codes) of that remote 120 system. 122 (d) It must also be able to describe the reason for the success or 123 failure of a delivery attempt, independent of any particular human 124 language or of the "language" of any particular mail system. 126 (e) It must preserve enough information to allow the maintainer of a 127 remote MTA to understand (and if possible, reproduce) the conditions 128 that caused a delivery failure at that MTA. 130 (f) For any notifications issued by foreign mail systems, which are 131 translated by a mail gateway to the DSN format, the DSN must 132 preserve the "type" of the foreign addresses and error codes, so 133 that these may be correctly interpreted by gateways. 135 A DSN contains a set of per-message fields which identify the message 136 and the transaction during which the message was submitted, along with 137 other fields that apply to all delivery attempts described by the DSN. 138 The DSN also includes a set of per-recipient fields to convey the result 139 of the attempt to deliver the message to each of one or more recipients. 141 1.3 Terminology 143 A message may be transmitted through several message transfer agents 144 (MTAs) on its way to a recipient. For a variety of reasons, recipient 145 addresses may be rewritten during this process, so each MTA may 146 potentially see a different recipient address. Depending on the purpose 147 for which a DSN is used, different formats of a particular recipient 148 address will be needed. 150 Several DSN fields are defined in terms of the view from a particular 151 MTA in the transmission. The MTAs are assigned the following names: 153 (a) Original MTA 155 The Original MTA is the one to which the message is submitted for 156 delivery by the sender of the message. 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) Received-From MTA 170 The Received-From MTA is the MTA from which the Reporting MTA received 171 the 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 | | | | |Received-| | | | | 187 | | => |Original| => ... => | From | => |Reporting| ===> |Remote| 188 | user| | MTA | | MTA | | MTA | ". 305 A particular DSN describes the delivery status for exactly one message. 306 However, an MTA MAY report on the delivery status for several recipients 307 of the same message in a single DSN. Due to the nature of the mail 308 transport system (where responsibility for delivery of a message to its 309 recipients may be split among several MTAs, and delivery to any 310 particular recipient may be delayed), multiple DSNs may be still be 311 issued in response to a single message submission. 313 2.1 The message/delivery-status content-type 315 The message/delivery-status content-type is defined as follows: 317 MIME type name: message 318 MIME subtype name: delivery-status 319 Optional parameters: none 320 Encoding considerations: "7bit" encoding is sufficient and 321 MUST be used to maintain readability 322 when viewed by non-MIME mail 323 readers. 324 Security considerations: discussed in section 4 of this memo. 326 The message/delivery-status report type for use in the multipart/report 327 is "delivery-status". 329 The body of a message/delivery-status consists of one or more "fields" 330 formatted according to the ABNF of RFC 822 header "fields" (see [6]). 331 The per-message fields appear first, followed by a blank line. 332 Following the per-message fields are one or more groups of per-recipient 333 fields. Each group of per-recipient fields is preceded by a blank line. 334 Using the ABNF of RFC 822, the syntax of the message/delivery-status 335 content is as follows: 337 delivery-status-content = 338 per-message-fields 1*( CRLF per-recipient-fields ) 340 The per-message fields are described in section 2.2. The per-recipient 341 fields are described in section 2.3. 343 2.1.1 General conventions for DSN fields 345 Since these fields are defined according to the rules of RFC 822, the 346 same conventions for continuation lines and comments apply. 347 Notification fields may be continued onto multiple lines by beginning 348 each additional line with a SPACE or HTAB. Text which appears in 349 parentheses is considered a comment and not part of the contents of that 350 notification field. Field names are case-insensitive, so the names of 351 notification fields may be spelled in any combination of upper and lower 352 case letters. Comments in DSN fields may use the "encoded-word" 353 construct defined in [7]. 355 2.1.2 "*-type" subfields 357 Several DSN fields consist of a "-type" subfield, followed by a 358 semicolon, followed by "*text". For these fields, the keyword used in 359 the address-type, diagnostic-type, or MTA-name-type subfield indicates 360 the expected format of the address, status-code, or MTA-name which 361 follows. 363 The "-type" subfields are defined as follows: 365 (a) An "address-type" specifies the format of a mailbox address. For 366 example, Internet mail addresses use the "rfc822" address-type. 368 address-type = atom 370 (b) A "diagnostic-type" specifies the format of a status code. For 371 example, when a DSN field contains a reply code reported via the 372 Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is 373 used. 375 diagnostic-type = atom 377 (c) An "MTA-name-type" specifies the format of an MTA name. For 378 example, for an SMTP server on an Internet host, the MTA name is the 379 domain name of that host, and the "dns" MTA-name-type is used. 381 mta-name-type = atom 383 Values for address-type, diagnostic-type, and MTA-name-type are case- 384 insensitive. Thus address-type values of "RFC822" and "rfc822" are 385 equivalent. 387 The Internet Assigned Numbers Authority (IANA) will maintain a registry 388 of address-types, diagnostic-types, and MTA-name-types, along with 389 descriptions of the meanings and acceptable values of each, or a 390 reference to a one or more specifications that provide such 391 descriptions. (The "rfc822" address-type, "smtp" diagnostic-type, and 392 "dns" MTA-name-type are defined in [4].) Registration forms for 393 address-type, diagnostic-type, and MTA-name-type appear in section 8 of 394 this document. 396 IANA will not accept registrations for any address-type, diagnostic- 397 type, or MTA-name-type name that begins with "X-". These type names are 398 reserved for experimental use. 400 2.1.3 Lexical tokens imported from RFC 822 402 The following lexical tokens, defined in [6], are used in the ABNF 403 grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- 404 white-space, SPACE, text. The date-time lexical token is defined in 405 [8]. 407 2.2 Per-Message DSN Fields 409 Some fields of a DSN apply to all of the delivery attempts described by 410 that DSN. These fields may appear at most once in any DSN. These 411 fields are used to correlate the DSN with the original message 412 transaction and to provide additional information which may be useful to 413 gateways. 415 per-message-fields = 416 [ original-envelope-id-field CRLF ] 417 reporting-mta-field CRLF 418 [ dsn-gateway-field CRLF ] 419 [ received-from-mta-field CRLF ] 420 [ arrival-date-field CRLF ] 421 *( extension-field CRLF ) 423 2.2.1 The Original-Envelope-Id field 425 The optional Original-Envelope-Id field contains an "envelope 426 identifier" which uniquely identifies the transaction during which the 427 message was submitted, and was either (a) specified by the sender and 428 supplied to the sender's MTA, or (b) generated by the sender's MTA and 429 made available to the sender when the message was submitted. Its 430 purpose is to allow the sender (or her user agent) to associate the 431 returned DSN with the specific transaction in which the message was 432 sent. 434 If such an envelope identifier was present in the envelope which 435 accompanied the message when it arrived at the Reporting MTA, it SHOULD 436 be supplied in the Original-Envelope-Id field of any DSNs issued as a 437 result of an attempt to deliver the message. Except when a DSN is 438 issued by the sender's MTA, an MTA MUST NOT supply this field unless 439 there is an envelope-identifier field in the envelope which accompanied 440 this message on its arrival at the Reporting MTA. 442 The Original-Envelope-Id field is defined as follows: 444 original-envelope-id-field = 445 "Original-Envelope-Id" ":" envelope-id 447 envelope-id = *text 449 There may be at most one Original-Envelope-Id field per DSN. 451 The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the original 452 case and spelling of the envelope-id. 454 NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from 455 the message header. The Message-Id identifies the content of the 456 message, while the Original-Envelope-Id identifies the transaction in 457 which the message is sent. 459 2.2.2 The Reporting-MTA DSN field 461 reporting-mta-field = 462 "Reporting-MTA" ":" mta-name-type ";" mta-name 464 mta-name = *text 466 The Reporting-MTA field is defined as follows: 468 A DSN describes the results of attempts to deliver, relay, or gateway a 469 message to one or more recipients. In all cases, the Reporting-MTA is 470 the MTA which attempted to perform the delivery, relay, or gateway 471 operation described in the DSN. This field is required. 473 Note that if an SMTP client attempts to relay a message to an SMTP 474 server and receives an error reply to a RCPT command, the client is 475 responsible for generating the DSN, and the client's domain name will 476 appear in the Reporting-MTA field. (The server's domain name will 477 appear in the Remote-MTA field.) 479 Note that the Reporting-MTA is not necessarily the MTA which actually 480 issued the DSN. For example, if an attempt to deliver a message outside 481 of the Internet resulted in a nondelivery notification which was 482 gatewayed back into Internet mail, the Reporting-MTA field of the 483 resulting DSN would be that of the MTA that originally reported the 484 delivery failure, not that of the gateway which converted the foreign 485 notification into a DSN. See Figure 2. 487 sender's environment recipient's environment 488 ............................ .......................................... 489 : : 490 (1) : : (2) 491 +-----+ +--------+ +--------+ +---------+ +---------+ +------+ 492 | | | | | | |Received-| | | | | 493 | |=>|Original|=>| |->| From |->|Reporting|-->|Remote| 494 | user| | MTA | | | | MTA | | MTA |") (so that no DSNs would be sent from a downstream 969 MTA to the original sender), 971 (e) for messages forwarded to a confidential address, disabling delivery 972 notifications for the forwarded message (e.g. if the "next-hop" MTA 973 uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER 974 parameter to the RCPT command), or 976 (f) when forwarding mail to a confidential address, having the 977 forwarding MTA rewrite the envelope return address for the forwarded 978 message and attempt delivery of that message as if the forwarding 979 MTA were the originator. On its receipt of final delivery status, 980 the forwarding MTA would issue a DSN to the original sender. 982 In general, any optional DSN field may be omitted if the Reporting MTA 983 site determines that inclusion of the field would impose too great a 984 compromise of site confidentiality. The need for such confidentiality 985 must be balanced against the utility of the omitted information in 986 trouble reports and DSNs gatewayed to foreign environments. 988 Implementors are cautioned that many existing MTAs will send nondelivery 989 notifications to a return address in the message header (rather than to 990 the one in the envelope), in violation of SMTP and other protocols. If 991 a message is forwarded through such an MTA, no reasonable action on the 992 part of the forwarding MTA will prevent the downstream MTA from 993 compromising the forwarding address. Likewise, if the recipient's MTA 994 automatically responds to messages based on a request in the message 995 header (such as the nonstandard, but widely used, Return-Receipt-To 996 extension header), it will also compromise the forwarding address. 998 4.3 Non-Repudiation 1000 Within the framework of today's internet mail, the DSNs defined in this 1001 memo provide valuable information to the mail user; however, even a 1002 "failed" DSN can not be relied upon as a guarantee that a message was 1003 not received by the recipient. Even if DSNs are not actively forged, 1004 conditions exist under which a message can be delivered despite the fact 1005 that a failure DSN was issued. 1007 For example, a race condition in the SMTP protocol allows for the 1008 duplication of messages if the connection is dropped following a 1009 completed DATA command, but before a response is seen by the SMTP 1010 client. This will cause the SMTP client to retransmit the message, even 1011 though the SMTP server has already accepted it.[9] If one of those 1012 delivery attempts succeeds and the other one fails, a "failed" DSN could 1013 be issued even though the message actually reached the recipient. 1015 5. Appendix - collected grammar 1017 NOTE: The following lexical tokens are defined in RFC 822: atom, CHAR, 1018 comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The 1019 date-time lexical token is defined in [8]. 1021 action-field = "Action" ":" action-value 1023 action-value = 1024 "failed" / "delayed" / "delivered" / "relayed" / "expanded" 1026 address-type = atom 1028 arrival-date-field = "Arrival-Date" ":" date-time 1030 delivery-status-content = 1031 per-message-fields 1*( CRLF per-recipient-fields ) 1033 diagnostic-code-field = 1034 "Diagnostic-Code" ":" diagnostic-type ";" *text 1036 diagnostic-type = atom 1038 dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name 1040 envelope-id = *text 1042 extension-field = extension-field-name ":" *text 1044 extension-field-name = atom 1046 final-recipient-field = 1047 "Final-Recipient" ":" address-type ";" generic-address 1049 generic-address = *text 1051 last-attempt-date-field = "Last-Attempt-Date" ":" date-time 1053 mta-name = *text 1055 mta-name-type = atom 1057 original-envelope-id-field = 1058 "Original-Envelope-Id" ":" envelope-id 1060 original-recipient-field = 1061 "Original-Recipient" ":" address-type ";" generic-address 1063 per-message-fields = 1064 [ original-envelope-id-field CRLF ] 1065 reporting-mta-field CRLF 1066 [ dsn-gateway-field CRLF ] 1067 [ received-from-mta-field CRLF ] 1068 [ arrival-date-field CRLF ] 1069 *( extension-field CRLF ) 1071 per-recipient-fields = 1072 [ original-recipient-field CRLF ] 1073 final-recipient-field CRLF 1074 action-field CRLF 1075 status-field CRLF 1076 [ remote-mta-field CRLF ] 1077 [ diagnostic-code-field CRLF ] 1078 [ last-attempt-date-field CRLF ] 1079 [ will-retry-until-field CRLF ] 1080 *( extension-field CRLF ) 1082 received-from-mta-field = 1083 "Received-From-MTA" ":" mta-name-type ";" mta-name 1085 remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name 1087 reporting-mta-field = 1088 "Reporting-MTA" ":" mta-name-type ";" mta-name 1090 status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT 1092 ; White-space characters and comments are NOT allowed within a 1093 ; status-code, though a comment enclosed in parentheses MAY follow 1094 ; the last numeric subfield of the status-code. Each numeric 1095 ; subfield within the status-code MUST be expressed without 1096 ; leading zero digits. 1098 status-field = "Status" ":" status-code 1100 will-retry-until-field = "Will-Retry-Until" ":" date-time 1101 6. Appendix - Guidelines for gatewaying DSNs 1103 NOTE: This section provides non-binding recommendations for the 1104 construction of mail gateways that wish to provide semi-transparent 1105 delivery reports between the Internet and another electronic mail 1106 system. Specific DSN gateway requirements for a particular pair of mail 1107 systems may be defined by other documents. 1109 6.1 Gatewaying from other mail systems to DSNs 1111 A mail gateway may issue a DSN to convey the contents of a "foreign" 1112 delivery or non-delivery notification over Internet mail. When there 1113 are appropriate mappings from the foreign notification elements to DSN 1114 fields, the information may be transmitted in those DSN fields. 1115 Additional information (such as might be useful in a trouble ticket or 1116 needed to tunnel the foreign notification through the Internet) may be 1117 defined in extension DSN fields. (Such fields should be given names 1118 that identify the foreign mail protocol, e.g. X400-* for X.400 NDN or DN 1119 protocol elements) 1121 The gateway must attempt to supply reasonable values for the Reporting- 1122 MTA, Final-Recipient, Action, and Status fields. These will normally be 1123 obtained by translating the values from the remote delivery or non- 1124 delivery notification into their Internet-style equivalents. However, 1125 some loss of information is to be expected. For example, the set of 1126 status-codes defined for DSNs may not be adequate to fully convey the 1127 delivery diagnostic code from the foreign system. The gateway should 1128 assign the most precise code which describes the failure condition, 1129 falling back on "generic" codes such as 2.0.0 (success), 4.0.0 1130 (temporary failure), and 5.0.0 (permanent failure) when necessary. The 1131 actual foreign diagnostic code should be retained in the Diagnostic-Code 1132 field (with an appropriate diagnostic-type value) for use in trouble 1133 tickets or tunneling. 1135 The sender-specified recipient address, and the original envelope-id, if 1136 present in the foreign transport envelope, should be preserved in the 1137 Original-Recipient and Original-Envelope-ID fields. 1139 The gateway should also attempt to preserve the "final" recipient 1140 addresses and MTA names from the foreign system. Whenever possible, 1141 foreign protocol elements should be encoded as meaningful printable 1142 ASCII strings. 1144 For DSNs produced from foreign delivery or nondelivery notifications, 1145 the name of the gateway MUST appear in the DSN-Gateway field of the DSN. 1147 6.2 Gatewaying from DSNs to other mail systems 1149 It may be possible to gateway DSNs from the Internet into a foreign mail 1150 system. The primary purpose of such gatewaying is to convey delivery 1151 status information in a form that is usable by the destination system. 1152 A secondary purpose is to allow "tunneling" of DSNs through foreign mail 1153 systems, in case the DSN may be gatewayed back into the Internet. 1155 In general, the recipient of the DSN (i.e., the sender of the original 1156 message) will want to know, for each recipient: the closest available 1157 approximation to the original recipient address, the delivery status 1158 (success, failure, or temporary failure), and for failed deliveries, a 1159 diagnostic code that describes the reason for the failure. 1161 If possible, the gateway should attempt to preserve the Original- 1162 Recipient address and Original-Envelope-ID (if present), in the 1163 resulting foreign delivery status report. 1165 When reporting delivery failures, if the diagnostic-type subfield of the 1166 Diagnostic-Code field indicates that the original diagnostic code is 1167 understood by the destination environment, the information from the 1168 Diagnostic-Code field should be used. Failing that, the information in 1169 the Status field should be mapped into the closest available diagnostic 1170 code used in the destination environment. 1172 If it is possible to tunnel a DSN through the destination environment, 1173 the gateway specification may define a means of preserving the DSN 1174 information in the delivery status reports used by that environment. 1176 7. Appendix - Guidelines for use of DSNs by mailing list exploders 1178 NOTE: This section pertains only to the use of DSNs by "mailing lists" 1179 as defined in [4], section 7.2.7. 1181 DSNs are designed to be used by mailing list exploders to allow them to 1182 detect and automatically delete recipients for whom mail delivery fails 1183 repeatedly. 1185 When forwarding a message to list subscribers, the mailing list exploder 1186 should always set the envelope return address (e.g. SMTP MAIL FROM 1187 address) to point to a special address which is set up to received 1188 nondelivery reports. A "smart" mailing list exploder can therefore 1189 intercept such nondelivery reports, and if they are in the DSN format, 1190 automatically examine them to determine for which recipients a message 1191 delivery failed or was delayed. 1193 The Original-Recipient field should be used if available, since it 1194 should exactly match the subscriber address known to the list. If the 1195 Original-Recipient field is not available, the recipient field may 1196 resemble the list subscriber address. Often, however, the list 1197 subscriber will have forwarded his mail to a different address, or the 1198 address may be subject to some re-writing, so heuristics may be required 1199 to successfully match an address from the recipient field. Care is 1200 needed in this case to minimize the possibility of false matches. 1202 The reason for delivery failure can be obtained from the Status and 1203 Action fields, and from the Diagnostic-Code field (if the status-type is 1204 recognized). Reports for recipients with action values other than 1205 "failed" can generally be ignored; in particular, subscribers should not 1206 be removed from a list due to "delayed" reports. 1208 In general, almost any failure status code (even a "permanent" one) can 1209 result from a temporary condition. It is therefore recommended that a 1210 list exploder not delete a subscriber based on any single failure DSN 1211 (regardless of the status code), but only on the persistence of delivery 1212 failure over a period of time. 1214 However, some kinds of failures are less likely than others to have been 1215 caused by temporary conditions, and some kinds of failures are more 1216 likely to be noticed and corrected quickly than others. Once more 1217 precise status codes are defined, it may be useful to differentiate 1218 between the status codes when deciding whether to delete a subscriber. 1219 For example, on a list with a high message volume, it might be desirable 1220 to temporarily suspend delivery to a recipient address which causes 1221 repeated "temporary" failures, rather than simply deleting the 1222 recipient. The duration of the suspension might depend on the type of 1223 error. On the other hand, a "user unknown" error which persisted for 1224 several days could be considered a reliable indication that address were 1225 no longer valid. 1227 8. Appendix - IANA registration forms for DSN types 1229 The forms below are for use when registering a new address-type, 1230 diagnostic-type, or MTA-name-type with the Internet Assigned Numbers 1231 Authority (IANA). Each piece of information requested by a registration 1232 form may be satisfied either by providing the information on the form 1233 itself, or by including a reference to a published, publicly available 1234 specification which includes the necessary information. IANA MAY reject 1235 DSN type registrations because of incomplete registration forms, 1236 imprecise specifications, or inappropriate type names. 1238 To register a DSN type, complete the applicable form below and send it 1239 via Internet electronic mail to . 1241 8.1 IANA registration form for address-type 1243 A registration for a DSN address-type MUST include the following 1244 information: 1246 (a) The proposed address-type name. 1248 (b) The syntax for mailbox addresses of this type, specified using BNF, 1249 regular expressions, ASN.1, or other non-ambiguous language. 1251 (c) If addresses of this type are not composed entirely of graphic 1252 characters from the US-ASCII repertoire, a specification for how 1253 they are to be encoded as graphic US-ASCII characters in a DSN 1254 Original-Recipient or Final-Recipient DSN field. 1256 (d) [optional] A specification for how addresses of this type are to be 1257 translated to and from Internet electronic mail addresses. 1259 8.2 IANA registration form for diagnostic-type 1261 A registration for a DSN address-type MUST include the following 1262 information: 1264 (a) The proposed diagnostic-type name. 1266 (b) A description of the syntax to be used for expressing diagnostic 1267 codes of this type as graphic characters from the US-ASCII 1268 repertoire. 1270 (c) A list of valid diagnostic codes of this type and the meaning of 1271 each code. 1273 (d) [optional] A specification for mapping from diagnostic codes of this 1274 type to DSN status codes (as defined in [5]). 1276 8.3 IANA registration form for MTA-name-type 1278 A registration for a DSN MTA-name-type must include the following 1279 information: 1281 (a) The proposed MTA-name-type name. 1283 (b) A description of the syntax of MTA names of this type, using BNF, 1284 regular expressions, ASN.1, or other non-ambiguous language. 1286 (c) If MTA names of this type do not consist entirely of graphic 1287 characters from the US-ASCII repertoire, a specification for how an 1288 MTA name of this type should be expressed as a sequence of graphic 1289 US-ASCII characters. 1291 9. Appendix - Examples 1293 NOTE: These examples are provided as illustration only, and are not 1294 considered part of the DSN protocol specification. If an example 1295 conflicts with the protocol definition above, the example is wrong. 1297 Likewise, the use of *-type subfield names or extension fields in these 1298 examples is not to be construed as a definition for those type names or 1299 extension fields. 1301 These examples were manually translated from bounced messages using 1302 whatever information was available. 1304 9.1 This is a simple DSN issued after repeated attempts to deliver a 1305 message failed. In this case, the DSN is issued by the same MTA from 1306 which the message was originated. 1308 Date: Thu, 7 Jul 1994 17:16:05 -0400 1309 From: Mail Delivery Subsystem 1310 Message-Id: <199407072116.RAA14128@CS.UTK.EDU> 1311 Subject: Returned mail: Cannot send message for 5 days 1312 To: 1313 MIME-Version: 1.0 1314 Content-Type: multipart/report; report-type=delivery-status; 1315 boundary="RAA14128.773615765/CS.UTK.EDU" 1317 --RAA14128.773615765/CS.UTK.EDU 1319 The original message was received at Sat, 2 Jul 1994 17:10:28 -0400 1320 from root@localhost 1322 ----- The following addresses had delivery problems ----- 1323 (unrecoverable error) 1325 ----- Transcript of session follows ----- 1326 ... Deferred: Connection timed out 1327 with larry.slip.umd.edu. 1328 Message could not be delivered for 5 days 1329 Message will be deleted from queue 1331 --RAA14128.773615765/CS.UTK.EDU 1332 content-type: message/delivery-status 1334 Reporting-MTA: dns; cs.utk.edu 1336 Original-Recipient: rfc822;louisl@larry.slip.umd.edu 1337 Final-Recipient: rfc822;louisl@larry.slip.umd.edu 1338 Action: failure 1339 Status: 4.0.0 1340 Diagnostic-Code: smtp; 426 connection timed out 1341 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1343 --RAA14128.773615765/CS.UTK.EDU 1344 content-type: message/rfc822 1346 [original message goes here] 1347 --RAA14128.773615765/CS.UTK.EDU-- 1348 9.2 This is another DSN issued by the sender's MTA, which contains 1349 details of multiple delivery attempts. Some of these were detected 1350 locally, and others by a remote MTA. 1352 Date: Fri, 8 Jul 1994 09:21:47 -0400 1353 From: Mail Delivery Subsystem 1354 Subject: Returned mail: User unknown 1355 To: 1356 MIME-Version: 1.0 1357 Content-Type: multipart/report; report-type=delivery-status; 1358 boundary="JAA13167.773673707/CS.UTK.EDU" 1360 --JAA13167.773673707/CS.UTK.EDU 1361 content-type: text/plain; charset=us-ascii 1363 ----- The following addresses had delivery problems ----- 1364 (unrecoverable error) 1365 (unrecoverable error) 1367 --JAA13167.773673707/CS.UTK.EDU 1368 content-type: message/delivery-status 1370 Reporting-MTA: dns; cs.utk.edu 1372 Original-Recipient: rfc822;arathib@vnet.ibm.com 1373 Final-Recipient: rfc822;arathib@vnet.ibm.com 1374 Action: failure 1375 Status: 5.0.0 (permanent failure) 1376 Diagnostic-Code: smtp; 1377 550 'arathib@vnet.IBM.COM' is not a registered gateway user 1378 Remote-MTA: dns; vnet.ibm.com 1380 Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com 1381 Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com 1382 Action: delayed 1383 Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure) 1385 Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu 1386 Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu 1387 Action: failure 1388 Status: 5.0.0 1389 Diagnostic-Code: smtp; 550 user unknown 1390 Remote-MTA: dns; sdcc13.ucsd.edu 1392 --JAA13167.773673707/CS.UTK.EDU 1393 content-type: message/rfc822 1395 [original message goes here] 1396 --JAA13167.773673707/CS.UTK.EDU-- 1397 9.3 A delivery report generated by Message Router (MAILBUS) and 1398 gatewayed by PMDF_MR to a DSN. In this case the gateway did not have 1399 sufficient information to supply an original-recipient address. 1401 Disclose-recipients: prohibited 1402 Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT) 1403 From: Message Router Submission Agent 1404 Subject: Status of : Re: Battery current sense 1405 To: owner-ups-mib@CS.UTK.EDU 1406 Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com> 1407 MIME-version: 1.0 1408 content-type: multipart/report; report-type=delivery-status; 1409 boundary="84229080704991.122306.SYS30" 1411 --84229080704991.122306.SYS30 1412 content-type: text/plain 1414 Invalid address - nair_s 1415 %DIR-E-NODIRMTCH, No matching Directory Entry found 1417 --84229080704991.122306.SYS30 1418 content-type: message/delivery-status 1420 Reporting-MTA: mailbus; SYS30 1422 Final-Recipient: unknown; nair_s 1423 Status: 5.0.0 (unknown permanent failure) 1424 Action: failure 1425 --84229080704991.122306.SYS30-- 1426 9.4 A delay report from a multiprotocol MTA. Note that there is no 1427 returned content, so no third body part appears in the DSN. 1429 From: 1430 Message-Id: <199407092338.TAA23293@CS.UTK.EDU> 1431 Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk 1432 id ; 1433 Sun, 10 Jul 1994 00:36:51 +0100 1434 To: owner-info-mime@cs.utk.edu 1435 Date: Sun, 10 Jul 1994 00:36:51 +0100 1436 Subject: WARNING: message delayed at "nsfnet-relay.ac.uk" 1437 content-type: multipart/report; report-type=delivery-status; 1438 boundary=foobar 1440 --foobar 1441 content-type: text/plain 1443 The following message: 1445 UA-ID: Reliable PC (... 1446 Q-ID: sun2.nsf:77/msg.11820-0 1448 has not been delivered to the intended recipient: 1450 thomas@de-montfort.ac.uk 1452 despite repeated delivery attempts over the past 24 hours. 1454 The usual cause of this problem is that the remote system is 1455 temporarily unavailable. 1457 Delivery will continue to be attempted up to a total elapsed 1458 time of 168 hours, ie 7 days. 1460 You will be informed if delivery proves to be impossible 1461 within this time. 1463 Please quote the Q-ID in any queries regarding this mail. 1465 --foobar 1466 content-type: message/delivery-status 1468 Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk 1470 Final-Recipient: rfc822;thomas@de-montfort.ac.uk 1471 Status: 4.0.0 (unknown temporary failure) 1472 Action: delayed 1474 --foobar-- 1475 10. Acknowledgments 1477 The authors wish to thank the following people for their reviews of 1478 earlier drafts of this document and their suggestions for improvement: 1479 Eric Allman, Harald Alvestrand, Allan Cargille, Jim Conklin, Peter 1480 Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve 1481 Kille, John Klensin, John Gardiner Myers, Mark Nahabedian, Julian 1482 Onions, Jacob Palme, Jean Charles Roy, and Gregory Sheehan. 1484 11. References 1486 [1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", 1487 RFC 1521, Bellcore, Innosoft, September 1993. 1489 [2] Vaudreuil, G. "The Multipart/Report Content Type for the Reporting 1490 of Mail System Administrative Messages", Internet-Draft draft-ietf- 1491 notary-mime-report-03.txt, 5 May 1995. 1493 [3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1494 USC/Information Sciences Institute, August 1982. 1496 [4] Moore, K. "SMTP Service Extension for Delivery Status 1497 Notifications", Internet-Draft draft-ietf-notary-smtp-drpt-04.txt, 1498 29 May 1995. 1500 [5] Vaudreuil, G. "Enhanced Mail System Status Codes", Internet-Draft 1501 draft-ietf-notary-status-03.txt, 5 May 1995. 1503 [6] Crocker, D., "Standard for the Format of ARPA Internet Text 1504 Messages", STD 11, RFC 822, UDEL, August 1982. 1506 [7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two: 1507 Message Header Extensions for Non-Ascii Text", RFC 1522, University 1508 of Tennessee, September 1993. 1510 [8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and 1511 Support", RFC 1123, October 1989. 1513 [9] Partridge, C. "Duplicate messages and SMTP", RFC 1047, February 1514 1988. 1516 11. Author's Addresses 1518 Keith Moore 1519 University of Tennessee 1520 107 Ayres Hall 1521 Knoxville, TN 37996-1301 1522 USA 1523 email: moore@cs.utk.edu 1524 voice: +1 615 974 3126 1525 fax: +1 615 974 8296 1527 Gregory M. Vaudreuil 1528 Octel Network Services 1529 17080 Dallas Parkway 1530 Dallas, TX 75248-1905 1531 USA 1532 email: Greg.Vaudreuil@Octel.Com