7Network Working Group T. Hansen
8Request for Comments: 5248 AT&T Laboratories
10Updates: 3463, 4468, 4954 June 2008
11Category: Best Current Practice
14 A Registry for SMTP Enhanced Mail System Status Codes
18 This document specifies an Internet Best Current Practices for the
19 Internet Community, and requests discussion and suggestions for
20 improvements. Distribution of this memo is unlimited.
24 The specification for enhanced mail system status codes, RFC 3463,
25 establishes a new code model and lists a collection of status codes.
26 While it anticipated that more codes would be added over time, it did
27 not provide an explicit mechanism for registering and tracking those
28 codes. This document specifies an IANA registry for mail system
29 enhanced status codes, and initializes that registry with the codes
30 so far established in published standards-track documents, as well as
31 other codes that have become established in the industry.
35 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
36 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
37 2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . . 2
38 2.2. Review Process for New Values . . . . . . . . . . . . . . . 4
39 2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 4
40 2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5
41 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
42 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
43 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
44 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
45 5.2. Informative References . . . . . . . . . . . . . . . . . . 9
58Hansen & Klensin Best Current Practice [Page 1]
60RFC 5248 SMTP Enhanced Status Code Registry June 2008
65 Enhanced Status Codes for SMTP were first defined in [RFC1893], which
66 was subsequently replaced by [RFC3463]. While it anticipated that
67 more codes would be added over time (see section 2 of [RFC3463]), it
68 did not provide an explicit mechanism for registering and tracking
69 those codes. Since then, various RFCs have been published and
70 internet drafts proposed that define additional status codes.
71 However, without an IANA registry, conflicts in definitions have
74 This RFC defines such an IANA registry and was written to help
75 prevent further conflicts from appearing in the future. It
76 initializes the registry with the established standards-track
77 enhanced status codes from [RFC3463], [RFC3886], [RFC4468], and
78 [RFC4954]. In addition, this document adds several codes to the
79 registry that were established by various internet drafts and have
80 come into common use, despite the expiration of the documents
83 As specified in [RFC3463], an enhanced status code consists of a
84 three-part code, with each part being numeric and separated by a
85 period character. The three portions are known as the class sub-
86 code, the subject sub-code, and the detail sub-code. In the tables,
87 a wildcard for the class sub-code is represented by an X, a wildcard
88 for a subject sub-code is represented by an XXX, and a wildcard for a
89 detail sub-code is represented by a YYY. For example, 3.XXX.YYY has
90 an unspecified subject sub-code and an unspecified status code, and
91 X.5.0 is has an unspecified class sub-code. (This is a change from
92 [RFC3463], which uses XXX for both the subject sub-code and detail
972.1. SMTP Enhanced Status Codes Registry
99 IANA has created the registry "SMTP Enhanced Status Codes". The SMTP
100 Enhanced Status Codes registry will have three tables:
103 Each of the entries in this table represent class sub-codes and
104 all have an unspecified subject sub-code and an unspecified detail
108 Each of the entries in this table represent subject sub-codes and
109 all have an unspecified class sub-code and an unspecified detail
114Hansen & Klensin Best Current Practice [Page 2]
116RFC 5248 SMTP Enhanced Status Code Registry June 2008
119 o Enumerated Status Codes
120 Each of the entries in this table represent the combination of a
121 subject sub-code and a detail sub-code. All entries will have an
122 unspecified class sub-code, a specified subject sub-code, and a
123 specified detail sub-code.
125 Each entry in the tables will include the following. (The sub-code
126 tables will not have the Associated Basic Status Code entries.)
128 Code: The status code. For example,
129 3.XXX.YYY is a class sub-code with an
130 unspecified subject sub-code and an
131 unspecified detail sub-code, and X.5.0
132 is an enumerated status code with an
133 unspecified class sub-code.
135 Summary: or Sample Text: For class and subject sub-codes, this
136 is the summary of the use for the sub-
137 code shown in section 2 of [RFC3463].
138 For enumerated status codes, this is an
139 example of a message that might be sent
142 Associated Basic Status Code: For enumerated status codes, the basic
143 status code(s) of [RFC2821] with which
144 it is usually associated. This may
145 also have a value such as "Any" or "Not
146 given". NOTE: This is a non-exclusive
147 list. In particular, the entries that
148 list some basic status codes for an
149 Enhanced Status Code might allow for
150 other basic status codes, while the
151 entries denoted "Not given" can be
152 filled in by updating the IANA registry
153 through updates to this document or at
154 the direction of the IESG.
156 Description: A short description of the code.
158 Reference: A reference to the document in which
159 the code is defined. This reference
160 should note whether the relevant
161 specification is standards-track, best
162 current practice, or neither, using one
163 of "(Standards track)", "(Best current
164 practice)" or "(Not standards track)".
170Hansen & Klensin Best Current Practice [Page 3]
172RFC 5248 SMTP Enhanced Status Code Registry June 2008
175 Submitter: The identity of the submitter, usually
178 Change Controller: The identity of the change controller
179 for the specification. This will be
180 "IESG" in the case of IETF-produced
183 An example of an entry in the enumerated status code table would be:
186 Sample Text: Other undefined Status
187 Associated basic status code: Any
188 Description: Other undefined status is the only undefined
189 error code. It should be used for all errors for
190 which only the class of the error is known.
191 Reference: RFC 3463 (Standards track)
192 Submitter: G. Vaudreuil
193 Change controller: IESG.
1952.2. Review Process for New Values
197 Entries in this registry are expected to follow the "Specification
198 Required" model ([RFC5226]) although, in practice, most entries are
199 expected to derive from standards-track documents. Non-standards-
200 track documents that specify codes to be registered should be readily
201 available. The principal purpose of this registry is to avoid
202 confusion and conflicts among different definitions or uses for the
2052.3. Registration Updates
207 Standards-track registrations may be updated if the relevant
208 standards are updated as a consequence of that action. Non-
209 standards-track entries may be updated by the listed change
210 controller. Only the entry's short description or references may be
211 modified in this way, not the code or associated text. In
212 exceptional cases, any aspect of any registered entity may be updated
213 at the direction of the IESG (for example, to correct a conflict).
226Hansen & Klensin Best Current Practice [Page 4]
228RFC 5248 SMTP Enhanced Status Code Registry June 2008
233 The initial values for the class and subject sub-code tables are to
234 be populated from section 2 of [RFC3463]. Specifically, these are
235 the values for 2.XXX.YYY, 4.XXX.YYY, and 5.XXX.YYY for the Class Sub-
236 Code table, and the values X.0.YYY, X.1.YYY, X.2.YYY, X.3.YYY,
237 X.4.YYY, X.5.YYY, X.6.YYY, and X.7.YYY for the Subject Sub-Code
238 table. The code, sample text, and description for each entry are to
239 be taken from [RFC3463]. Each entry is to use [RFC3463] as the
240 reference, submitted by G. Vaudreuil, and change controlled by the
241 IESG. There are no associated detail sub-code values for the class
242 and subject sub-code tables.
244 The initial values for the Enumerated Status Code table is to be
247 1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through
248 X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through
249 X.4.7, X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0
252 2. section 3.3.4 of [RFC3886] (X.1.9),
254 3. X.6.6 found in section 5 of [RFC4468], (but not X.7.8 found in
257 4. and X.5.6, X.7.8, X.7.9, X.7.11, and X.7.12, found in section 6
258 of [RFC4954] (using the text from X.5.6, 5.7.8, 5.7.9, 5.7.11,
261 Each entry is to be designated as defined in the corresponding RFC,
262 submitted by the corresponding RFC author, and change controlled by
263 the IESG. Each of the above RFCs is a standards-track document.
265 The initial values for the Associated Basic Status Code for each of
266 the above initial enhanced status codes is given in the following
269 As noted above, this table is incomplete. In particular, the entries
270 that have some basic status codes might allow for other detail sub-
271 status codes, while the entries denoted "Not given" can be filled in
272 by updating the IANA registry through updates to this document or at
273 the direction of the IESG.
282Hansen & Klensin Best Current Practice [Page 5]
284RFC 5248 SMTP Enhanced Status Code Registry June 2008
287 +--------+---------------+--------+----------+--------+-------------+
288 | Enh. | Assoc. Basic | Enh. | Assoc. | Enh. | Assoc. |
289 | Status | Status Code | Status | Basic | Status | Basic |
290 | Code | | Code | Status | Code | Status Code |
292 +--------+---------------+--------+----------+--------+-------------+
293 | X.0.0 | Any | X.1.0 | Not | X.1.1 | 451, 550 |
295 | X.1.2 | Not given | X.1.3 | 501 | X.1.4 | Not given |
296 | X.1.5 | 250 | X.1.6 | Not | X.1.7 | Not given |
298 | X.1.8 | 451, 501 | X.1.9 | Not | X.2.0 | Not given |
300 | X.2.1 | Not given | X.2.2 | 552 | X.2.3 | 552 |
301 | X.2.4 | 450, 452 | X.3.0 | 221, | X.3.1 | 452 |
305 | | | | 550, 554 | | |
306 | X.3.2 | 453 | X.3.3 | Not | X.3.4 | 552, 554 |
308 | X.3.5 | Not given | X.4.0 | Not | X.4.1 | 451 |
310 | X.4.2 | 421 | X.4.3 | 451, 550 | X.4.4 | Not given |
311 | X.4.5 | 451 | X.4.6 | Not | X.4.7 | Not given |
313 | X.5.0 | 220, 250, | X.5.1 | 430, | X.5.2 | 500, 501, |
314 | | 251, 252, | | 500, | | 502, 550, |
315 | | 253, 451, | | 501, | | 555 |
316 | | 452, 454, | | 503, | | |
317 | | 458, 459, | | 530, | | |
318 | | 501, 502, | | 550, | | |
319 | | 503, 554 | | 554, 555 | | |
320 | X.5.3 | 451 | X.5.4 | 451, | X.5.5 | Not given |
325 | | | | 550, 555 | | |
326 | X.5.6 | 500 | X.6.0 | Not | X.6.1 | Not given |
328 | X.6.2 | Not given | X.6.3 | 554 | X.6.4 | 250 |
329 | X.6.5 | Not given | X.6.6 | 554 | X.7.0 | 220, 235, |
330 | | | | | | 450, 454, |
331 | | | | | | 500, 501, |
332 | | | | | | 503, 504, |
333 | | | | | | 530, 535, |
338Hansen & Klensin Best Current Practice [Page 6]
340RFC 5248 SMTP Enhanced Status Code Registry June 2008
343 | X.7.1 | 451, 454, | X.7.2 | 550 | X.7.3 | Not given |
344 | | 502, 503, | | | | |
345 | | 533, 550, 551 | | | | |
346 | X.7.4 | 504 | X.7.5 | Not | X.7.6 | Not given |
348 | X.7.7 | Not given | X.7.8 | 535, 554 | X.7.9 | 534 |
349 | X.7.10 | 523 | X.7.11 | 524, 538 | X.7.12 | 422, 432 |
350 | X.7.13 | 525 | X.7.14 | 535, 554 | | |
351 +--------+---------------+--------+----------+--------+-------------+
355 The following additional definitions have been registered in the
356 enumerated status code table. These entries have been used in the
357 industry without any published specification.
360 Sample Text: Encryption Needed
362 Description: This indicates that an external strong privacy
363 layer is needed in order to use the requested
364 authentication mechanism. This is primarily
365 intended for use with clear text authentication
366 mechanisms. A client that receives this may
367 activate a security layer such as TLS prior to
368 authenticating, or attempt to use a stronger
370 Reference: RFC 5248 (Best current practice)
371 Submitter: T. Hansen, J. Klensin
372 Change controller: IESG
394Hansen & Klensin Best Current Practice [Page 7]
396RFC 5248 SMTP Enhanced Status Code Registry June 2008
400 Sample Text: User Account Disabled
402 Description: Sometimes a system administrator will have to
403 disable a user's account (e.g., due to lack of
404 payment, abuse, evidence of a break-in attempt,
405 etc.). This error code occurs after a successful
406 authentication to a disabled account. This
407 informs the client that the failure is permanent
408 until the user contacts their system
409 administrator to get the account re-enabled. It
410 differs from a generic authentication failure
411 where the client's best option is to present the
412 passphrase entry dialog in case the user simply
413 mistyped their passphrase.
414 Reference: RFC 5248 (Best current practice)
415 Submitter: T. Hansen, J. Klensin
416 Change controller: IESG
419 Sample Text: Trust relationship required
420 Associated basic status code: 535, 554
421 Description: The submission server requires a configured trust
422 relationship with a third-party server in order
423 to access the message content. This value
424 replaces the prior use of X.7.8 for this error
425 condition, thereby updating [RFC4468].
426 Reference: RFC 5248 (Best current practice)
427 Submitter: T. Hansen, J. Klensin
428 Change controller: IESG
4303. Security Considerations
432 As stated in [RFC1893], use of enhanced status codes may disclose
433 additional information about how an internal mail system is
434 implemented beyond that available through the SMTP status codes.
436 Many proposed additions to the response code list are security
437 related. Having these registered in one place to prevent collisions
438 will improve their value. Security error responses can leak
439 information to active attackers (e.g., the distinction between "user
440 not found" and "bad password" during authentication). Documents
441 defining security error codes should make it clear when this is the
442 case so SMTP server software subject to such threats can provide
443 appropriate controls to restrict exposure.
450Hansen & Klensin Best Current Practice [Page 8]
452RFC 5248 SMTP Enhanced Status Code Registry June 2008
457 While the need for this registry should have become clear shortly
458 after [RFC3463] was approved, the growth of the code table through
459 additional documents and work done as part of email
460 internationalization and [RFC2821] updating efforts made the
461 requirement much more clear. The comments of the participants in
462 those efforts are gratefully acknowledged, particularly the members
463 of the ietf-smtp@imc.org mailing list. Chris Newman and Randy
464 Gellens provided useful comments and some text for early versions of
4695.1. Normative References
471 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
474 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
475 RFC 3463, January 2003.
477 [RFC3886] Allman, E., "An Extensible Message Format for Message
478 Tracking Responses", RFC 3886, September 2004.
480 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468,
483 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
484 for Authentication", RFC 4954, July 2007.
4865.2. Informative References
488 [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes",
489 RFC 1893, January 1996.
491 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
492 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
506Hansen & Klensin Best Current Practice [Page 9]
508RFC 5248 SMTP Enhanced Status Code Registry June 2008
519 EMail: tony+mailesc@maillennium.att.com
523 1770 Massachusetts Ave, Ste 322
527 Phone: +1 617 245 1457
528 EMail: john+ietf@jck.com
562Hansen & Klensin Best Current Practice [Page 10]
564RFC 5248 SMTP Enhanced Status Code Registry June 2008
567Full Copyright Statement
569 Copyright (C) The IETF Trust (2008).
571 This document is subject to the rights, licenses and restrictions
572 contained in BCP 78, and except as set forth therein, the authors
573 retain all their rights.
575 This document and the information contained herein are provided on an
576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
578 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
579 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
580 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
585 The IETF takes no position regarding the validity or scope of any
586 Intellectual Property Rights or other rights that might be claimed to
587 pertain to the implementation or use of the technology described in
588 this document or the extent to which any license under such rights
589 might or might not be available; nor does it represent that it has
590 made any independent effort to identify any such rights. Information
591 on the procedures with respect to rights in RFC documents can be
592 found in BCP 78 and BCP 79.
594 Copies of IPR disclosures made to the IETF Secretariat and any
595 assurances of licenses to be made available, or the result of an
596 attempt made to obtain a general license or permission for the use of
597 such proprietary rights by implementers or users of this
598 specification can be obtained from the IETF on-line IPR repository at
599 http://www.ietf.org/ipr.
601 The IETF invites any interested party to bring to its attention any
602 copyrights, patents or patent applications, or other proprietary
603 rights that may cover technology that may be required to implement
604 this standard. Please address the information to the IETF at
618Hansen & Klensin Best Current Practice [Page 11]