idnits 2.17.1 draft-vaudreuil-1892bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 are 63 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 16, 2002) is 8018 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) == Missing Reference: 'RFC2119' is mentioned on line 65, but not defined == Missing Reference: 'Required' is mentioned on line 123, but not defined == Missing Reference: 'Optional' is mentioned on line 129, but not defined == Unused Reference: 'SMTP' is defined on line 189, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1894 (ref. 'DSN') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (ref. 'MIME') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1891 (ref. 'DRPT') (Obsoleted by RFC 3461) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Greg Vaudreuil 3 Expires in six months Lucent Technologies 4 April 16, 2002 6 The Multipart/Report Content Type 7 for the Reporting of 8 Mail System Administrative Messages 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC 2026. 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are valid for a maximum of six months and may be 23 updated, replaced, or obsoleted by other documents at any time. It is 24 inappropriate to use Internet Drafts as reference material or to cite 25 them other than as a "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 This Internet-Draft is in conformance with Section 10 of RFC 2026. 39 Abstract 41 The Multipart/Report MIME content-type is a general "family" or 42 "container" type for electronic mail reports of any kind. Although 43 this memo defines only the use of the Multipart/Report content-type 44 with respect to delivery status reports, mail processing programs will 45 benefit if a single content-type is used to for all kinds of reports. 47 This document is part of a four document set describing the delivery 48 status report service. This collection includes the SMTP extensions 49 to request delivery status reports, a MIME content for the reporting 50 of delivery reports, an enumeration of extended status codes, and this 51 document describing a multipart container for the delivery report, the 52 original message, and a human-friendly summary of the failure. 54 Working Group Summary 56 RFC 1892 was a product of the Notary working group. This document is 57 a revision of that document providing clarifications as necessary to 58 advance to draft standard. 60 Document Conventions 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [RFC2119]. 66 Table of Contents 68 1. THE MULTIPART/REPORT CONTENT TYPE.................................3 69 2. THE TEXT/RFC822-HEADERS...........................................4 70 3. SECURITY CONSIDERATIONS...........................................5 71 4. REFERENCES........................................................5 72 5. COPYRIGHT NOTICE..................................................6 73 6. AUTHOR'S ADDRESS..................................................6 74 APPENDIX A - CHANGES FROM RFC1893....................................7 76 1. The Multipart/Report Content Type 78 The Multipart/Report MIME content-type is a general "family" or 79 "container" type for electronic mail reports of any kind. Although 80 this memo defines only the use of the Multipart/Report content-type 81 with respect to delivery status reports, mail processing programs will 82 benefit if a single content-type is used to for all kinds of reports. 84 The Multipart/Report content-type is defined as follows: 86 MIME type name: multipart 87 MIME subtype name: report 88 Required parameters: boundary, report-type 89 Optional parameters: none 90 Encoding considerations: 7bit should always be adequate 91 Security considerations: see section 4 of this memo. 93 The syntax of Multipart/Report is identical to the Multipart/Mixed 94 content type defined in [MIME]. When used to send a report, the 95 Multipart/Report content-type must be the top-level MIME content type 96 for any report message. The report-type parameter identifies the type 97 of report. The parameter is the MIME content sub-type of the second 98 body part of the Multipart/Report. 100 User agents and gateways must be able to automatically determine 101 that a message is a mail system report and should be processed as 102 such. Placing the Multipart/Report as the outermost content 103 provides a mechanism whereby an auto-processor may detect through 104 parsing the RFC 822 headers that the message is a report. 106 The Multipart/Report content-type contains either two or three sub- 107 parts, in the following order: 109 1) [Required] The first body part contains human readable message. The 110 purpose of this message is to provide an easily understood description 111 of the condition(s) that caused the report to be generated, for a 112 human reader who may not have an user agent capable of interpreting 113 the second section of the Multipart/Report. 115 The text in the first section may be in any MIME standards-track 116 content-type, charset, or language. Where a description of the error 117 is desired in several languages or several media, a 118 Multipart/Alternative construct may be used. 120 This body part may also be used to send detailed information that 121 cannot be easily formatted into a Message/Report body part. 123 (2) [Required] A machine parsable body part containing an account of 124 the reported message handling event. The purpose of this body part is 125 to provide a machine-readable description of the condition(s) that 126 caused the report to be generated, along with details not present in 127 the first body part that may be useful to human experts. An initial 128 body part, Message/delivery-status is defined in [DSN] 129 (3) [Optional] A body part containing the returned message or a 130 portion thereof. This information may be useful to aid human experts 131 in diagnosing problems. (Although it may also be useful to allow the 132 sender to identify the message which the report was issued, it is 133 hoped that the envelope-id and original-recipient- address returned in 134 the Message/Report body part will replace the traditional use of the 135 returned content for this purpose.) 137 Return of content may be wasteful of network bandwidth and a variety 138 of implementation strategies can be used. Generally the sender should 139 choose the appropriate strategy and inform the recipient of the 140 required level of returned content required. In the absence of an 141 explicit request for level of return of content such as that provided 142 in [DRPT], the agent that generated the delivery service report should 143 return the full message content. 145 When data not encoded in 7 bits is to be returned, and the return path 146 is not guaranteed to be 8-bit capable, two options are available. The 147 original message MAY be re-encoded into a legal 7-bit MIME message or 148 the Text/RFC822-Headers content-type MAY be used to return only the 149 original message headers. 151 2. The Text/RFC822-Headers content-type 153 The Text/RFC822-Headers MIME content-type provides a 154 mechanism to label and return only the RFC 822 headers of 155 a failed message. These headers are not the complete 156 message and should not be returned as a Message/RFC822. 157 The returned headers are useful for identifying the 158 failed message and for diagnostics based on the received: 159 lines. 161 The Text/RFC822-Headers content-type is defined as follows: 163 MIME type name: Text 164 MIME subtype name: RFC822-Headers 165 Required parameters: None 166 Optional parameters: none 167 Encoding considerations: 7 bit is sufficient for normal RFC822 168 headers, however, if the headers are broken and require 169 encoding to make them legal 7 bit content, they may be 170 encoded in quoted-printable. 171 Security considerations: see section 3 of this memo. 173 The Text/RFC822-headers body part should contain all the RFC822 header 174 lines from the message which caused the report. The RFC822 headers 175 include all lines prior to the blank line in the message. They include 176 the MIME-Version and MIME Content- headers. 178 3. Security Considerations 180 Automated use of report types without authentication presents several 181 security issues. Forging negative reports presents the opportunity 182 for denial-of-service attacks when the reports are used for automated 183 maintenance of directories or mailing lists. Forging positive reports 184 may cause the sender to incorrectly believe a message was delivered 185 when it was not 187 4. References 189 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 190 USC/Information Sciences Institute, August 1982. 192 [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for 193 Delivery Status Notifications", RFC 1894, University of Tennessee, 194 Octel Network Services, January 1996. 196 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text 197 Messages", STD 11, RFC 822, UDEL, August 1982. 199 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 200 Extensions", RFC 1521, Bellcore, Innosoft, June 1992. 202 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status 203 Notifications", RFC 1891, University of Tennessee, January 1996. 205 5. Copyright Notice 207 "Copyright (C) The Internet Society (2002). All Rights Reserved. 209 This document and translations of it may be copied and furnished to 210 others, and derivative works that comment on or otherwise explain it 211 or assist in its implementation may be prepared, copied, published and 212 distributed, in whole or in part, without restriction of any kind, 213 provided that the above copyright notice and this paragraph are 214 included on all such copies and derivative works. However, this 215 document itself may not be modified in any way, such as by removing 216 the copyright notice or references to the Internet Society or other 217 Internet organizations, except as needed for the purpose of developing 218 Internet standards in which case the procedures for copyrights defined 219 in the Internet Standards process MUST be followed, or as required to 220 translate it into languages other than English. 222 The limited permissions granted above are perpetual and will not be 223 revoked by the Internet Society or its successors or assigns. 225 This document and the information contained herein is provided on an 226 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 227 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 228 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 229 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 230 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 232 6. Author's Address 234 Gregory M. Vaudreuil 235 Lucent Technologies 236 17080 Dallas Parkway 237 Dallas, TX 75248-1905 238 Voice/Fax: +1-972-733-2722 239 GregV@ieee.org 241 Appendix A - Changes from RFC1892 243 Changed Authors contact information 245 Updated required standards boilerplate 247 Edited the text to make it spell-checker and grammar checker compliant