idnits 2.17.1 draft-freed-smtperror-01.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-23) 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '...ry special case. It MUST NOT be taken...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 225 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 (July 1996) is 10144 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 239, but no explicit reference was found in the text == Unused Reference: 'RFC-1869' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC-1893' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'RFC-1894' is defined on line 251, 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: 15 errors (**), 0 flaws (~~), 8 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 July 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. Status Codes and Negotiation 115 This specification does not provide a means for clients to 116 request that status codes be returned or that they not be 117 returned; a compliant server includes these codes in the 118 responses it sends regardless of whether or not the client 119 expects them. This is somewhat different from most other SMTP 120 extensions, where generally speaking a client must 121 specifically make a request before the extended server behaves 122 any differently than an unextended server. The omission of 123 client negotiation in this case is entirely intentional: 124 Given the generally poor state of SMTP server error code 125 implementation it is felt that any step taken towards more 126 comprehensible error codes is something that all clients, 127 extended or not, should benefit from. 129 IMPORTANT NOTE: The use of this approach in this extension 130 should be seen as a very special case. It MUST NOT be taken 131 as a license for future SMTP extensions to dramatically change 132 the nature of SMTP client-server interaction without proper 133 announcement from the server and a corresponding enabling 134 command from the client. 136 6. Usage Example 138 The following dialogue illustrates the use of enhanced status 139 codes by a server: 141 S: 142 C: 143 S: 220 dbc.mtview.ca.us SMTP service ready 144 C: EHLO ymir.claremont.edu 145 S: 250-dbc.mtview.ca.us says hello 146 S: 250 ENHANCEDSTATUSCODES 147 C: MAIL FROM: 148 S: 250 2.1.0 Originator ok 149 C: RCPT TO: 150 S: 250 2.1.5 Recipient ok 151 C: RCPT TO: 152 S: 550 5.1.1 Mailbox "nosuchuser" does not exist 153 C: RCPT TO: 154 S: 551-5.7.1 Forwarding to remote hosts disabled 155 S: 551 5.7.1 Select another host to act as your forwarder 156 C: DATA 157 S: 354 Send message, ending in CRLF.CRLF. 158 ... 159 C: . 160 S: 250 2.6.0 Message accepted 161 C: QUIT 162 S: 221 2.0.0 Goodbye 164 The client that receives these responses might then send a 165 nondelivery notification of the general form: 167 Date: Mon, 11 Mar 1996 09:21:47 -0400 168 From: Mail Delivery Subsystem 169 Subject: Returned mail 170 To: 171 MIME-Version: 1.0 172 Content-Type: multipart/report; report-type=delivery-status; 173 boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU" 175 --JAA13167.773673707/YMIR.CLAREMONT.EDU 176 content-type: text/plain; charset=us-ascii 178 ----- Mail was successfully relayed to 179 the following addresses ----- 181 183 ----- The following addresses had delivery problems ----- 184 185 (Mailbox "nosuchuser" does not exist) 186 187 (Forwarding to remote hosts disabled) 189 --JAA13167.773673707/YMIR.CLAREMONT.EDU 190 content-type: message/delivery-status 192 Reporting-MTA: dns; ymir.claremont.edu 194 Original-Recipient: rfc822;mrose@dbc.mtview.ca.us 195 Final-Recipient: rfc822;mrose@dbc.mtview.ca.us 196 Action: relayed 197 Status: 2.1.5 (Destination address valid) 198 Diagnostic-Code: smtp; 199 250 Recipient ok 200 Remote-MTA: dns; dbc.mtview.ca.us 202 Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us 203 Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us 204 Action: failed 205 Status: 5.1.1 (Bad destination mailbox address) 206 Diagnostic-Code: smtp; 207 550 Mailbox "nosuchuser" does not exist 208 Remote-MTA: dns; dbc.mtview.ca.us 209 Original-Recipient: rfc822;remoteuser@isi.edu 210 Final-Recipient: rfc822;remoteuser@isi.edu 211 Action: failed 212 Status: 5.7.1 (Delivery not authorized, message refused) 213 Diagnostic-Code: smtp; 214 551 Forwarding to remote hosts disabled 215 Select another host to act as your forwarder 216 Remote-MTA: dns; dbc.mtview.ca.us 218 --JAA13167.773673707/YMIR.CLAREMONT.EDU 219 content-type: message/rfc822 221 [original message goes here] 222 --JAA13167.773673707/YMIR.CLAREMONT.EDU-- 224 Note that in order to reduce clutter the reporting MTA has 225 omitted enhanced status code information from the 226 diagnostic-code fields it has generated. 228 7. Security Considerations 230 Additional detail in server responses axiomatically provides 231 additional information about the server. It is conceivable 232 that additional information of this sort may be of assistance 233 in circumventing server security. The advantages of provides 234 additional information must always be weighed against the 235 security implications of doing so. 237 8. References 239 [RFC-821] 240 Postel, J., "Simple Mail Transfer Protocol", RFC 821, 241 August, 1982. (August, 1982). 243 [RFC-1869] 244 Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, 245 N., "SMTP Service Extensions", RFC 1869, November, 1995. 247 [RFC-1893] 248 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 249 1893, January, 1996. 251 [RFC-1894] 252 Moore, K., Vaudreuil, G., "An Extensible Message Format 253 for Delivery Status Notifications", RFC 1894, January, 254 1996. 256 9. Author Address 258 Ned Freed 259 Innosoft International, Inc. 260 1050 East Garvey Avenue South 261 West Covina, CA 91790 262 USA 263 tel: +1 818 919 3600 fax: +1 818 919 3614 264 email: ned@innosoft.com