| Network Working Group | J. Klensin, Ed. |
| Internet-Draft | |
| Obsoletes: 1846 (if approved) | August 11, 2014 |
| Updates: 5321 (if approved) | |
| Intended status: Standards Track | |
| Expires: February 12, 2015 |
SMTP 521 Reply Code
draft-klensin-rfc1846bis-00.txt
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.
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 12, 2015.
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.
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.
The SMTP specification [2] 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.
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].
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.
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.
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.
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.
After issuing the initial 521 reply, the server host MUST do one of the following two options:
DISCUSSION:
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.
A host which sends a 521 greeting message MUST NOT be listed as an MX record for any domain except as specified above.
[CREF1]Note in draft: this seemed a tad contradictory to the text above and the instructions below. --JcK
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.
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:
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.
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 [4]. 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.
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.
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.
| [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] | Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995. |
| [4] | Levine, J. and M. Delany, "A "Null MX" No Service Resource Record for Domains that Accept No Mail", August 2014. |
RFC Editor: Please remove this appendix before publication.