SMTP 521 Reply Code
draft-klensin-smtp-521code-01

Network Working Group                                         J. Klensin
Internet-Draft
Updates: 1846, 5321 (if approved)                        August 22, 2014
Intended status: Standards Track
Expires: February 23, 2015

                          SMTP 521 Reply Code
                   draft-klensin-smtp-521code-01.txt

Abstract

   This memo defines a Simple Mail Transfer Protocol (SMTP) reply code,
   521.  THe 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 code may be used to indicate that an
   Internet host does not accept incoming mail.

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 February 23, 2015.

Copyright Notice

   Copyright (c) 2014 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

Klensin                 Expires February 23, 2015               [Page 1]
Internet-Draft             SMTP 521 Reply Code               August 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The 521 Reply Code  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Small details to avoid loose ends . . . . . . . . . . . . . .   3
     4.1.  Specific changes to RFC 5321  . . . . . . . . . . . . . .   3
     4.2.  The RFC 1846 Experiment . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   5
     A.1.  Changss from -00 to -01 . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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 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.

   This specification updates RFC 5321 to add the new 521 code.  That
   code was first formally proposed in the Experimental RFC 1846 [3];
   this document updates that specification to standardize the code and
   provide more specific treatment of it.

   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].

Klensin                 Expires February 23, 2015               [Page 2]
Internet-Draft             SMTP 521 Reply Code               August 2014

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.

   An 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.  This document specifies a reply code to be used for that
   purpose.

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 those conditions.

   The preferred message to accompany a 521 code is "Host does not
   accept mail".

   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.  Small details to avoid loose ends

4.1.  Specific changes to RFC 5321

   This document adds the 521 code, with message "Host 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

Klensin                 Expires February 23, 2015               [Page 3]
Internet-Draft             SMTP 521 Reply Code               August 2014

   "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply
   Sequences"), preceding the 554 code.

4.2.  The RFC 1846 Experiment

   By formalizing Response 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.

5.  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.

6.  Acknowledgments

   Alain Durand and Francis Dupont proposed the 521 code in RFC 1846
   [3].  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 [4] inspired the
   creation of this specification.

   Martin Duerst and Tom Petch identified significant issues in the
   initial draft of the current form of the document.

7.  References

7.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.

7.2.  Informative References

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

Klensin                 Expires February 23, 2015               [Page 4]
Internet-Draft             SMTP 521 Reply Code               August 2014

   [4]        Levine, J. and M. Delany, "A "Null MX" No Service Resource
              Record for Domains that Accept No Mail", August 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.  Changss from -00 to -01

   Revised abstract and cleaned up "error code" terminology.

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 February 23, 2015               [Page 5]