RFC1846 - SMTP 521 Reply Code

王朝other·作者佚名  2008-05-31
宽屏版  字体: |||超大  

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, RFC1123 ([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, RFC821,

USC/Information Sciences Institute, August 1982.

[2] Braden, R., Editor, "Requirements for Internet Hosts -

Application and Support", STD 3, RFC1123, USC/Information

Sciences Institute, October 1989.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
© 2005- 王朝网络 版权所有