Network Working Group J. Klensin Internet-Draft March 5, 2015 Updates: 1846, 5321 (if approved) Intended status: Standards Track Expires: September 6, 2015 SMTP 521 and 556 Reply Codes draft-klensin-smtp-521code-05.txt Abstract This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created for RFC-nullMX. These codes are used to indicate that an Internet host does not accept incoming mail at all (not just under particular circumstances). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Klensin Expires September 6, 2015 [Page 1] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Discussion List . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 4 4. The 556 Reply Code . . . . . . . . . . . . . . . . . . . . . 4 5. Small details to avoid loose ends . . . . . . . . . . . . . . 5 5.1. Specific changes to RFC 5321 . . . . . . . . . . . . . . 5 5.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 7 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 7 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 7 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 7 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [[ RFC Editor: the string RFC-nullMX is produced by an XML entity named &RFCnullMX. When this document is edited for RFC publication, the value of that entity should be replaced by the appropriate RFC number and this note deleted. ]] The SMTP specification [2] (referred to, along with its various updates, as "SMTP" below) contains a list and discussion of reply codes. This document updates that list with a new code, 521, for use in response to an initial connection. In that context, it specifically denotes a system that does not receive email or otherwise handle SMTP mail or inquiry transactions. That code differs from the use of reply code 554, recommended by RFC 5321, because the latter code can be used in a larger variety of situations, including mail that is not accepted for, or from, particular sources, destinations, or addresses. It also introduces a second reply code, 556, for use when an SMTP client encounters a domain in a forward-pointing address that it can determine (e.g., Klensin Expires September 6, 2015 [Page 2] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 from the DNS "null MX" convention [5]) does not support receipt of email and has to report that condition to a host that delivered the message to it for further processing. This specification updates RFC 5321 to add the new codes. The 521 code was first formally proposed in the Experimental RFC 1846 [4]; this document updates that specification to standardize the code and provide more specific treatment of it. 1.1. Terminology The reader of this document is expected to have reasonable familiarity with the SMTP specification in RFC 5321, particularly its discussion of reply codes and their use and theory. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 1.2. Discussion List [[CREF1: RFC Editor: please remove this subsection.]] Discussion of the SMTP aspects and relationships of this specification should occur on the ietf-smtp list, https://www.ietf.org/mailman/listinfo/ietf-smtp. Discussions of "null MX" and the relationship of this specification to it occur on the apps-discuss list, https://www.ietf.org/mailman/listinfo/apps- discuss. 2. Background Many Internet hosts are not in a position -- whether technically, operationally, or administratively-- to offer email service. If an SMTP client (sender) attempts to open a mail connection to a system that does not have an SMTP server, the connection attempt will time out. SMTP requires that timeouts result in the client queuing the message and retrying it for an extended period. That behavior will result in wasted resources and long delays in getting an error message back to its originator. One alternative is to run a dummy SMTP server on hosts that do not receive mail under any circumstances, having that dummy server return a fatal error reply code in response to any connection-opening attempt. Another is to determine, from a separate source such as a DNS record, that the host does not receive mail. This document specifies reply codes to be used for those purposes. Klensin Expires September 6, 2015 [Page 3] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 3. The 521 Reply Code This specification adds the 521 reply code to the repertoire specified in SMTP, reserving it for use at connection-opening time to indicate that the host does not accept email under any circumstances. It SHOULD be used for dummy SMTP servers whose sole purpose is to notify systems that attempt to open mail connections that the host never accepts mail. It MAY be used in other situations where the intent is to indicate that the host never accepts email. It SHOULD NOT be used for situations in which the server rejects mail from particular hosts or addresses or in which mail for a particular destination host is not accepted;. As discussed in SMTP, reply code 554 is more appropriate for most of those conditions; an additional case, in which the determination that mail is not accepted is determined outside the mail system, is covered in the next section (Section 4). "Server does not accept mail" is an acceptable message to accompany a 521 code used for this purpose. Once the 521 reply code is returned instead of the usual 220, the SMTP session proceeds normally. If the SMTP client attempts to send additional commands other than QUIT, the server MAY either continue sending 521 reply codes or simply close the connection. If the purpose of running a dummy SMTP server that returns a 521 code is to conserve resources, the latter will usually be preferable. 4. The 556 Reply Code This specification adds the 556 reply code to the repertoire specified in SMTP. The code is intended for situations in which an SMTP client can determine that a particular server or domain that is referred to in a forward-pointing address does not accept mail connections without attempting to open a connection to that domain. Interpretation of a special DNS record, found when a lookup is performed in conjunction with a RCPT command [5], is one such method (and the only standardized one at the time this specification was written). When an SMTP server returns a 556 reply code after receiving a command (such as RCPT, which contains a forward-pointing address) because it has information (such as discussed above) that the mail will not be accepted, the SMTP client is expected to handle the response like any other permanent negative completion reply to the command. This is consistent with the SMTP specification. Klensin Expires September 6, 2015 [Page 4] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 5. Small details to avoid loose ends 5.1. Specific changes to RFC 5321 This document adds the 521 code, with message "Host does not accept mail", and the 556 code, with message "Domain does not accept mail", to the function group and numerical lists (Sections 4.2.2 and 4.2.3 respectively) of RFC 5321. It also adds the 521 code to the "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply Sequences"), preceding the 554 code, and the 556 code to the "RCPT" portion of that same section. 5.2. The RFC 1846 Experiment By formalizing reply code 521, this specification ends the experiment proposed in RFC 1846. That document also discusses general strategies for hosts that do not accept mail directly. That discussion is out of scope for the present document. 6. IANA Considerations This document updates RFC 5321 to add descriptions and text for two reply codes, but there is no registry for those codes. IANA should update the SMTP Enhanced Status Code Registry [3] to include these codes, specifically: o Add 521 to the list of codes associated with the enhanced code entry for X.3.2, referencing this document. o Add this document to the references associated with the enhanced code entry for X.10.1 and reply code 556. Note that, if a use for 556 arises that is not associated with null MX [5], it may be necessary to add an additional enhanced code, but such action is outside the scope of this document. 7. Security Considerations Not running any SMTP server, or running an SMTP server which simply emits fixed strings in response to incoming connections, should provide significantly fewer opportunities for security problems than running a complete SMTP implementation. See the Security Considerations section of RFC-nullMX [5] for a discussion of security issues with that approach. Use of the specific codes provided here provides more information to the client than a generic or arbitrarily-chosen 5yz code but should have no other effect on security. Klensin Expires September 6, 2015 [Page 5] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 8. Acknowledgments Alain Durand and Francis Dupont proposed the 521 code in RFC 1846 [4]. They also participated in an extended conversation and provided many useful comments that led to this document. The document also contains, with their permission, some text copied from that early specification. Discussion of the "null MX" approach and proposal [5] inspired the creation of this specification. Specific comments and suggestions from John Levine (co-author of that document) were also helpful. Martin Duerst and Tom Petch identified significant issues in the initial draft of the current form of the document. Ned Freed, Tony Hansen, and Rolf Sonneveld suggested textual improvements that were incorporated. Tony Hansen also acted as document shepherd and made several contributions in conjunction with that role. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [3] IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry: Enumerated Status Codes", . 9.2. Informative References [4] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995. [5] Levine, J. and M. Delany, "A "Null MX" No Service Resource Record for Domains that Accept No Mail", September 2014, . Klensin Expires September 6, 2015 [Page 6] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 Appendix A. Change Log RFC Editor: Please remove this appendix before publication.. This Internet Draft is the successor to draft-klensin-rfc1846bis-00. That document was an attempt to completely update and replace RFC 1846. That effort led to the conclusion that it would be better to focus narrowly on the 521 code, leaving a more general treatment of hosts that do not receive mail to a separate replacement for RFC 1846 and/or an update to RFC 5321. A.1. Changes from -00 to -01 Revised abstract and cleaned up "error code" terminology. A.2. Changes from -01 to -02 Added provision for code 556 and associated discussion. Several editorial corrections and cleanups. A.3. Changes from -02 to -03 Updated reference to nullMX to -10 Changed text describing preferred/acceptable message text. Additional editorial improvements. A.4. Changes from -03 to -04 Corrected errors in previous Change Log sections. Added an IANA Considerations section and provision for the SMTP Enhanced Status Code Registry. A.5. Changes from -04 to -05 Several small editorial corrections, most suggested by Rolf Sonneveld. Changed sample text for code 521 to use "server" rather than "host" for consistence with RFC 5321. Rationalized use of "responses" and "reply code" terminology. Klensin Expires September 6, 2015 [Page 7] Internet-Draft SMTP 521 and 556 Reply Codes March 2015 Author's Address John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires September 6, 2015 [Page 8]