idnits 2.17.00 (12 Aug 2021) /tmp/idnits37501/draft-klensin-smtp-521code-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC5321, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1846, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5321, updated by this document, for RFC5378 checks: 2005-07-11) -- 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 (September 7, 2014) is 2812 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft 4 Updates: 1846, 5321 (if approved) September 7, 2014 5 Intended status: Standards Track 6 Expires: March 11, 2015 8 SMTP 521 and 556 Reply Codes 9 draft-klensin-smtp-521code-02.txt 11 Abstract 13 This memo defines two Simple Mail Transfer Protocol (SMTP) reply 14 code, 521 and 556. The 521 code was originally described in an 15 Experimental RFC in 1995 and is in wide use, but has not previously 16 been formally incorporated into SMTP. The 556 code was created for 17 [[RFC nullMX]]. These codes are used to indicate that an Internet 18 host does not accept incoming mail at all (not just under particular 19 circumstances). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 11, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Discussion List . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 3 60 4. The 556 Reply Code . . . . . . . . . . . . . . . . . . . . . 4 61 5. Small details to avoid loose ends . . . . . . . . . . . . . . 4 62 5.1. Specific changes to RFC 5321 . . . . . . . . . . . . . . 4 63 5.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 70 A.1. Changss from -00 to -01 . . . . . . . . . . . . . . . . . 6 71 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The SMTP specification [2] (referred to, along with its various 77 updates, as "SMTP" below) contains a list and discussion of reply 78 codes. This document updates that list with a new code, 521, for use 79 in response to an initial connection. In that context, it 80 specifically denotes a system that does not receive email or 81 otherwise handle SMTP mail or inquiry transactions. That code 82 differs from the use of reply code 554, recommended by RFC 5321, 83 because the latter code can be used in a larger variety of 84 situations, including mail that is not accepted for, or from, 85 particular sources, destinations, or addresses. It also introduces a 86 second reply code, 556, for use when an SMTP client encounters a 87 domain in a forward-pointing address that it can determine (e.g., 88 from the DNS "null MX" convention [4]) does not support receipt of 89 email and has to report that condition to a host that delivered the 90 message to it for further processing. 92 This specification updates RFC 5321 to add the new codes. The 521 93 code was first formally proposed in the Experimental RFC 1846 [3]; 94 this document updates that specification to standardize the code and 95 provide more specific treatment of it. 97 1.1. Terminology 99 The reader of this document is expected to have reasonable 100 familiarity with the SMTP specification in RFC 5321, particularly its 101 discussion of reply codes and their use and theory. [[CREF1: For 102 those who do not, it is safe to assume that it adds the two codes and 103 that everything else is just details.]] 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [1]. 109 1.2. Discussion List 111 [[CREF2: RFC Editor: please remove this subsection.]] 113 Discussion of the SMTP aspects and relationships of this 114 specification should occur on the ietf-smtp list, 115 https://www.ietf.org/mailman/listinfo/ietf-smtp. Discussions of 116 "null MX" and the relationship of this specification to it occur on 117 the apps-discuss list, https://www.ietf.org/mailman/listinfo/apps- 118 discuss. 120 2. Background 122 Many Internet hosts are not in a position -- whether technically, 123 operationally, or administratively-- to offer email service. If an 124 SMTP client (sender) attempts to open a mail connection to a system 125 that does not have an SMTP server, the connection attempt will time 126 out. SMTP requires that timeouts result in the client queuing the 127 message and retrying it for an extended period. That behavior will 128 result in wasted resources and long delays in getting an error 129 message back to its originator. 131 One alternative is to run a dummy SMTP server on hosts that do not 132 receive mail under any circumstances, having that dummy server return 133 a fatal error reply code in response to any connection-opening 134 attempt. Another is to determine, from a separate source such as a 135 DNS record, that the host does not receive mail. This document 136 specifies reply codes to be used for those purposes. 138 3. The 521 Reply Code 140 This specification adds the 521 reply code to the repertoire 141 specified in SMTP, reserving it for use at connection-opening time to 142 indicate that the host does not accept email under any circumstances. 143 It SHOULD be used for dummy SMTP servers whose sole purpose is to 144 notify systems that attempt to open mail connections that the host 145 never accepts mail. It MAY be used in other situations where the 146 intent is for the host to indicate that it never accepts email. 148 The 521 reply code SHOULD NOT be used for situations in which the 149 server rejects mail from particular hosts or addresses or in which 150 mail intended to be transferred to a particular destination host is 151 not accepted. As discussed in SMTP, reply code 554 is more 152 appropriate for most of those conditions. One additional case is 153 covered in the next section. 155 The preferred message to accompany a 521 code is "Host does not 156 accept mail". 158 Once the 521 reply code is returned instead of the usual 220, the 159 SMTP session proceeds normally (i.e., the client will send QUIT and 160 close the connection). If the SMTP client attempts to send 161 additional commands other than QUIT, the Server MAY either continue 162 sending 521 reply codes or simply close the connection. If the 163 purpose of running a dummy SMTP server that returns a 521 code is to 164 conserve resources, the latter will usually be preferable. 166 4. The 556 Reply Code 168 This specification adds the 556 reply code to the repertoire 169 specified in SMTP. The code is intended for situations in which an 170 SMTP client can determine that a particular server or domain that is 171 referred to in a forward-pointing address does not accept mail 172 connections without attempting to open a connection to a mail server 173 associated with that domain. Interpretation of a special DNS record, 174 found when a lookup is performed in conjunction with a RCPT command 175 [4], is one such method (and the only standardized one at the time 176 this specification was written). 178 When an SMTP server returns a 556 response code after receiving a 179 command, such as RCPT, containing a forward-pointing address because 180 it has information, as discussed above, that mail is not accepted, 181 the SMTP client is, consistent with the SMTP specification, expected 182 to handle the response like any other permanent negative completion 183 reply to the command. 185 5. Small details to avoid loose ends 187 5.1. Specific changes to RFC 5321 189 This document adds the 521 code, with message "Host does not accept 190 mail", and the 556 code, with message "Domain does not accept mail", 191 to the function group and numerical lists (Sections 4.2.2 and 4.2.3 192 respectively) of RFC 5321. It also adds the 521 code to the 193 "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply 194 Sequences"), preceding the 554 code, and the 556 code to the "RCPT" 195 portion of that same section. 197 5.2. The RFC 1846 Experiment 199 By formalizing Response Code 521, this specification ends the 200 experiment proposed in RFC 1846. That earlier document also 201 discusses general strategies for hosts that do not accept mail 202 directly. The latter discussion is out of scope for the present 203 document. 205 6. Security Considerations 207 Not running any SMTP server, or running an SMTP server which simply 208 emits fixed strings in response to incoming connections, should 209 provide significantly fewer opportunities for security problems than 210 running a complete SMTP implementation. See the Security 211 Considerations section of [[RFC nullMX]] [4] for a discussion of 212 security issues with that approach. Use of the specific code 213 provided here provides more information to the client than a generic 214 or arbitrarily-chosen 5yz code but should have no other effect on 215 security. 217 7. Acknowledgments 219 Alain Durand and Francis Dupont proposed the 521 code in RFC 1846 220 [3]. They also participated in an extended conversation and provided 221 many useful comments that led to this document. The document also 222 contains, with their permission, some text copied from that early 223 specification. 225 Discussion of the "null MX" approach and proposal [4] inspired the 226 creation of this specification and the inclusion of the 556 code in 227 it. Specific comments and suggestions from John Levine (co-author of 228 that document) and Ned Freed were also helpful. 230 Martin Duerst and Tom Petch identified significant issues in the 231 initial draft of the current form of the document. 233 8. References 235 8.1. Normative References 237 [1] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 241 October 2008. 243 8.2. Informative References 245 [3] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, 246 September 1995. 248 [4] Levine, J. and M. Delany, "A "Null MX" No Service Resource 249 Record for Domains that Accept No Mail", August 2014, 250 . 253 Appendix A. Change Log 255 RFC Editor: Please remove this appendix before publication.. 257 This Internet Draft is the successor to draft-klensin-rfc1846bis-00. 258 That document was an attempt to completely update and replace RFC 259 1846. That effort led to the conclusion that it would be better to 260 focus narrowly on the 521 code, leaving a more general treatment of 261 hosts that do not receive mail to a separate replacement for RFC 1846 262 and/or an update to RFC 5321. 264 A.1. Changss from -00 to -01 266 Revised abstract and cleaned up "error code" terminology. 268 A.2. Changes from -01 to -02 270 Added provision for code 556 and associated discussion. 272 Several editorial corrections and cleanups. 274 Author's Address 276 John C Klensin 277 1770 Massachusetts Ave, Ste 322 278 Cambridge, MA 02140 279 USA 281 Phone: +1 617 245 1457 282 Email: john-ietf@jck.com