idnits 2.17.1 draft-ietf-notary-mime-report-03.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 35 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 140 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 131 looks like a reference -- Missing reference section? 'DSN' on line 125 looks like a reference -- Missing reference section? 'DRPT' on line 134 looks like a reference -- Missing reference section? 'RFC822' on line 128 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. -------------------------------------------------------------------------------- 2 Network Working Group Greg Vaudreuil 3 Internet Draft Octel Network Services 4 Expires: 11/5/95 May 5, 1995 6 The Multipart/Report Content Type 7 for the Reporting of 8 Mail System Administrative Messages 10 12 1. 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, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet Drafts as reference material or to 22 cite them other than as a "work in progress". 24 2. The Multipart/Report MIME content-type 26 The Multipart/Report MIME content-type is a general "family" or 27 "container" type for electronic mail reports of any kind. Although 28 this memo defines only the use of the Multipart/Report content-type 29 with respect to delivery status reports, mail processing programs 30 will benefit if a single content-type is used to for all kinds of 31 reports. 33 The Multipart/Report content-type is defined as follows: 35 MIME type name: multipart 36 MIME subtype name: report 37 Required parameters: boundary, report-type 38 Optional parameters: none 39 Encoding considerations: 7bit should always be adequate 40 Security considerations: see section 5 of this memo. 42 The syntax of Multipart/Report is identical to the Multipart/Mixed 43 content type defined in [MIME]. When used to send a report, the 44 Multipart/Report content-type must be the top-level MIME content 45 type for any report message. The report-type parameter identifies 46 the type of report. The parameter is the MIME content sub-type of 47 the second body part of the Multipart/Report. 49 User agents and gateways must be able to automatically determine 50 that a message is a mail system report and should be processed as 51 such. Placing the Multipart/Report as the outermost content 52 provides a mechanism whereby an auto-processor may detect through 53 parsing the RFC 822 headers that the message is a report. 55 The Multipart/Report content-type contains either two or three sub- 56 parts, in the following order: 58 (1) [required] The first body part contains human consumable 59 message. The purpose of this message is to provide an easily- 60 understood description of the condition(s) that caused the 61 report to be generated, for a human reader who may not have an 62 user agent capable of interpreting the second section of the 63 Multipart/Report. 65 The text in the first section text may be in any MIME standards- 66 track content-type, charset, or language. Where a description 67 of the error is desired in several languages or several media, a 68 Multipart/Alternative construct may be used. 70 This body part may also be used to send detailed trace 71 information that cannot be easily formatted into a 72 Message/Report body part. 74 (2) [required] A machine parsable body part containing an account 75 of the reported message handling event. The purpose of this body 76 part is to provide a machine-readable description of the 77 condition(s) which caused the report to be generated, along with 78 details not present in the Text/Plain body part that may be 79 useful to human experts. An initial body part, 80 Message/delivery-status is defined in [DSN] 82 (3) [optional] A body part containing the returned message or a 83 portion thereof. This information may be useful to aid human 84 experts in diagnosing problems. (Although it may also be useful 85 to allow the sender to identify the message which the report was 86 issued, it is hoped that the envelope-id and original-recipient- 87 address returned in the Message/Report body part will replace 88 the traditional use of the returned content for this purpose.) 90 Return of content may be wasteful of network bandwidth and a variety 91 of implementation strategies can be used. Generally the sender 92 should choose the appropriate strategy and inform the recipient of 93 the required level of returned content required. In the absence of 94 an explicit request for level of return of content such as that 95 provided in [DRPT], the agent which generated the delivery service 96 report should return the full message content. 98 3. The Text/RFC822-Headers MIME content-type 100 The Text/RFC822-Headers MIME content-type provides a mechanism to 101 label and return only the RFC 822 headers of a failed message. 102 These headers are not the complete message and should not be 103 returned as a Message/RFC822. The returned headers are useful for 104 correlating the erred message and for diagnostics based on the 105 received: lines. 107 The Text/RFC822-Headers content-type is defined as follows: 109 MIME type name: Message 110 MIME subtype name: RFC822-Headers 111 Required parameters: None 112 Optional parameters: none 113 Encoding considerations: 7 bit is sufficient for normal RFC822 114 headers, however, if the headers are broken and require 115 encoding, they may be encoded in quoted-printable. 116 Security considerations: see section 5 of this memo. 118 The Text/RFC822-headers body part should contain all the RFC822 119 header lines from the message which caused the report. The RFC822 120 headers include all lines prior to the blank line in the message. 121 They include the MIME-Version and MIME Content- headers. 123 4. References 125 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 126 Delivery Status Reports", Internet-Draft. 128 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text 129 Messages", STD 11, RFC 822, UDEL, August 1982. 131 [MIME] Borenstein, N., Freed, N., "Multipurpose Internet Mail 132 Extensions", RFC 1521, Bellcore, Innosoft, June 1992. 134 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status 135 Notifications", Internet Draft. 137 5. Security Consideration 139 Automated use of report types without authentication presents 140 several security issues. Forging negative reports presents the 141 opportunity for denial-of-service attacks when the reports are used 142 for automated maintenance of directories or mailing lists. Forging 143 positive reports may cause the sender to incorrectly believe a 144 message was delivered when it was not. 146 6. Author's Address 148 Gregory M. Vaudreuil 149 Octel Network Services 150 17060 Dallas Parkway 151 Dallas, TX 75248-1905 152 Greg.Vaudreuil@Octel.com 153 Voice/Fax: +1-214-733-2722