Internet DRAFT - draft-klensin-rfc1846bis
draft-klensin-rfc1846bis
Network Working Group J.C. Klensin, Ed.
Internet-Draft August 11, 2014
Updates: 5321 (if approved)
Obsoletes: 1846 (if approved)
Intended status: Standards Track
Expires: February 10, 2015
SMTP 521 Reply Code
draft-klensin-rfc1846bis-00.txt
Abstract
This memo defines a new Simple Mail Transfer Protocol (SMTP) reply
code, 521, which one may use to indicate that an Internet host does
not accept incoming mail. It is a standards track replacement for
the earlier, experimental, RFC 1846 without any substantive changes.
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 10, 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 the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Klensin Expires February 10, 2015 [Page 1]
Internet-Draft SMTP 521 Reply Code August 2014
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Two complementary solutions . . . . . . . . . . . . . . . . . 3
4. The MX relays solution . . . . . . . . . . . . . . . . . . . . 3
5. The SMTP server solution . . . . . . . . . . . . . . . . . . . 4
5.1. 521 greeting . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. SMTP dialog . . . . . . . . . . . . . . . . . . . . . . . 4
5.3. MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.4. Postmaster . . . . . . . . . . . . . . . . . . . . . . . . 5
6. SMTP client behavior . . . . . . . . . . . . . . . . . . . . . 5
7. Context and other approaches . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A.1. Changes from RFC 1846 . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The SMTP specification [RFC5321] contains a list and discussion of
error codes. This document updates that list with a new code, 521,
for use primarily, ideally exclusively, 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 that code can be used in a larger
variety of situations.
Klensin Expires February 10, 2015 [Page 2]
Internet-Draft SMTP 521 Reply Code August 2014
This document supersedes and is a standards track replacement for RFC
1846 [RFC1846]. Formally RFC 1846 was an experiment about the use of
the 521 code, one that has run for about 19 years. During that time,
reply code 521 has been supported in multiple implementations as an
alternative to other connect-time codes. This specification updates
RFC 5321 by adding the 521 code to the recommended code list in
preference to the use of other connection-time codes to indicate the
intentional absence of SMTP service on that host. Because RFC 5321
requires that clients take their primary actions on the basis of the
first digit of the reply code, the addition of this code can provide
additional information but its use, or the use of alternative 5yz
codes, cannot have significant negative operational effects with
conforming implementations of SMTP.
The reader of this document is expected to have reasonable
familiarity with the SMTP specification in RFC 5321, particularly the
discussions 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 [RFC2119].
2. Motivations
Hosts on the Internet have shifted from large, general-purpose hosts
to smaller, more specialized hosts. An increasing number of hosts
are dedicated to specific tasks, such as serving NTP or DNS. These
dedicated hosts frequently do not provide mail service.
Usually, these mailless hosts do not run an SMTP server.
Unfortunately, users will occasionally misaddress mail to these
hosts. Regular SMTP clients attempting to deliver this misaddressed
mail see the absence of an SMTP server on a host only through a
timeout in trying to make a connection and must treat that state as a
temporary error. They must queue the mail for later delivery in case
the problem was actually temporary of in case an SMTP server is
started at a later time.
This causes the mail to remain queued for days, until it is returned
with what is usually a confusing error message.
3. Two complementary solutions
Two complementary solutions MAY be implemented to deal with this
issue. The first one is to use MX relays to bounce misaddressed
mails. The second one is to implement a minimal SMTP server on the
mailless host to bounce all mails.
The choice between the two solutions is site dependent.
4. The MX relays solution
Klensin Expires February 10, 2015 [Page 3]
Internet-Draft SMTP 521 Reply Code August 2014
MX relays may be used to indicate SMTP clients that an Internet host
does not accept mail.
During the SMTP dialog, these MX relays MAY bounce any message
destined to this particular host with an SMTP 521 reply code.
SMTP dialog example:
---> 220 relay.imag.fr ready
<--- HELO client.inria.fr
---> 250 relay.imag.fr Hello client.inria.fr
<--- MAIL FROM: <user1@client.inria.fr>
---> 250 <user1@client.inria.fr>... Sender Ok
<--- RCPT TO: <user2@nomail.imag.fr>
---> 521 nomail.imag.fr does not accept mail
<--- QUIT
---> 221 relay.imag.fr closing connection
[[Note in draft: to be acceptable for the standards track at the time
of posting, the examples above and below will probably have to be
retooled to use "example.com" or equivalent]]
If an MX relay of precedence n for a mailless host bounces mails on
its behalf, then any other MX relay of precedence lower than n for
this mailless host SHOULD do the same.
5. The SMTP server solution
5.1. 521 greeting
A host may indicate that it does not accept mail by sending an
initial 521 "Host does not accept mail" reply to an incoming SMTP
connection. The official name of the server host or its IP address
MUST be sent as the first word following the reply code.
For example: 521 canon.inria.fr does not accept mail.
5.2. SMTP dialog
After issuing the initial 521 reply, the server host MUST do one of
the following two options:
a. Close the SMTP connection.
b. Read commands, issuing 521 replies to all commands except QUIT.
If the SMTP client does not issue the QUIT command after a
reasonable time, the SMTP server MUST time out and close the
connection. A suggested time-out value is 5 minutes.
DISCUSSION:
Klensin Expires February 10, 2015 [Page 4]
Internet-Draft SMTP 521 Reply Code August 2014
When an SMTP server closes the connection immediately after issuing
the initial 521 reply, some existing SMTP clients treat the condition
as a transient error and requeue the mail for later delivery. If the
SMTP server leaves the connection open, those clients immediately
SHOULD send the QUIT command and return the mail.
5.3. MX
A host which sends a 521 greeting message MUST NOT be listed as an MX
record for any domain except as specified above.
[[Note in draft: this seemed a tad contradictory to the text above
and the instructions below. --JcK]]
5.4. Postmaster
An SMTP server that sends a reply message using a 521 code in
response to an initial connection is not subject to the postmaster
requirement of Section 4.5.1 of RFC 5321.
DISCUSSION:
Postmaster exists so you can report mail errors. A host that doesn't
support mail doesn't need a Postmaster.
6. SMTP client behavior
If an SMTP client encounters a host in an MX record that issues a 521
greeting message, it MUST do one of the following, but the choice is
left to the implementation:
a. Attempt to deliver it to a different MX host for that domain.
b. Return the mail with an appropriate non-delivery report.
If an SMTP client encounters a 521 reply code in any other part of
the SMTP dialog, it MUST return the mail with an appropriate non-
delivery report.
7. Context and other approaches
This specification, and the 521 code, are intended to address
situations in which an SMTP connection is attempted to a host that
does not support SMTP. An alternate approach is to provide
information about SMTP non-support in the hope of discouraging such
connection attempts. One way to do that using the DNS is specified
as the "null MX" approach [nullMX]. Even when that approach is used,
it is desirable to support a server that will return this code if a
connection is attempted on the SMTP port because client recognition
of the special DNS records for null MX is not universal.
8. Security Considerations
Klensin Expires February 10, 2015 [Page 5]
Internet-Draft SMTP 521 Reply Code August 2014
Not running any SMTP server, or running an SMTP server which simply
emits fixed strings in response to incoming connection should provide
significantly fewer opportunities for security problems than running
a complete SMTP implementation.
9. Contributors
Alain Durand and Francis Dupont created RFC 1846, and, because this
document copied large amounts of text from it, most of the text here.
They have not been listed as co-authors only before they could not be
contacted before this specification was posted.
10. References
10.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.
10.2. Informative References
[1] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846,
September 1995.
[2] 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.
Appendix A.1. Changes from RFC 1846
o Updated boilerplate and editorial material for a standards track
document. As part of this, added new Section 1 and Section 7.
o Removed "experimental" material
o Updated references and improved ties to RFC 5321.
o Mentioned the "nullMX" relationship.
Author's Address
Klensin Expires February 10, 2015 [Page 6]
Internet-Draft SMTP 521 Reply Code August 2014
John C Klensin, editor
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Klensin Expires February 10, 2015 [Page 7]
