RFC 1846 EXPERIMENTAL EMAIL · SMTP

SMTP 521 Reply Code

A new SMTP reply code that lets a host say plainly that it does not take mail.

On rfc-editor.org ↗
PUBLISHED
September 1995
AUTHORS
A. Durand, F. Dupont
STREAM
IETF
UPDATED BY
RFC 7504 — SMTP 521 and 556 Reply Codes
REPLY CODE
521
MEANING
Host does not accept mail
SUGGESTED TIME-OUT
5 minutes
CATEGORY
Experimental
DOI
10.17487/RFC1846

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                          A. Durand
Request For Comments: 1846                                          IMAG
Category: Experimental                                         F. Dupont
                                                      INRIA Rocquencourt
                                                          September 1995


                          SMTP 521 Reply Code


Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This memo defines a new Simple Mail Transfer Protocol (SMTP) [1]
   reply code, 521, which one may use to indicate that an Internet host
   does not accept incoming mail.

1. Motivations

   Hosts on the Internet have shifted from large, general-purpose hosts
   to smaller, more specialized hosts.  There is an increasing number of
   hosts which 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 must treat the lack of an SMTP server on the host as a temporary
   error.  They must queue the mail for later delivery, should an SMTP
   server be 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.

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

3. The MX relays solution

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

   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.

4. The SMTP server solution

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

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

   When an SMTP server closes the connection immediatly 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 send the QUIT command and return the mail.

4.3 MX

   A host which sends a 521 greeting message MUST NOT be listed as an MX
   record for any domain.

4.4 Postmaster

   An SMTP server which sends a 521 greeting message IS NOT subject to
   the postmaster requirement of STD 3, RFC 1123 ([2]).

   DISCUSSION:

   Postmaster exists so you can report mail errors.  A host that doesn't
   support mail doesn't need a Postmaster.

5. 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 two options:

   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.

6. Security Considerations

   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.

7. Authors' Addresses

   Alain Durand
   Institut de Mathematiques Appliquees de Grenoble (IMAG)
   BP 53 38041 Grenoble CEDEX 9 France

   Phone : +33 76 63 57 03
   Fax   : +33 76 44 66 75
   EMail: Alain.Durand@imag.fr


   Francis Dupont
   Institut National de Recherche en Informatique et en Automatique
   B.P. 105 / 78153 Le Chesnay CEDEX France

   Phone : +33 1 39 63 52 13
   Fax   : +33 1 39 63 53 30
   EMail: Francis.Dupont@inria.fr

8. Expericences

   People implementing this reply code are suggested to send a message
   to mailext@list.cren.net to report their experience.

9. References

   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

   [2] Braden, R., Editor, "Requirements for Internet Hosts -
       Application and Support", STD 3, RFC 1123, USC/Information
       Sciences Institute, October 1989.

AI ELI5

On this page
PROBLEMMail misaddressed to hosts that run no SMTP server must be queued as a temporary error, so it sits for days before coming back with a confusing message.
MECHANISMA host or an MX relay answers with the new SMTP reply code 521, meaning the host does not accept mail, and clients then return the mail or try another MX host.
STATUS TODAYThe memo is Experimental and is listed as updated by RFC 7504.

§1Why a 521 Reply Is Needed

More and more Internet hosts are dedicated to tasks such as serving NTP or DNS, and they often provide no mail service and run no SMTP server. Users sometimes misaddress mail to them.

A regular SMTP client must treat the missing server as a temporary error and queue the mail in case a server starts later. The mail then stays queued for days until it comes back with what is usually a confusing error message. This memo defines reply code 521 to say that a host does not accept incoming mail.

If you mail a letter to a house nobody lives in, the post office keeps trying for days. A clear sign would save everyone the wait.

§2Two Complementary Solutions

Two solutions MAY be implemented, and the choice is site dependent. In the first, MX relays bounce mail for the mailless host with a 521 reply during the SMTP dialog, at the RCPT TO step. If an MX relay of precedence n does this, any relay of lower precedence number for that host SHOULD do the same.

In the second, the mailless host runs a minimal SMTP server whose initial greeting is 521, with its official name or IP address as the first word after the code. The server MUST then either close the connection or answer every command except QUIT with 521, timing out if the client does not quit (5 minutes is suggested).

Either a helper office takes the mail and says the house takes no mail, or the house answers the door itself and says so.

MX RELAY BOUNCING WITH 521 (RFC 1846 EXAMPLE, SIMPLIFIED)
SMTP clientMX relay
  1. 220 ready
  2. HELO
  3. 250 Hello
  4. MAIL FROM
  5. 250 Sender Ok
  6. RCPT TOAddressed to the mailless host.
  7. 521 does not accept mail
  8. QUIT
  9. 221 closing connection

§3Rules for Servers and Clients

A host that sends a 521 greeting MUST NOT be listed as an MX record for any domain, and it is not subject to the postmaster requirement of STD 3, RFC 1123, since a host without mail needs no one to report mail errors to.

Closing the connection right after the greeting makes some existing clients treat it as transient and requeue the mail, while leaving it open makes them send QUIT and return the mail. A client that meets a 521 greeting from an MX host must either try a different MX host or return the mail with a non-delivery report. A 521 anywhere else in the dialog MUST lead to the mail being returned.

A no-mail house must not be listed as a place to send mail, and anyone who is told no must either try another address or give the letter back.

§4Security Considerations

The memo argues that running no SMTP server, or one that only emits fixed strings, should give significantly fewer opportunities for security problems than a complete SMTP implementation. Implementers are asked to report their experience to a mailing list named in the memo.

A door that only ever says one sentence is harder to trick than a door that does many things.

§5References