rfcs/rfc2034.txt -rw-r--r-- 10.2 KiB
1
2
3
4
5
6
7Network Working Group N. Freed
8Request for Comments: RFC 2034 Innosoft
9Category: Standards Track October 1996
10
11
12 SMTP Service Extension for
13 Returning Enhanced Error Codes
14
15Status of this Memo
16
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
22
231. Abstract
24
25 This memo defines an extension to the SMTP service [RFC-821, RFC-
26 1869] whereby an SMTP server augments its responses with the enhanced
27 mail system status codes defined in RFC 1893. These codes can then
28 be used to provide more informative explanations of error conditions,
29 especially in the context of the delivery status notifications format
30 defined in RFC 1894.
31
322. Introduction
33
34 Although SMTP is widely and robustly deployed, various extensions
35 have been requested by parts of the Internet community. In
36 particular, in the modern, international, and multilingual Internet a
37 need exists to assign codes to specific error conditions that can be
38 translated into different languages. RFC 1893 defines such a set of
39 status codes and RFC 1894 defines a mechanism to send such coded
40 material to users. However, in many cases the agent creating the RFC
41 1894 delivery status notification is doing so in response to errors
42 it received from a remote SMTP server.
43
44 As such, remote servers need a mechanism for embedding enhanced
45 status codes in their responses as well as a way to indicate to a
46 client when they are in fact doing this. This memo uses the SMTP
47 extension mechanism described in RFC 1869 to define such a mechanism.
48
49
50
51
52
53
54
55
56
57
58Freed Standards Track [Page 1]
59
60RFC 2034 SMTP Enhanced Error Codes October 1996
61
62
633. Framework for the Enhanced Error Statuses Extension
64
65 The enhanced error statuses transport extension is laid out as
66 follows:
67
68 (1) the name of the SMTP service extension defined here is
69 Enhanced-Status-Codes;
70
71 (2) the EHLO keyword value associated with the extension is
72 ENHANCEDSTATUSCODES;
73
74 (3) no parameter is used with the ENHANCEDSTATUSCODES EHLO
75 keyword;
76
77 (4) the text part of all 2xx, 4xx, and 5xx SMTP responses
78 other than the initial greeting and any response to
79 HELO or EHLO are prefaced with a status code as defined
80 in RFC 1893. This status code is always followed by one
81 or more spaces.
82
83 (5) no additional SMTP verbs are defined by this extension;
84 and,
85
86 (6) the next section specifies how support for the
87 extension affects the behavior of a server and client
88 SMTP.
89
904. The Enhanced-Status-Codes service extension
91
92 Servers supporting the Enhanced-Status-Codes extension must preface
93 the text part of almost all response lines with a status code. As in
94 RFC 1893, the syntax of these status codes is given by the ABNF:
95
96 status-code ::= class "." subject "." detail
97 class ::= "2" / "4" / "5"
98 subject ::= 1*3digit
99 detail ::= 1*3digit
100
101 These codes must appear in all 2xx, 4xx, and 5xx response lines other
102 than initial greeting and any response to HELO or EHLO. Note that 3xx
103 responses are NOT included in this list.
104
105 All status codes returned by the server must agree with the primary
106 response code, that is, a 2xx response must incorporate a 2.X.X code,
107 a 4xx response must incorporate a 4.X.X code, and a 5xx response must
108 incorporate a 5.X.X code.
109
110
111
112
113
114Freed Standards Track [Page 2]
115
116RFC 2034 SMTP Enhanced Error Codes October 1996
117
118
119 When responses are continued across multiple lines the same status
120 code must appear at the beginning of the text in each line of the
121 response.
122
123 Servers supporting this extension must attach enhanced status codes
124 to their responses regardless of whether or not EHLO is employed by
125 the client.
126
1275. Status Codes and Negotiation
128
129 This specification does not provide a means for clients to request
130 that status codes be returned or that they not be returned; a
131 compliant server includes these codes in the responses it sends
132 regardless of whether or not the client expects them. This is
133 somewhat different from most other SMTP extensions, where generally
134 speaking a client must specifically make a request before the
135 extended server behaves any differently than an unextended server.
136 The omission of client negotiation in this case is entirely
137 intentional: Given the generally poor state of SMTP server error code
138 implementation it is felt that any step taken towards more
139 comprehensible error codes is something that all clients, extended or
140 not, should benefit from.
141
142 IMPORTANT NOTE: The use of this approach in this extension should be
143 seen as a very special case. It MUST NOT be taken as a license for
144 future SMTP extensions to dramatically change the nature of SMTP
145 client-server interaction without proper announcement from the server
146 and a corresponding enabling command from the client.
147
1486. Usage Example
149
150 The following dialogue illustrates the use of enhanced status codes
151 by a server:
152
153 S: <wait for connection on TCP port 25>
154 C: <open connection to server>
155 S: 220 dbc.mtview.ca.us SMTP service ready
156 C: EHLO ymir.claremont.edu
157 S: 250-dbc.mtview.ca.us says hello
158 S: 250 ENHANCEDSTATUSCODES
159 C: MAIL FROM:<ned@ymir.claremont.edu>
160 S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok
161 C: RCPT TO:<mrose@dbc.mtview.ca.us>
162 S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok
163 C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>
164 S: 550 5.1.1 Mailbox "nosuchuser" does not exist
165 C: RCPT TO:<remoteuser@isi.edu>
166 S: 551-5.7.1 Forwarding to remote hosts disabled
167
168
169
170Freed Standards Track [Page 3]
171
172RFC 2034 SMTP Enhanced Error Codes October 1996
173
174
175 S: 551 5.7.1 Select another host to act as your forwarder
176 C: DATA
177 S: 354 Send message, ending in CRLF.CRLF.
178 ...
179 C: .
180 S: 250 2.6.0 Message accepted
181 C: QUIT
182 S: 221 2.0.0 Goodbye
183
184 The client that receives these responses might then send a
185 nondelivery notification of the general form:
186
187 Date: Mon, 11 Mar 1996 09:21:47 -0400
188 From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>
189 Subject: Returned mail
190 To: <ned@ymir.claremont.edu>
191 MIME-Version: 1.0
192 Content-Type: multipart/report; report-type=delivery-status;
193 boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
194
195 --JAA13167.773673707/YMIR.CLAREMONT.EDU
196 content-type: text/plain; charset=us-ascii
197
198 ----- Mail was successfully relayed to
199 the following addresses -----
200
201 <mrose@dbc.mtview.ca.us>
202
203 ----- The following addresses had delivery problems -----
204 <nosuchuser@dbc.mtview.ca.us>
205 (Mailbox "nosuchuser" does not exist)
206 <remoteuser@isi.edu>
207 (Forwarding to remote hosts disabled)
208
209 --JAA13167.773673707/YMIR.CLAREMONT.EDU
210 content-type: message/delivery-status
211
212 Reporting-MTA: dns; ymir.claremont.edu
213
214 Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
215 Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
216 Action: relayed
217 Status: 2.1.5 (Destination address valid)
218 Diagnostic-Code: smtp;
219 250 Recipient <mrose@dbc.mtview.ca.us> ok
220 Remote-MTA: dns; dbc.mtview.ca.us
221
222
223
224
225
226Freed Standards Track [Page 4]
227
228RFC 2034 SMTP Enhanced Error Codes October 1996
229
230
231 Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
232 Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
233 Action: failed
234 Status: 5.1.1 (Bad destination mailbox address)
235 Diagnostic-Code: smtp;
236 550 Mailbox "nosuchuser" does not exist
237 Remote-MTA: dns; dbc.mtview.ca.us
238
239 Original-Recipient: rfc822;remoteuser@isi.edu
240 Final-Recipient: rfc822;remoteuser@isi.edu
241 Action: failed
242 Status: 5.7.1 (Delivery not authorized, message refused)
243 Diagnostic-Code: smtp;
244 551 Forwarding to remote hosts disabled
245 Select another host to act as your forwarder
246 Remote-MTA: dns; dbc.mtview.ca.us
247
248 --JAA13167.773673707/YMIR.CLAREMONT.EDU
249 content-type: message/rfc822
250
251 [original message goes here]
252 --JAA13167.773673707/YMIR.CLAREMONT.EDU--
253
254 Note that in order to reduce clutter the reporting MTA has omitted
255 enhanced status code information from the diagnostic-code fields it
256 has generated.
257
2587. Security Considerations
259
260 Additional detail in server responses axiomatically provides
261 additional information about the server. It is conceivable that
262 additional information of this sort may be of assistance in
263 circumventing server security. The advantages of provides additional
264 information must always be weighed against the security implications
265 of doing so.
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Freed Standards Track [Page 5]
283
284RFC 2034 SMTP Enhanced Error Codes October 1996
285
286
2878. References
288
289 [RFC-821]
290 Postel, J., "Simple Mail Transfer Protocol", RFC 821,
291 August, 1982. (August, 1982).
292
293 [RFC-1869]
294 Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed,
295 N., "SMTP Service Extensions", RFC 1869, November, 1995.
296
297 [RFC-1893]
298 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
299 1893, January, 1996.
300
301 [RFC-1894]
302 Moore, K., Vaudreuil, G., "An Extensible Message Format
303 for Delivery Status Notifications", RFC 1894, January,
304 1996.
305
3069. Author Address
307
308 Ned Freed
309 Innosoft International, Inc.
310 1050 East Garvey Avenue South
311 West Covina, CA 91790
312 USA
313 tel: +1 818 919 3600 fax: +1 818 919 3614
314 email: ned@innosoft.com
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Freed Standards Track [Page 6]
339