< draft-klensin-smtp-521code-01.txt   draft-klensin-smtp-521code-02.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft Internet-Draft
Updates: 1846, 5321 (if approved) August 22, 2014 Updates: 1846, 5321 (if approved) September 7, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: February 23, 2015 Expires: March 11, 2015
SMTP 521 Reply Code SMTP 521 and 556 Reply Codes
draft-klensin-smtp-521code-01.txt draft-klensin-smtp-521code-02.txt
Abstract Abstract
This memo defines a Simple Mail Transfer Protocol (SMTP) reply code, This memo defines two Simple Mail Transfer Protocol (SMTP) reply
521. THe code was originally described in an Experimental RFC in code, 521 and 556. The 521 code was originally described in an
1995 and is in wide use, but has not previously been formally Experimental RFC in 1995 and is in wide use, but has not previously
incorporated into SMTP. The code may be used to indicate that an been formally incorporated into SMTP. The 556 code was created for
Internet host does not accept incoming mail. [[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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 23, 2015. This Internet-Draft will expire on March 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Discussion List . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 3 3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 3
4. Small details to avoid loose ends . . . . . . . . . . . . . . 3 4. The 556 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
4.1. Specific changes to RFC 5321 . . . . . . . . . . . . . . 3 5. Small details to avoid loose ends . . . . . . . . . . . . . . 4
4.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 4 5.1. Specific changes to RFC 5321 . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6
A.1. Changss from -00 to -01 . . . . . . . . . . . . . . . . . 5 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 A.1. Changss from -00 to -01 . . . . . . . . . . . . . . . . . 6
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The SMTP specification [2] (referred to, along with its various The SMTP specification [2] (referred to, along with its various
updates, as "SMTP" below) contains a list and discussion of reply updates, as "SMTP" below) contains a list and discussion of reply
codes. This document updates that list with a new code, 521, for use codes. This document updates that list with a new code, 521, for use
in response to an initial connection. In that context, it in response to an initial connection. In that context, it
specifically denotes a system that does not receive email or specifically denotes a system that does not receive email or
otherwise handle SMTP mail or inquiry transactions. That code otherwise handle SMTP mail or inquiry transactions. That code
differs from the use of reply code 554, recommended by RFC 5321, differs from the use of reply code 554, recommended by RFC 5321,
because the latter code can be used in a larger variety of because the latter code can be used in a larger variety of
situations, including mail that is not accepted for, or from, situations, including mail that is not accepted for, or from,
particular sources, destinations, or addresses. 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 [4]) 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 521 code. That This specification updates RFC 5321 to add the new codes. The 521
code was first formally proposed in the Experimental RFC 1846 [3]; code was first formally proposed in the Experimental RFC 1846 [3];
this document updates that specification to standardize the code and this document updates that specification to standardize the code and
provide more specific treatment of it. provide more specific treatment of it.
1.1. Terminology
The reader of this document is expected to have reasonable The reader of this document is expected to have reasonable
familiarity with the SMTP specification in RFC 5321, particularly its familiarity with the SMTP specification in RFC 5321, particularly its
discussion of reply codes and their use and theory. discussion of reply codes and their use and theory. [[CREF1: For
those who do not, it is safe to assume that it adds the two codes and
that everything else is just details.]]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
1.2. Discussion List
[[CREF2: 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 2. Background
Many Internet hosts are not in a position -- whether technically, Many Internet hosts are not in a position -- whether technically,
operationally, or administratively-- to offer email service. If an operationally, or administratively-- to offer email service. If an
SMTP client (sender) attempts to open a mail connection to a system SMTP client (sender) attempts to open a mail connection to a system
that does not have an SMTP server, the connection attempt will time that does not have an SMTP server, the connection attempt will time
out. SMTP requires that timeouts result in the client queuing the out. SMTP requires that timeouts result in the client queuing the
message and retrying it for an extended period. That behavior will message and retrying it for an extended period. That behavior will
result in wasted resources and long delays in getting an error result in wasted resources and long delays in getting an error
message back to its originator. message back to its originator.
An alternative is to run a dummy SMTP server on hosts that do not One alternative is to run a dummy SMTP server on hosts that do not
receive mail under any circumstances, having that dummy server return receive mail under any circumstances, having that dummy server return
a fatal error reply code in response to any connection-opening a fatal error reply code in response to any connection-opening
attempt. This document specifies a reply code to be used for that attempt. Another is to determine, from a separate source such as a
purpose. 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 3. The 521 Reply Code
This specification adds the 521 reply code to the repertoire This specification adds the 521 reply code to the repertoire
specified in SMTP, reserving it for use at connection-opening time to specified in SMTP, reserving it for use at connection-opening time to
indicate that the host does not accept email under any circumstances. indicate that the host does not accept email under any circumstances.
It SHOULD be used for dummy SMTP servers whose sole purpose is to It SHOULD be used for dummy SMTP servers whose sole purpose is to
notify systems that attempt to open mail connections that the host notify systems that attempt to open mail connections that the host
never accepts mail. It MAY be used in other situations where the never accepts mail. It MAY be used in other situations where the
intent is to indicate that the host never accepts email. It SHOULD intent is for the host to indicate that it never accepts email.
NOT be used for situations in which the server rejects mail from
particular hosts or addresses or in which mail for a particular The 521 reply code SHOULD NOT be used for situations in which the
destination host is not accepted; as discussed in SMTP, reply code server rejects mail from particular hosts or addresses or in which
554 is more appropriate for those conditions. mail intended to be transferred to a particular destination host is
not accepted. As discussed in SMTP, reply code 554 is more
appropriate for most of those conditions. One additional case is
covered in the next section.
The preferred message to accompany a 521 code is "Host does not The preferred message to accompany a 521 code is "Host does not
accept mail". accept mail".
Once the 521 reply code is returned instead of the usual 220, the Once the 521 reply code is returned instead of the usual 220, the
SMTP session proceeds normally. If the SMTP client attempts to send SMTP session proceeds normally (i.e., the client will send QUIT and
close the connection). If the SMTP client attempts to send
additional commands other than QUIT, the Server MAY either continue additional commands other than QUIT, the Server MAY either continue
sending 521 reply codes or simply close the connection. If the 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 purpose of running a dummy SMTP server that returns a 521 code is to
conserve resources, the latter will usually be preferable. conserve resources, the latter will usually be preferable.
4. Small details to avoid loose ends 4. The 556 Reply Code
4.1. Specific changes to RFC 5321 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 a mail server
associated with that domain. Interpretation of a special DNS record,
found when a lookup is performed in conjunction with a RCPT command
[4], is one such method (and the only standardized one at the time
this specification was written).
When an SMTP server returns a 556 response code after receiving a
command, such as RCPT, containing a forward-pointing address because
it has information, as discussed above, that mail is not accepted,
the SMTP client is, consistent with the SMTP specification, expected
to handle the response like any other permanent negative completion
reply to the command.
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 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 mail", and the 556 code, with message "Domain does not accept mail",
4.2.3 respectively) of RFC 5321. It also adds the 521 code to the 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 "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply
Sequences"), preceding the 554 code. Sequences"), preceding the 554 code, and the 556 code to the "RCPT"
portion of that same section.
4.2. The RFC 1846 Experiment 5.2. The RFC 1846 Experiment
By formalizing Response Code 521, this specification ends the By formalizing Response Code 521, this specification ends the
experiment proposed in RFC 1846. That document also discusses experiment proposed in RFC 1846. That earlier document also
general strategies for hosts that do not accept mail directly. That discusses general strategies for hosts that do not accept mail
discussion is out of scope for the present document. directly. The latter discussion is out of scope for the present
document.
5. Security Considerations 6. Security Considerations
Not running any SMTP server, or running an SMTP server which simply Not running any SMTP server, or running an SMTP server which simply
emits fixed strings in response to incoming connections, should emits fixed strings in response to incoming connections, should
provide significantly fewer opportunities for security problems than provide significantly fewer opportunities for security problems than
running a complete SMTP implementation. running a complete SMTP implementation. See the Security
Considerations section of [[RFC nullMX]] [4] for a discussion of
security issues with that approach. Use of the specific code
provided here provides more information to the client than a generic
or arbitrarily-chosen 5yz code but should have no other effect on
security.
6. Acknowledgments 7. Acknowledgments
Alain Durand and Francis Dupont proposed the 521 code in RFC 1846 Alain Durand and Francis Dupont proposed the 521 code in RFC 1846
[3]. They also participated in an extended conversation and provided [3]. They also participated in an extended conversation and provided
many useful comments that led to this document. The document also many useful comments that led to this document. The document also
contains, with their permission, some text copied from that early contains, with their permission, some text copied from that early
specification. specification.
Discussion of the "null MX" approach and proposal [4] inspired the Discussion of the "null MX" approach and proposal [4] inspired the
creation of this specification. creation of this specification and the inclusion of the 556 code in
it. Specific comments and suggestions from John Levine (co-author of
that document) and Ned Freed were also helpful.
Martin Duerst and Tom Petch identified significant issues in the Martin Duerst and Tom Petch identified significant issues in the
initial draft of the current form of the document. initial draft of the current form of the document.
7. References 8. References
7.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
7.2. Informative References 8.2. Informative References
[3] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, [3] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846,
September 1995. September 1995.
[4] Levine, J. and M. Delany, "A "Null MX" No Service Resource [4] Levine, J. and M. Delany, "A "Null MX" No Service Resource
Record for Domains that Accept No Mail", August 2014, Record for Domains that Accept No Mail", August 2014,
<https://datatracker.ietf.org/doc/draft-ietf-appsawg- <https://datatracker.ietf.org/doc/draft-ietf-appsawg-
nullmx/>. nullmx/>.
Appendix A. Change Log Appendix A. Change Log
skipping to change at page 5, line 25 skipping to change at page 6, line 33
That document was an attempt to completely update and replace RFC That document was an attempt to completely update and replace RFC
1846. That effort led to the conclusion that it would be better to 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 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 hosts that do not receive mail to a separate replacement for RFC 1846
and/or an update to RFC 5321. and/or an update to RFC 5321.
A.1. Changss from -00 to -01 A.1. Changss from -00 to -01
Revised abstract and cleaned up "error code" terminology. 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.
Author's Address Author's Address
John C Klensin John C Klensin
1770 Massachusetts Ave, Ste 322 1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 245 1457 Phone: +1 617 245 1457
Email: john-ietf@jck.com Email: john-ietf@jck.com
 End of changes. 30 change blocks. 
49 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/