The RFC Archive
 The RFC Archive   RFC 1846   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1846

SMTP 521 Reply Code

Last modified on Thursday, September 28th, 1995

Permanent link to RFC 1846
Search GitHub Wiki for RFC 1846
Show other RFCs mentioning RFC 1846







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.



Durand & Dupont               Experimental                   PAGE 1 top


RFC 1846 SMTP 521 Reply Code September 1995 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. Durand & Dupont Experimental PAGE 2 top

RFC 1846 SMTP 521 Reply Code September 1995 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. Durand & Dupont Experimental PAGE 3 top

RFC 1846 SMTP 521 Reply Code September 1995 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. Durand & Dupont Experimental PAGE 4 top

SMTP 521 Reply Code RFC TOTAL SIZE: 6558 bytes PUBLICATION DATE: Thursday, September 28th, 1995 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1846: The IETF Trust, Thursday, September 28th, 1995
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement