draft-ietf-mailext-smtp-521
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 04:52:29 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 23 Mar 1995 23:00:00 GMT
ETag: "2edaa5-1929-2f71fd70"
Accept-Ranges: bytes
Content-Length: 6441
Connection: close
Content-Type: text/plain
Internet Engineering Task Force A. Durand, F. Dupont, J. G. Myers
INTERNET-DRAFT IMAG, INRIA Rocquencourt, CMU
March, 1995
SMTP 521 reply code
<draft-ietf-mailext-smtp-521-03.txt>
1. Status
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
2. Abstract
This memo defines a new SMTP ([1]) reply code, 521, which one may use
to indicate that an Internet host does not accept incoming mail.
3. 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.
Expires Octobre 1995 [Page 1]
4. 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.
5. 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.
6. The SMTP server solution
6.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
Expires Octobre 1995 [Page 2]
6.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.
6.3 MX
A host which sends a 521 greeting message MUST NOT be listed as an MX
record for any domain.
6.4 Postmaster
An SMTP server which sends a 521 greeting message IS NOT subject to
the postmaster requirement of RFC1123 ([2]).
DISCUSSION:
Postmaster exists so you can report mail errors. A host
that doesn't support mail doesn't need a Postmaster.
7. 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.
Expires Octobre 1995 [Page 3]
8. Security considerations
Not running any SMTP server, or running A 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. Author 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
E-Mail: 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
E-Mail: Francis.Dupont@inria.fr
John G. Myers
Carnegie-Mellon University
5000 Forbes Ave. Pittsburgh PA, 15213-3890
E-mail: jgm+@cmu.edu
10. References
[1] J.B. Postel. Simple Mail Transfer Protocol, Request For Comments 821
STD 10, (August, 1982).
[2] Braden, R.,ed. Requirements for Internet hosts - application and
support, Request For Comments 1123. (October 1989)
Expires Octobre 1995 [Page 4]