idnits 2.17.1 draft-vaudreuil-1892bis-00.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 64 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 (June 15, 2001) is 8343 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 71, but not defined == Missing Reference: 'Required' is mentioned on line 129, but not defined == Missing Reference: 'Optional' is mentioned on line 135, but not defined == Unused Reference: 'SMTP' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 200, 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 June 15, 2001 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 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 36 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 37 ftp.isi.edu (US West Coast). 39 Copyright Notice 41 Copyright (C) The Internet Society (2001). All Rights Reserved. 43 This Internet-Draft is in conformance with Section 10 of RFC 2026. 45 Abstract 47 The Multipart/Report MIME content-type is a general "family" or 48 "container" type for electronic mail reports of any kind. Although 49 this memo defines only the use of the Multipart/Report content-type 50 with respect to delivery status reports, mail processing programs will 51 benefit if a single content-type is used to for all kinds of reports. 53 This document is part of a four document set describing the delivery 54 status report service. This collection includes the SMTP extensions 55 to request delivery status reports, a MIME content for the reporting 56 of delivery reports, an enumeration of extended status codes, and this 57 document describing a multipart container for the delivery report, the 58 original message, and a human-friendly summary of the failure. 60 Working Group Summary 62 RFC 1892 was a product of the Notary working group. This document is 63 a revision of that document providing clarifications as necessary to 64 advance to draft standard. 66 Document Conventions 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC-2119 [RFC2119]. 72 Table of Contents 74 1. THE MULTIPART/REPORT CONTENT TYPE.................................3 75 2. THE TEXT/RFC822-HEADERS...........................................4 76 3. SECURITY CONSIDERATIONS...........................................5 77 4. REFERENCES........................................................5 78 5. COPYRIGHT NOTICE..................................................6 79 6. AUTHOR'S ADDRESS..................................................6 80 APPENDIX A - CHANGES FROM RFC1893....................................7 82 1. The Multipart/Report Content Type 84 The Multipart/Report MIME content-type is a general "family" or 85 "container" type for electronic mail reports of any kind. Although 86 this memo defines only the use of the Multipart/Report content-type 87 with respect to delivery status reports, mail processing programs will 88 benefit if a single content-type is used to for all kinds of reports. 90 The Multipart/Report content-type is defined as follows: 92 MIME type name: multipart 93 MIME subtype name: report 94 Required parameters: boundary, report-type 95 Optional parameters: none 96 Encoding considerations: 7bit should always be adequate 97 Security considerations: see section 4 of this memo. 99 The syntax of Multipart/Report is identical to the Multipart/Mixed 100 content type defined in [MIME]. When used to send a report, the 101 Multipart/Report content-type must be the top-level MIME content type 102 for any report message. The report-type parameter identifies the type 103 of report. The parameter is the MIME content sub-type of the second 104 body part of the Multipart/Report. 106 User agents and gateways must be able to automatically determine 107 that a message is a mail system report and should be processed as 108 such. Placing the Multipart/Report as the outermost content 109 provides a mechanism whereby an auto-processor may detect through 110 parsing the RFC 822 headers that the message is a report. 112 The Multipart/Report content-type contains either two or three sub- 113 parts, in the following order: 115 1) [Required] The first body part contains human readable message. The 116 purpose of this message is to provide an easily understood description 117 of the condition(s) that caused the report to be generated, for a 118 human reader who may not have an user agent capable of interpreting 119 the second section of the Multipart/Report. 121 The text in the first section may be in any MIME standards-track 122 content-type, charset, or language. Where a description of the error 123 is desired in several languages or several media, a 124 Multipart/Alternative construct may be used. 126 This body part may also be used to send detailed information that 127 cannot be easily formatted into a Message/Report body part. 129 (2) [Required] A machine parsable body part containing an account of 130 the reported message handling event. The purpose of this body part is 131 to provide a machine-readable description of the condition(s) that 132 caused the report to be generated, along with details not present in 133 the first body part that may be useful to human experts. An initial 134 body part, Message/delivery-status is defined in [DSN] 135 (3) [Optional] A body part containing the returned message or a 136 portion thereof. This information may be useful to aid human experts 137 in diagnosing problems. (Although it may also be useful to allow the 138 sender to identify the message which the report was issued, it is 139 hoped that the envelope-id and original-recipient- address returned in 140 the Message/Report body part will replace the traditional use of the 141 returned content for this purpose.) 143 Return of content may be wasteful of network bandwidth and a variety 144 of implementation strategies can be used. Generally the sender should 145 choose the appropriate strategy and inform the recipient of the 146 required level of returned content required. In the absence of an 147 explicit request for level of return of content such as that provided 148 in [DRPT], the agent that generated the delivery service report should 149 return the full message content. 151 When data not encoded in 7 bits is to be returned, and the return path 152 is not guaranteed to be 8-bit capable, two options are available. The 153 original message MAY be re-encoded into a legal 7-bit MIME message or 154 the Text/RFC822-Headers content-type MAY be used to return only the 155 original message headers. 157 2. The Text/RFC822-Headers content-type 159 The Text/RFC822-Headers MIME content-type provides a mechanism to 160 label and return only the RFC 822 headers of a failed message. These 161 headers are not the complete message and should not be returned as a 162 Message/RFC822. The returned headers are useful for identifying the 163 failed message and for diagnostics based on the received: lines. 165 The Text/RFC822-Headers content-type is defined as follows: 167 MIME type name: Text 168 MIME subtype name: RFC822-Headers 169 Required parameters: None 170 Optional parameters: none 171 Encoding considerations: 7 bit is sufficient for normal RFC822 172 headers, however, if the headers are broken and require 173 encoding to make them legal 7 bit content, they may be 174 encoded in quoted-printable. 175 Security considerations: see section 3 of this memo. 177 The Text/RFC822-headers body part should contain all the RFC822 header 178 lines from the message which caused the report. The RFC822 headers 179 include all lines prior to the blank line in the message. They include 180 the MIME-Version and MIME Content- headers. 182 3. Security Considerations 184 Automated use of report types without authentication presents several 185 security issues. Forging negative reports presents the opportunity 186 for denial-of-service attacks when the reports are used for automated 187 maintenance of directories or mailing lists. Forging positive reports 188 may cause the sender to incorrectly believe a message was delivered 189 when it was not 191 4. References 193 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 194 USC/Information Sciences Institute, August 1982. 196 [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for 197 Delivery Status Notifications", RFC 1894, University of Tennessee, 198 Octel Network Services, January 1996. 200 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text 201 Messages", STD 11, RFC 822, UDEL, August 1982. 203 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 204 Extensions", RFC 1521, Bellcore, Innosoft, June 1992. 206 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status 207 Notifications", RFC 1891, University of Tennessee, January 1996. 209 5. Copyright Notice 211 "Copyright (C) The Internet Society (2001). All Rights Reserved. 213 This document and translations of it may be copied and furnished to 214 others, and derivative works that comment on or otherwise explain it 215 or assist in its implementation may be prepared, copied, published and 216 distributed, in whole or in part, without restriction of any kind, 217 provided that the above copyright notice and this paragraph are 218 included on all such copies and derivative works. However, this 219 document itself may not be modified in any way, such as by removing 220 the copyright notice or references to the Internet Society or other 221 Internet organizations, except as needed for the purpose of developing 222 Internet standards in which case the procedures for copyrights defined 223 in the Internet Standards process MUST be followed, or as required to 224 translate it into languages other than English. 226 The limited permissions granted above are perpetual and will not be 227 revoked by the Internet Society or its successors or assigns. 229 This document and the information contained herein is provided on an 230 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 231 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 232 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 233 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 234 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 236 6. Author's Address 238 Gregory M. Vaudreuil 239 Lucent Technologies 240 17080 Dallas Parkway 241 Dallas, TX 75248-1905 242 Voice/Fax: +1-972-733-2722 243 GregV@ieee.org 245 Appendix A - Changes from RFC1892 247 Changed Authors contact information 249 Updated required standards boilerplate 251 Edited the text to make it spell-checker and grammar checker compliant