As per Relevance of the word experimental, we have this rfc below:
Network Working Group A.
Request For Comments: 1846
Category: Experimental F.
INRIA
September 1995
SMTP 521 Reply
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1]
reply code, 521, which one may use to indicate that an Internet
does not accept incoming mail
1.
Hosts on the Internet have shifted from large, general-purpose
to smaller, more specialized hosts. There is an increasing number
hosts which are dedicated to specific tasks, such as serving NTP
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
hosts. Regular SMTP clients attempting to deliver this
mail must treat the lack of an SMTP server on the host as a
error. They must queue the mail for later delivery, should an
server be started at a later time
This causes the mail to remain queued for days, until it is
with what is usually a confusing error message
2. Two complementary
Two complementary solutions MAY be implemented to deal with
issue. The first one is to use MX relays to bounce
mails. The second one is to implement a minimal smtp server on
mailless host to bounce all mails
The choice between the two solutions is site dependent
Durand & Dupont Experimental [Page 1]
RFC 1846 SMTP 521 Reply Code September 1995
3. The MX relays
MX relays may be used to indicate SMTP clients that an Internet
does not accept mail
During the SMTP dialog, these MX relays MAY bounce any
destinated to this particular host with an SMTP 521 reply code
SMTP dialog example
---> 220 relay.imag.fr
<--- HELO client.inria.
---> 250 relay.imag.fr Hello client.inria.
<--- MAIL FROM:
---> 250 ... Sender
<--- RCPT TO:
---> 521 nomail.imag.fr does not accept
<---
---> 221 relay.imag.fr closing
If an MX relay of precedence n for a mailless host bounces mails
its behalf, then any other MX relay of precedence lower than n
this mailless host SHOULD do the same
4. The SMTP server
4.1 521
A host may indicate that it does not accept mail by sending
initial 521 "Host does not accept mail" reply to an incoming
connection. The official name of the server host or its IP
MUST be sent as the first word following the reply code
For example: 521 canon.inria.fr does not accept
4.2 SMTP
After issuing the initial 521 reply, the server host MUST do one
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
reasonable time, the SMTP server MUST time out and close
connection. A suggested time-out value is 5 minutes
Durand & Dupont Experimental [Page 2]
RFC 1846 SMTP 521 Reply Code September 1995
DISCUSSION
When an SMTP server closes the connection immediatly after
the initial 521 reply, some existing SMTP clients treat
condition as a transient error and requeue the mail for
delivery. If the SMTP server leaves the connection open,
clients immediately send the QUIT command and return the mail
4.3
A host which sends a 521 greeting message MUST NOT be listed as an
record for any domain
4.4
An SMTP server which sends a 521 greeting message IS NOT subject
the postmaster requirement of STD 3, RFC 1123 ([2]).
DISCUSSION
Postmaster exists so you can report mail errors. A host that doesn'
support mail doesn't need a Postmaster
5. SMTP client
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
the SMTP dialog, it MUST return the mail with an appropriate non
delivery report
6. Security
Not running any SMTP server, or running an SMTP server which
emits fixed strings in response to incoming connection should
significantly fewer opportunities for security problems than
a complete SMTP implementation
Durand & Dupont Experimental [Page 3]
RFC 1846 SMTP 521 Reply Code September 1995
7. Authors'
Alain
Institut de Mathematiques Appliquees de Grenoble (IMAG
BP 53 38041 Grenoble CEDEX 9
Phone : +33 76 63 57 03
Fax : +33 76 44 66 75
EMail: Alain.Durand@imag.
Francis
Institut National de Recherche en Informatique et en
B.P. 105 / 78153 Le Chesnay CEDEX
Phone : +33 1 39 63 52 13
Fax : +33 1 39 63 53 30
EMail: Francis.Dupont@inria.
8.
People implementing this reply code are suggested to send a
to mailext@list.cren.net to report their experience
9.
[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/
Sciences Institute, October 1989.
Durand & Dupont Experimental [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
