Network Working Group
Internet Engineering Task Force (IETF)                        J. Klensin
Request for Comments: 7504                                     June 2015
Updates: 1846, 5321 (if approved)
Intended status:
Category: Standards Track
Expires: November 2, 2015
ISSN: 2070-1721

                      SMTP 521 and 556 Reply Codes
                   draft-klensin-smtp-521code-07.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. to
   support the new tests and actions specified in RFC 7505.  These codes
   are used to indicate that an Internet host does not accept incoming
   mail at all.  This specification is not applicable when the host
   sometimes accepts mail but may reject particular messages, or even
   all (not just messages, under particular
   circumstances). specific 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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 November 2, 2015.
   http://www.rfc-editor.org/info/rfc7504.

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
   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   3
     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 Details to avoid loose ends Avoid Loose Ends . . . . . . . . . . . . . .   5
     5.1.  Specific changes 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.
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   7
     A.1.  Changes from -00 to -01 . .
   Acknowledgments . . . . . . . . . . . . . . .   7
     A.2.  Changes from -01 to -02 . . . . . . . . . .   6
   Author's Address  . . . . . . .   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
     A.6.  Changes from -05 to -06 . . . . . . . . . . . . . . . . .   8
     A.7.  Changes from -06 to -07 . . . . . . . . . . . . . . . . .   8
   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

1.  Introduction

   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 mail 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., from the DNS "null MX" convention [5])
   does not support receipt of
   email mail 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-- administratively -- to offer email mail 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 circumstances and have 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.

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 mail 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. mail.  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" (or a variant such as "Host", "Domain",
   or a related term) 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.  When an intermediate SMTP system (typically a
   relay) that would normally attempt to open a mail connection to a
   host referred to in a forward-pointing address can determine that the
   host does not accept mail connections, and do so without attempting
   to open a connection to that target host, it is appropriate for it to
   return a reply with a 556 code to the system that sent it the message
   for outbound transmission.  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.

5.  Small details Details to avoid loose ends Avoid Loose Ends

5.1.  Specific changes 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 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 has
   updated the SMTP "Enumerated Status Codes" subregistry of the "Simple Mail
   Transfer Protocol (SMTP) Enhanced Status Code Registry Codes Registry" [3] to
   include these codes, specifically:

   o  Add  Added 521 to the list of codes associated with the enhanced code
      entry for X.3.2, referencing which now references this document.

   o  Add  Added this document to the references associated with the enhanced
      code entry for X.1.10 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 that 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 RFC 7505 [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 arbitrarily
   chosen 5yz code but should have no other effect on security.

8.  Acknowledgments

   Alain Durand and Francis Dupont proposed the 521 code  References

8.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 1846
   [4].  They also participated in an extended conversation and provided 2119, DOI 10.17487/RFC2119, March 1997,
        <http://www.rfc-editor.org/info/rfc2119>.

   [2]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
        DOI 10.17487/RFC5321, October 2008,
        <http://www.rfc-editor.org/info/rfc5321>.

   [3]  IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced Status
        Codes Registry",
        <http://www.iana.org/assignments/smtp-enhanced-status-codes>.

8.2.  Informative References

   [4]  Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846,
        DOI 10.17487/RFC1846, September 1995,
        <http://www.rfc-editor.org/info/rfc1846>.

   [5]  Levine, J. and M. Delany, "A "Null MX" No Service Resource
        Record for Domains that Accept No Mail", RFC 7505,
        DOI 10.17487/RFC7505, June 2015,
        <http://www.rfc-editor.org/info/rfc7505>.

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.

   Dilyan Palauzov did a careful reading and identified an editorial
   error.

   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", March 1997.

   [2]        Klensin, J., "Simple Mail Transfer Protocol", October
              2008.

   [3]        IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced
              Status Codes Registry: Enumerated Status Codes",
              <http://www.iana.org/assignments/smtp-enhanced-status-
              codes/smtp-enhanced-status-codes.xhtml#smtp-enhanced-
              status-codes-3>.

9.2.  Informative References

   [4]        Durand, A. and F. Dupont, "SMTP 521 Reply Code", September
              1995.

   [5]        Levine, J. and M. Delany, "A "Null MX" No Service Resource
              Record for Domains that Accept No Mail", September 2014,
              <https://datatracker.ietf.org/doc/draft-ietf-appsawg-
              nullmx/>.

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

   o  Added provision for code 556 and associated discussion.

   o  Several editorial corrections and cleanups.

A.3.  Changes from -02 to -03

   o  Updated reference to nullMX to -10

   o  Changed text describing preferred/acceptable message text.

   o  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

   o  Several small editorial corrections, most suggested by Rolf
      Sonneveld.

   o  Changed sample text for code 521 to use "server" rather than
      "host" for consistence with RFC 5321.

   o  Rationalized use of "responses" and "reply code" terminology.

A.6.  Changes from -05 to -06

   o  Part of Section 4 rewritten to make the client and server
      relationships more clear to people who are not SMTP (and RFC 5321)
      experts.

   o  Corrected an error in IANA considerations to change the extended
      reply code for code 556 to X.1.10 from X.10.1.

   o  Minor editorial issues caught during Last Call corrected.

A.7.  Changes from -06 to -07

   o  Added parenthetical note in Section 3 to "acceptable text" for the
      521 reply.

Author's Address

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140
   USA
   United States

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com