7Network Working Group N. Freed
8Request for Comments: RFC 2034 Innosoft
9Category: Standards Track October 1996
12 SMTP Service Extension for
13 Returning Enhanced Error Codes
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.
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
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.
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.
58Freed Standards Track [Page 1]
60RFC 2034 SMTP Enhanced Error Codes October 1996
633. Framework for the Enhanced Error Statuses Extension
65 The enhanced error statuses transport extension is laid out as
68 (1) the name of the SMTP service extension defined here is
69 Enhanced-Status-Codes;
74 (3) no parameter is used with the ENHANCEDSTATUSCODES EHLO
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
83 (5) no additional SMTP verbs are defined by this extension;
86 (6) the next section specifies how support for the
87 extension affects the behavior of a server and client
904. The Enhanced-Status-Codes service extension
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:
96 status-code ::= class "." subject "." detail
97 class ::= "2" / "4" / "5"
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.
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.
114Freed Standards Track [Page 2]
116RFC 2034 SMTP Enhanced Error Codes October 1996
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
123 Servers supporting this extension must attach enhanced status codes
124 to their responses regardless of whether or not EHLO is employed by
1275. Status Codes and Negotiation
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.
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.
150 The following dialogue illustrates the use of enhanced status codes
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
170Freed Standards Track [Page 3]
172RFC 2034 SMTP Enhanced Error Codes October 1996
175 S: 551 5.7.1 Select another host to act as your forwarder
177 S: 354 Send message, ending in CRLF.CRLF.
180 S: 250 2.6.0 Message accepted
184 The client that receives these responses might then send a
185 nondelivery notification of the general form:
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>
192 Content-Type: multipart/report; report-type=delivery-status;
193 boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
195 --JAA13167.773673707/YMIR.CLAREMONT.EDU
196 content-type: text/plain; charset=us-ascii
198 ----- Mail was successfully relayed to
199 the following addresses -----
201 <mrose@dbc.mtview.ca.us>
203 ----- The following addresses had delivery problems -----
204 <nosuchuser@dbc.mtview.ca.us>
205 (Mailbox "nosuchuser" does not exist)
207 (Forwarding to remote hosts disabled)
209 --JAA13167.773673707/YMIR.CLAREMONT.EDU
210 content-type: message/delivery-status
212 Reporting-MTA: dns; ymir.claremont.edu
214 Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
215 Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
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
226Freed Standards Track [Page 4]
228RFC 2034 SMTP Enhanced Error Codes October 1996
231 Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
232 Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
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
239 Original-Recipient: rfc822;remoteuser@isi.edu
240 Final-Recipient: rfc822;remoteuser@isi.edu
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
248 --JAA13167.773673707/YMIR.CLAREMONT.EDU
249 content-type: message/rfc822
251 [original message goes here]
252 --JAA13167.773673707/YMIR.CLAREMONT.EDU--
254 Note that in order to reduce clutter the reporting MTA has omitted
255 enhanced status code information from the diagnostic-code fields it
2587. Security Considerations
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
282Freed Standards Track [Page 5]
284RFC 2034 SMTP Enhanced Error Codes October 1996
290 Postel, J., "Simple Mail Transfer Protocol", RFC 821,
291 August, 1982. (August, 1982).
294 Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed,
295 N., "SMTP Service Extensions", RFC 1869, November, 1995.
298 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
302 Moore, K., Vaudreuil, G., "An Extensible Message Format
303 for Delivery Status Notifications", RFC 1894, January,
309 Innosoft International, Inc.
310 1050 East Garvey Avenue South
311 West Covina, CA 91790
313 tel: +1 818 919 3600 fax: +1 818 919 3614
314 email: ned@innosoft.com
338Freed Standards Track [Page 6]