1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
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]
^L
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]
^L
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]
^L
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]
^L
|
