idnits 2.17.1 draft-klensin-rfc1846bis-00.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.) == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC1846, but the abstract doesn't seem to directly say this. It does mention RFC1846 though, so this could be OK. -- The draft header indicates that this document updates RFC5321, 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2014) is 3540 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) -- Looks like a reference, but probably isn't: 'RFC5321' on line 86 -- Looks like a reference, but probably isn't: 'RFC1846' on line 96 -- Looks like a reference, but probably isn't: 'RFC2119' on line 116 == Unused Reference: '1' is defined on line 272, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 275, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1846 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.C. Klensin, Ed. 3 Internet-Draft August 11, 2014 4 Updates: 5321 (if approved) 5 Obsoletes: 1846 (if approved) 6 Intended status: Standards Track 7 Expires: February 10, 2015 9 SMTP 521 Reply Code 10 draft-klensin-rfc1846bis-00.txt 12 Abstract 14 This memo defines a new Simple Mail Transfer Protocol (SMTP) reply 15 code, 521, which one may use to indicate that an Internet host does 16 not accept incoming mail. It is a standards track replacement for 17 the earlier, experimental, RFC 1846 without any substantive changes. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 10, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Two complementary solutions . . . . . . . . . . . . . . . . . 3 67 4. The MX relays solution . . . . . . . . . . . . . . . . . . . . 3 68 5. The SMTP server solution . . . . . . . . . . . . . . . . . . . 4 69 5.1. 521 greeting . . . . . . . . . . . . . . . . . . . . . . . 4 70 5.2. SMTP dialog . . . . . . . . . . . . . . . . . . . . . . . 4 71 5.3. MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5.4. Postmaster . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. SMTP client behavior . . . . . . . . . . . . . . . . . . . . . 5 74 7. Context and other approaches . . . . . . . . . . . . . . . . . 5 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 10.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 6 81 Appendix A.1. Changes from RFC 1846 . . . . . . . . . . . . . . 6 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 1. Introduction 86 The SMTP specification [RFC5321] contains a list and discussion of 87 error codes. This document updates that list with a new code, 521, 88 for use primarily, ideally exclusively, in response to an initial 89 connection. In that context, it specifically denotes a system that 90 does not receive email or otherwise handle SMTP mail or inquiry 91 transactions. That code differs from the use of reply code 554, 92 recommended by RFC 5321, because that code can be used in a larger 93 variety of situations. 95 This document supersedes and is a standards track replacement for RFC 96 1846 [RFC1846]. Formally RFC 1846 was an experiment about the use of 97 the 521 code, one that has run for about 19 years. During that time, 98 reply code 521 has been supported in multiple implementations as an 99 alternative to other connect-time codes. This specification updates 100 RFC 5321 by adding the 521 code to the recommended code list in 101 preference to the use of other connection-time codes to indicate the 102 intentional absence of SMTP service on that host. Because RFC 5321 103 requires that clients take their primary actions on the basis of the 104 first digit of the reply code, the addition of this code can provide 105 additional information but its use, or the use of alternative 5yz 106 codes, cannot have significant negative operational effects with 107 conforming implementations of SMTP. 109 The reader of this document is expected to have reasonable 110 familiarity with the SMTP specification in RFC 5321, particularly the 111 discussions of reply codes and their use and theory. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Motivations 119 Hosts on the Internet have shifted from large, general-purpose hosts 120 to smaller, more specialized hosts. An increasing number of hosts 121 are dedicated to specific tasks, such as serving NTP or DNS. These 122 dedicated hosts frequently do not provide mail service. 124 Usually, these mailless hosts do not run an SMTP server. 125 Unfortunately, users will occasionally misaddress mail to these 126 hosts. Regular SMTP clients attempting to deliver this misaddressed 127 mail see the absence of an SMTP server on a host only through a 128 timeout in trying to make a connection and must treat that state as a 129 temporary error. They must queue the mail for later delivery in case 130 the problem was actually temporary of in case an SMTP server is 131 started at a later time. 133 This causes the mail to remain queued for days, until it is returned 134 with what is usually a confusing error message. 136 3. Two complementary solutions 138 Two complementary solutions MAY be implemented to deal with this 139 issue. The first one is to use MX relays to bounce misaddressed 140 mails. The second one is to implement a minimal SMTP server on the 141 mailless host to bounce all mails. 143 The choice between the two solutions is site dependent. 145 4. The MX relays solution 146 MX relays may be used to indicate SMTP clients that an Internet host 147 does not accept mail. 149 During the SMTP dialog, these MX relays MAY bounce any message 150 destined to this particular host with an SMTP 521 reply code. 152 SMTP dialog example: 154 ---> 220 relay.imag.fr ready 155 <--- HELO client.inria.fr 156 ---> 250 relay.imag.fr Hello client.inria.fr 157 <--- MAIL FROM: 158 ---> 250 ... Sender Ok 159 <--- RCPT TO: 160 ---> 521 nomail.imag.fr does not accept mail 161 <--- QUIT 162 ---> 221 relay.imag.fr closing connection 164 [[Note in draft: to be acceptable for the standards track at the time 165 of posting, the examples above and below will probably have to be 166 retooled to use "example.com" or equivalent]] 168 If an MX relay of precedence n for a mailless host bounces mails on 169 its behalf, then any other MX relay of precedence lower than n for 170 this mailless host SHOULD do the same. 172 5. The SMTP server solution 174 5.1. 521 greeting 176 A host may indicate that it does not accept mail by sending an 177 initial 521 "Host does not accept mail" reply to an incoming SMTP 178 connection. The official name of the server host or its IP address 179 MUST be sent as the first word following the reply code. 181 For example: 521 canon.inria.fr does not accept mail. 183 5.2. SMTP dialog 185 After issuing the initial 521 reply, the server host MUST do one of 186 the following two options: 188 a. Close the SMTP connection. 190 b. Read commands, issuing 521 replies to all commands except QUIT. 191 If the SMTP client does not issue the QUIT command after a 192 reasonable time, the SMTP server MUST time out and close the 193 connection. A suggested time-out value is 5 minutes. 195 DISCUSSION: 197 When an SMTP server closes the connection immediately after issuing 198 the initial 521 reply, some existing SMTP clients treat the condition 199 as a transient error and requeue the mail for later delivery. If the 200 SMTP server leaves the connection open, those clients immediately 201 SHOULD send the QUIT command and return the mail. 203 5.3. MX 205 A host which sends a 521 greeting message MUST NOT be listed as an MX 206 record for any domain except as specified above. 207 [[Note in draft: this seemed a tad contradictory to the text above 208 and the instructions below. --JcK]] 210 5.4. Postmaster 212 An SMTP server that sends a reply message using a 521 code in 213 response to an initial connection is not subject to the postmaster 214 requirement of Section 4.5.1 of RFC 5321. 216 DISCUSSION: 218 Postmaster exists so you can report mail errors. A host that doesn't 219 support mail doesn't need a Postmaster. 221 6. SMTP client behavior 223 If an SMTP client encounters a host in an MX record that issues a 521 224 greeting message, it MUST do one of the following, but the choice is 225 left to the implementation: 227 a. Attempt to deliver it to a different MX host for that domain. 229 b. Return the mail with an appropriate non-delivery report. 231 If an SMTP client encounters a 521 reply code in any other part of 232 the SMTP dialog, it MUST return the mail with an appropriate non- 233 delivery report. 235 7. Context and other approaches 237 This specification, and the 521 code, are intended to address 238 situations in which an SMTP connection is attempted to a host that 239 does not support SMTP. An alternate approach is to provide 240 information about SMTP non-support in the hope of discouraging such 241 connection attempts. One way to do that using the DNS is specified 242 as the "null MX" approach [nullMX]. Even when that approach is used, 243 it is desirable to support a server that will return this code if a 244 connection is attempted on the SMTP port because client recognition 245 of the special DNS records for null MX is not universal. 247 8. Security Considerations 248 Not running any SMTP server, or running an SMTP server which simply 249 emits fixed strings in response to incoming connection should provide 250 significantly fewer opportunities for security problems than running 251 a complete SMTP implementation. 253 9. Contributors 255 Alain Durand and Francis Dupont created RFC 1846, and, because this 256 document copied large amounts of text from it, most of the text here. 257 They have not been listed as co-authors only before they could not be 258 contacted before this specification was posted. 260 10. References 262 10.1. Normative References 264 [1] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 268 October 2008. 270 10.2. Informative References 272 [1] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, 273 September 1995. 275 [2] Levine, J. and M. Delany, "A "Null MX" No Service Resource 276 Record for Domains that Accept No Mail", August 2014, 277 . 280 Appendix A. Change Log 282 RFC Editor: Please remove this appendix before publication. 284 Appendix A.1. Changes from RFC 1846 286 o Updated boilerplate and editorial material for a standards track 287 document. As part of this, added new Section 1 and Section 7. 289 o Removed "experimental" material 291 o Updated references and improved ties to RFC 5321. 293 o Mentioned the "nullMX" relationship. 295 Author's Address 296 John C Klensin, editor 297 1770 Massachusetts Ave, Ste 322 298 Cambridge, MA 02140 299 USA 301 Phone: +1 617 245 1457 302 Email: john-ietf@jck.com