]>

1770 Massachusetts Ave, Ste 322 Cambridge MA 02140 USA +1 617 245 1457 john-ietf@jck.com

Applications Reply code Email Server 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.

The SMTP specification 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. 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.

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: ---> 250 ... Sender Ok <--- RCPT TO: ---> 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: Close the SMTP connection. 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: 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. 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: Attempt to deliver it to a different MX host for that domain. 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.

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

&rfc2119; &rfc5321; &rfc1846;

RFC Editor: Please remove this appendix before publication.

Updated boilerplate and editorial material for a standards track document. As part of this, added new and . Removed "experimental" material Updated references and improved ties to RFC 5321. Mentioned the "nullMX" relationship.