idnits 2.17.1 draft-freed-smtperror-00.txt: ** The Abstract section seems to be numbered 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-26) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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. ** The abstract seems to contain references ([RFC-821,RFC-1869]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 54 has weird spacing: '...memo uses the...' == Line 202 has weird spacing: '...omitted enhan...' -- 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 (March 1996) is 10269 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) == Unused Reference: 'RFC-821' is defined on line 216, but no explicit reference was found in the text == Unused Reference: 'RFC-1869' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'RFC-1893' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'RFC-1894' is defined on line 228, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1893 (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 1894 (Obsoleted by RFC 3464) Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ned Freed, Innosoft 2 Internet Draft 4 SMTP Service Extension for 5 Returning Enhanced Error Codes 7 March 1996 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or obsoleted 19 by other documents at any time. It is not appropriate to use 20 Internet-Drafts as reference material or to cite them other 21 than as a "working draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please 24 check the 1id-abstracts.txt listing contained in the 25 Internet-Drafts Shadow Directories on ds.internic.net (US East 26 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 27 or munnari.oz.au (Pacific Rim). 29 1. Abstract 31 This memo defines an extension to the SMTP service [RFC-821, 32 RFC-1869] whereby an SMTP server augments its responses with 33 the enhanced mail system status codes defined in RFC 1893. 34 These codes can then be used to provide more informative 35 explanations of error conditions, especially in the context of 36 the delivery status notifications format defined in RFC 1894. 38 2. Introduction 40 Although SMTP is widely and robustly deployed, various 41 extensions have been requested by parts of the Internet 42 community. In particular, in the modern, international, and 43 multilingual Internet a need exists to assign codes to 44 specific error conditions that can be translated into 45 different languages. RFC 1893 defines such a set of status 46 codes and RFC 1894 defines a mechanism to send such coded 47 material to users. However, in many cases the agent creating 48 the RFC 1894 delivery status notification is doing so in 49 response to errors it received from a remote SMTP server. 51 As such, remote servers need a mechanism for embedding 52 enhanced status codes in their responses as well as a way to 53 indicate to a client when they are in fact doing this. This 54 memo uses the SMTP extension mechanism described in RFC 1869 55 to define such a mechanism. 57 3. Framework for the Enhanced Error Statuses Extension 59 The enhanced error statuses transport extension is laid out as 60 follows: 62 (1) the name of the SMTP service extension defined here is 63 Enhanced-Status-Codes; 65 (2) the EHLO keyword value associated with the extension is 66 ENHANCEDSTATUSCODES; 68 (3) no parameter is used with the ENHANCEDSTATUSCODES EHLO 69 keyword; 71 (4) the text part of all 2xx, 4xx, and 5xx SMTP responses 72 other than the initial greeting and any response to 73 HELO or EHLO are prefaced with a status code as defined 74 in RFC 1893. This status code is always followed by one 75 or more spaces. 77 (5) no additional SMTP verbs are defined by this extension; 78 and, 80 (6) the next section specifies how support for the 81 extension affects the behavior of a server and client 82 SMTP. 84 4. The Enhanced-Status-Codes service extension 86 Servers supporting the Enhanced-Status-Codes extension must 87 preface the text part of almost all response lines with a 88 status code. As in RFC 1893, the syntax of these status codes 89 is given by the ABNF: 91 status-code ::= class "." subject "." detail 92 class ::= "2" / "4" / "5" 93 subject ::= 1*3digit 94 detail ::= 1*3digit 96 These codes must appear in all 2xx, 4xx, and 5xx response 97 lines other than initial greeting and any response to HELO or 98 EHLO. Note that 3xx responses are NOT included in this list. 100 All status codes returned by the server must agree with the 101 primary response code, that is, a 2xx response must 102 incorporate a 2.X.X code, a 4xx response must incorporate a 103 4.X.X code, and a 5xx response must incorporate a 5.X.X code. 105 When responses are continued across multiple lines the same 106 status code must appear at the beginning of the text in each 107 line of the response. 109 Servers supporting this extension must attach enhanced status 110 codes to their responses regardless of whether or not EHLO is 111 employed by the client. 113 5. Usage Example 115 The following dialogue illustrates the use of enhanced status 116 codes by a server: 118 S: 119 C: 120 S: 220 dbc.mtview.ca.us SMTP service ready 121 C: EHLO ymir.claremont.edu 122 S: 250-dbc.mtview.ca.us says hello 123 S: 250 ENHANCEDSTATUSCODES 124 C: MAIL FROM: 125 S: 250 2.1.0 Originator ok 126 C: RCPT TO: 127 S: 250 2.1.5 Recipient ok 128 C: RCPT TO: 129 S: 550 5.1.1 Mailbox "nosuchuser" does not exist 130 C: RCPT TO: 131 S: 551-5.7.1 Forwarding to remote hosts disabled 132 S: 551 5.7.1 Select another host to act as your forwarder 133 C: DATA 134 S: 354 Send message, ending in CRLF.CRLF. 135 ... 136 C: . 137 S: 250 2.6.0 Message accepted 138 C: QUIT 139 S: 221 2.0.0 Goodbye 141 The client that receives these responses might then send a 142 nondelivery notification of the general form: 144 Date: Mon, 11 Mar 1996 09:21:47 -0400 145 From: Mail Delivery Subsystem 146 Subject: Returned mail 147 To: 148 MIME-Version: 1.0 149 Content-Type: multipart/report; report-type=delivery-status; 150 boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU" 152 --JAA13167.773673707/YMIR.CLAREMONT.EDU 153 content-type: text/plain; charset=us-ascii 155 ----- Mail was successfully relayed to 156 the following addresses ----- 158 160 ----- The following addresses had delivery problems ----- 161 162 (Mailbox "nosuchuser" does not exist) 163 164 (Forwarding to remote hosts disabled) 166 --JAA13167.773673707/YMIR.CLAREMONT.EDU 167 content-type: message/delivery-status 169 Reporting-MTA: dns; ymir.claremont.edu 170 Original-Recipient: rfc822;mrose@dbc.mtview.ca.us 171 Final-Recipient: rfc822;mrose@dbc.mtview.ca.us 172 Action: relayed 173 Status: 2.1.5 (Destination address valid) 174 Diagnostic-Code: smtp; 175 250 Recipient ok 176 Remote-MTA: dns; dbc.mtview.ca.us 178 Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us 179 Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us 180 Action: failed 181 Status: 5.1.1 (Bad destination mailbox address) 182 Diagnostic-Code: smtp; 183 550 Mailbox "nosuchuser" does not exist 184 Remote-MTA: dns; dbc.mtview.ca.us 186 Original-Recipient: rfc822;remoteuser@isi.edu 187 Final-Recipient: rfc822;remoteuser@isi.edu 188 Action: failed 189 Status: 5.7.1 (Delivery not authorized, message refused) 190 Diagnostic-Code: smtp; 191 551 Forwarding to remote hosts disabled 192 Select another host to act as your forwarder 193 Remote-MTA: dns; dbc.mtview.ca.us 195 --JAA13167.773673707/YMIR.CLAREMONT.EDU 196 content-type: message/rfc822 198 [original message goes here] 199 --JAA13167.773673707/YMIR.CLAREMONT.EDU-- 201 Note that in order to reduce clutter the reporting MTA has 202 omitted enhanced status code information from the 203 diagnostic-code fields it has generated. 205 6. Security Considerations 207 Additional detail in server responses axiomatically provides 208 additional information about the server. It is conceivable 209 that additional information of this sort may be of assistance 210 in circumventing server security. The advantages of provides 211 additional information must always be weighed against the 212 security implications of doing so. 214 7. References 216 [RFC-821] 217 Postel, J., "Simple Mail Transfer Protocol", RFC 821, 218 August, 1982. (August, 1982). 220 [RFC-1869] 221 Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, 222 N., "SMTP Service Extensions", RFC 1869, November, 1995. 224 [RFC-1893] 225 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 226 1893, January, 1996. 228 [RFC-1894] 229 Moore, K., Vaudreuil, G., "An Extensible Message Format 230 for Delivery Status Notifications", RFC 1894, January, 231 1996. 233 8. Author Address 235 Ned Freed 236 Innosoft International, Inc. 237 1050 East Garvey Avenue South 238 West Covina, CA 91790 239 USA 240 tel: +1 818 919 3600 fax: +1 818 919 3614 241 email: ned@innosoft.com