idnits 2.17.1 draft-ietf-notary-mime-report-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-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 6 months document validity. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** There are 39 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 138 has weird spacing: '...several secur...' -- 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 (May 5, 1995) is 10582 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 section? 'MIME' on line 129 looks like a reference -- Missing reference section? 'DSN' on line 123 looks like a reference -- Missing reference section? 'DRPT' on line 132 looks like a reference -- Missing reference section? 'RFC822' on line 126 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Octel Network Services 3 Expires: 11/5/95 May 5, 1995 5 The Multipart/Report Content Type 6 for the Reporting of 7 Mail System Administrative Messages 9 11 1. Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet Drafts as reference material or to 21 cite them other than as a "work in progress". 23 2. The Multipart/Report MIME content-type 25 The Multipart/Report MIME content-type is a general "family" or 26 "container" type for electronic mail reports of any kind. Although 27 this memo defines only the use of the Multipart/Report content-type 28 with respect to delivery status reports, mail processing programs 29 will benefit if a single content-type is used to for all kinds of 30 reports. 32 The Multipart/Report content-type is defined as follows: 34 MIME type name: multipart 35 MIME subtype name: report 36 Required parameters: boundary, report-type 37 Optional parameters: none 38 Encoding considerations: 7bit should always be adequate 39 Security considerations: see section 5 of this memo. 41 The syntax of Multipart/Report is identical to the Multipart/Mixed 42 content type defined in [MIME]. When used to send a report, the 43 Multipart/Report content-type must be the top-level MIME content 44 type for any report message. The report-type parameter identifies 45 the type of report. The parameter is the MIME content sub-type of 46 the second body part of the Multipart/Report. 48 User agents and gateways must be able to automatically determine 49 that a message is a mail system report and should be processed as 50 such. Placing the Multipart/Report as the outermost content 51 provides a mechanism whereby an auto-processor may detect through 52 parsing the RFC 822 headers that the message is a report. 54 The Multipart/Report content-type contains either two or three sub- 55 parts, in the following order: 57 (1) [required] The first body part contains human readable message. 58 The purpose of this message is to provide an easily-understood 59 description of the condition(s) that caused the report to be 60 generated, for a human reader who may not have an user agent 61 capable of interpreting the second section of the 62 Multipart/Report. 64 The text in the first section may be in any MIME standards-track 65 content-type, charset, or language. Where a description of the 66 error is desired in several languages or several media, a 67 Multipart/Alternative construct may be used. 69 This body part may also be used to send detailed information 70 that cannot be easily formatted into a Message/Report body part. 72 (2) [required] A machine parsable body part containing an account 73 of the reported message handling event. The purpose of this body 74 part is to provide a machine-readable description of the 75 condition(s) which caused the report to be generated, along with 76 details not present in the first body part that may be useful to 77 human experts. An initial body part, Message/delivery-status is 78 defined in [DSN] 80 (3) [optional] A body part containing the returned message or a 81 portion thereof. This information may be useful to aid human 82 experts in diagnosing problems. (Although it may also be useful 83 to allow the sender to identify the message which the report was 84 issued, it is hoped that the envelope-id and original-recipient- 85 address returned in the Message/Report body part will replace 86 the traditional use of the returned content for this purpose.) 88 Return of content may be wasteful of network bandwidth and a variety 89 of implementation strategies can be used. Generally the sender 90 should choose the appropriate strategy and inform the recipient of 91 the required level of returned content required. In the absence of 92 an explicit request for level of return of content such as that 93 provided in [DRPT], the agent which generated the delivery service 94 report should return the full message content. 96 3. The Text/RFC822-Headers MIME content-type 98 The Text/RFC822-Headers MIME content-type provides a mechanism to 99 label and return only the RFC 822 headers of a failed message. 100 These headers are not the complete message and should not be 101 returned as a Message/RFC822. The returned headers are useful for 102 identifying the failed message and for diagnostics based on the 103 received: lines. 105 The Text/RFC822-Headers content-type is defined as follows: 107 MIME type name: Text 108 MIME subtype name: RFC822-Headers 109 Required parameters: None 110 Optional parameters: none 111 Encoding considerations: 7 bit is sufficient for normal RFC822 112 headers, however, if the headers are broken and require 113 encoding, they may be encoded in quoted-printable. 114 Security considerations: see section 5 of this memo. 116 The Text/RFC822-headers body part should contain all the RFC822 117 header lines from the message which caused the report. The RFC822 118 headers include all lines prior to the blank line in the message. 119 They include the MIME-Version and MIME Content- headers. 121 4. References 123 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 124 Delivery Status Reports", Internet-Draft. 126 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text 127 Messages", STD 11, RFC 822, UDEL, August 1982. 129 [MIME] Borenstein, N., Freed, N., "Multipurpose Internet Mail 130 Extensions", RFC 1521, Bellcore, Innosoft, June 1992. 132 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status 133 Notifications", Internet Draft. 135 5. Security Consideration 137 Automated use of report types without authentication presents 138 several security issues. Forging negative reports presents the 139 opportunity for denial-of-service attacks when the reports are used 140 for automated maintenance of directories or mailing lists. Forging 141 positive reports may cause the sender to incorrectly believe a 142 message was delivered when it was not. 144 6. Author's Address 146 Gregory M. Vaudreuil 147 Octel Network Services 148 17060 Dallas Parkway 149 Dallas, TX 75248-1905 150 Greg.Vaudreuil@Octel.com 151 Voice/Fax: +1-214-733-2722