idnits 2.17.1 draft-hansen-4468upd-mailesc-registry-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC4468, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3463, but the abstract doesn't seem to directly say this. It does mention RFC3463 though, so this could be OK. -- The draft header indicates that this document updates RFC4954, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3463, updated by this document, for RFC5378 checks: 2001-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 18, 2008) is 5851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) -- Obsolete informational reference (is this intentional?): RFC 1893 (Obsoleted by RFC 3463) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen 3 Internet-Draft AT&T Laboratories 4 Updates: 3463,4468,4954 J. Klensin 5 (if approved) April 18, 2008 6 Intended status: Standards Track 7 Expires: October 20, 2008 9 A Registry for SMTP Enhanced Mail System Status Codes 10 draft-hansen-4468upd-mailesc-registry-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 20, 2008. 37 Abstract 39 The specification for enhanced mail system enhanced status codes, RFC 40 3463, establishes a new code model and lists a collection of status 41 codes. While it anticipated that more codes would be added over 42 time, it did not provide an explicit mechanism for registering and 43 tracking those codes. This document specifies an IANA registry for 44 mail system enhanced status codes, and initializes that registry with 45 the codes so far established in published standards-track documents, 46 as well as other codes that have become established in the industry. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . 3 53 2.2. Review Process for New Values . . . . . . . . . . . . . . 5 54 2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 5 55 2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 60 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 Enhanced Status Codes for SMTP were first defined in [RFC1893], 67 subsequently replaced by [RFC3463]. While it anticipated that more 68 codes would be added over time (see its Section 2), it did not 69 provide an explicit mechanism for registering and tracking those 70 codes. Since that time, various RFCs have been published and 71 internet drafts proposed that define further status codes. However, 72 without an IANA registry, conflicts in definitions have begun to 73 appear. 75 This RFC defines such an IANA registry and was written to help 76 prevent further conflicts from appearing in the future. It 77 initializes the registry with the established standards-track 78 enhanced status codes from [RFC3463], [RFC3886], [RFC4468] and 79 [RFC4954]. In addition, several codes are added that were 80 established by various internet drafts and have come into common use, 81 despite the expiration of the documents themselves. 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 a XXX, and a wildcard for a 89 detail sub-code is represented by an 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 93 sub-code wildcards.) 95 This document is being discussed on the SMTP mailing list, 96 ietf-smtp@imc.org. (RFC EDITOR NOTE: Remove this paragraph on 97 publication.) 99 2. IANA Considerations 101 2.1. SMTP Enhanced Status Codes Registry 103 IANA is directed to create the registry "SMTP Enhanced Status Codes". 104 The Mail Enhanced Status Codes registry will have three tables: 106 o Class Sub-Codes. Each of the entries in this table represent 107 class sub-codes and all have an unspecified subject sub-code and 108 an unspecified detail sub-code. 110 o Subject Sub-Codes. Each of the entries in this table represent 111 subject sub-codes and all have an unspecified class sub-code and 112 an unspecified detail sub-code. 113 o Enumerated Status Codes. Each of the entries in this table 114 represent the combination of a subject sub-code and a detail sub- 115 code. All entries will have an unspecified class sub-code, a 116 specified subject sub-code, and a specified detail sub-code. 118 Each entry in the tables will include the following. (The sub-code 119 tables will not have the Associated Basic Status Code entries.) 121 Code: The status code. For example, 122 3.XXX.YYY is a class sub-code with an 123 unspecified subject sub-code and an 124 unspecified detail sub-code, and X.5.0 125 is an enumerated status code with an 126 unspecified class sub-code. 127 Summary: or Sample Text: For class and subject sub-codes, this 128 is the summary of the use for the sub- 129 code shown in section 2 of [RFC3463]. 130 For enumerated status codes, this is an 131 example of a message that might be sent 132 along with the code. 133 Associated Basic Status Code: For enumerated status codes, the basic 134 status code(s) of [RFC2821] with which 135 it is usually associated. This may 136 also have a value such as "Any" or "Not 137 given". NOTE: This is a non-exclusive 138 list. In particular, the entries that 139 list some basic status codes for an 140 Enhanced Status Code might allow for 141 other basic status codes, while the 142 entries denoted "Not given" can be 143 filled in by updating the IANA registry 144 through updates to this document or at 145 the direction of the IESG. 146 Description: A short description of the code. 147 Reference: A reference to the document in which 148 the code is defined. This reference 149 should note whether the relevant 150 specification is standards-track or not 151 using "(Standards track)" or "(Not 152 standards track)". 153 Submitter: The identity of the submitter, usually 154 the document author. 156 Change Controller: The identity of the change controller 157 for the specification. This will be 158 "IESG" in the case of IETF-produced 159 documents. 161 An example of an entry in the enumerated status code table would be: 163 Code: X.0.0 164 Sample Text: Other undefined Status 165 Associated basic status code: Any 166 Description: Other undefined status is the only undefined 167 error code. It should be used for all errors for 168 which only the class of the error is known. 169 Reference: RFC 3463. (Standards track) 170 Submitter: G. Vaudreuil 171 Change controller: IESG. 173 2.2. Review Process for New Values 175 Entries in this registry are expected to follow the "Specification 176 Required" model ([RFC2434]) although, in practice, most entries are 177 expected to derive from standards-track documents. Non-standards- 178 track documents that specify codes to be registered should be readily 179 available. The principal purpose of this registry is to avoid 180 confusion and conflicts among different definitions or uses for the 181 same code. 183 The procedures from [RFC4020] may be followed to pre-allocate an 184 Enhanced Status Code before final publication of an internet draft. 186 2.3. Registration Updates 188 Standards-track registrations may be updated if the relevant 189 standards are updated as a consequence of that action. Non- 190 standards-track entries may be updated by the listed responsible 191 party. Only the entry's short description or references may be 192 modified in this way, not the code or associated text. In 193 exceptional cases, any aspect of any registered entity may be updated 194 at the direction of the IESG (for example, to correct a conflict). 196 2.4. Initial Values 198 The initial values for the class and subject sub-code tables are to 199 be populated from section 2 of [RFC3463]. Specifically, these are 200 the values for 2.XXX.YYY, 4.XXX.YYY and 5.XXX.YYY for the Class Sub- 201 Code table, and the values X.0.YYY, X.1.YYY, X.2.YYY, X.3.YYY, 202 X.4.YYY, X.5.YYY, X.6.YYY and X.7.YYY for the Subject Sub-Code table. 203 The code, sample text and description for each entry are to be taken 204 from [RFC3463]. Each entry is to use [RFC3463] as the reference, 205 submitted by G. Vaudreuil, and change controlled by IESG. There are 206 no associated detail sub-code values for the class and subject sub- 207 code tables. 209 The initial values for the Enumerated Status Code table is to be 210 populated from: 212 1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through 213 X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through 214 X.4.7, X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 215 through X.7.7) 216 2. section 3.3.4 of [RFC3886] (X.1.9), 217 3. X.6.6 found in section 5 of [RFC4468], (but not X.7.8 found in 218 the same section), 219 4. and X.5.6, X.7.8, X.7.9, X.7.11 and X.7.12, found in section 6 of 220 [RFC4954]. 222 Each entry is to be designated as defined in the corresponding RFC, 223 submitted by the corresponding RFC author, and change controlled by 224 the IESG. Each of the above RFCs is a standards track document. 226 The initial values for the Associated Basic Status Code for each of 227 the above initial enhanced status codes is given in the following 228 table. 230 As noted above, this table is incomplete. In particular, the entries 231 that have some basic status codes might allow for other detail sub- 232 status codes, while the entries denoted "Not given" can be filled in 233 by updating the IANA registry through updates to this document or at 234 the direction of the IESG. 236 +--------+---------+--------+-------------+--------+----------------+ 237 | Enh. | Assoc. | Enh. | Assoc. | Enh. | Assoc. Basic | 238 | Status | Basic | Status | Basic | Status | Status Code | 239 | Code | Status | Code | Status Code | Code | | 240 | | Code | | | | | 241 +--------+---------+--------+-------------+--------+----------------+ 242 | X.0.0 | Any | X.1.0 | Not given | X.1.1 | 451, 550 | 243 | X.1.2 | Not | X.1.3 | 501 | X.1.4 | Not given | 244 | | given | | | | | 245 | X.1.5 | 250 | X.1.6 | Not given | X.1.7 | Not given | 246 | X.1.8 | 451, | X.2.0 | Not given | X.2.1 | Not given | 247 | | 501 | | | | | 248 | X.2.2 | 552 | X.2.3 | 552 | X.2.4 | 450, 452 | 249 | X.3.0 | 221, | X.3.1 | 452 | X.3.2 | 453 | 250 | | 250, | | | | | 251 | | 421, | | | | | 252 | | 451, | | | | | 253 | | 550, | | | | | 254 | | 554 | | | | | 255 | X.3.3 | Not | X.3.4 | 552, 554 | X.3.5 | Not given | 256 | | given | | | | | 257 | X.4.0 | Not | X.4.1 | 451 | X.4.2 | 421 | 258 | | given | | | | | 259 | X.4.3 | 451, | X.4.4 | Not given | X.4.5 | 451 | 260 | | 550 | | | | | 261 | X.4.6 | Not | X.4.7 | Not given | X.5.0 | 220, 250, 251, | 262 | | given | | | | 252, 253, 451, | 263 | | | | | | 452, 454, 458, | 264 | | | | | | 459, 501, 502, | 265 | | | | | | 503, 554 | 266 | X.5.1 | 430, | X.5.2 | 500, 501, | X.5.3 | 451 | 267 | | 500, | | 502, 550, | | | 268 | | 501, | | 555 | | | 269 | | 503, | | | | | 270 | | 530, | | | | | 271 | | 550, | | | | | 272 | | 554, | | | | | 273 | | 555 | | | | | 274 | X.5.4 | 451, | X.5.5 | Not given | X.5.6 | 500 | 275 | | 501, | | | | | 276 | | 502, | | | | | 277 | | 503, | | | | | 278 | | 504, | | | | | 279 | | 550, | | | | | 280 | | 555 | | | | | 281 | X.6.0 | Not | X.6.1 | Not given | X.6.2 | Not given | 282 | | given | | | | | 283 | X.6.3 | 554 | X.6.4 | 250 | X.6.5 | Not given | 284 | X.6.6 | 554 | X.7.0 | 220, 235, | X.7.1 | 451, 454, 502, | 285 | | | | 450, 454, | | 503, 533, 550, | 286 | | | | 500, 501, | | 551 | 287 | | | | 503, 504, | | | 288 | | | | 530, 535, | | | 289 | | | | 550 | | | 290 | X.7.2 | 550 | X.7.3 | Not given | X.7.4 | 504 | 291 | X.7.5 | Not | X.7.6 | Not given | X.7.7 | Not given | 292 | | given | | | | | 293 | X.7.8 | 535, | X.7.9 | 534 | X.7.11 | 524, 538 | 294 | | 554 | | | | | 295 | X.7.12 | 422, | | | | | 296 | | 432 | | | | | 297 +--------+---------+--------+-------------+--------+----------------+ 299 Table 1 301 The following additional definitions are to be registered in the 302 enumerated status code table. These entries have been used in the 303 industry without any published specification. (RFC EDITOR NOTE: 304 change XXXX below to this document's RFC number.) 306 Code: X.7.10 307 Sample Text: Encryption Needed 308 Associated basic status code: 523 309 Description: This indicates that external strong privacy layer 310 is needed in order to use the requested 311 authentication mechanism. This is primarily 312 intended for use with clear text authentication 313 mechanisms. A client which receives this may 314 activate a security layer such as TLS prior to 315 authenticating, or attempt to use a stronger 316 mechanism. 317 Reference: RFC XXXX. (Standards track) 318 Submitter: T. Hansen, J. Klensin 319 Change controller: IESG. 321 Code: X.7.13 322 Sample Text: User Account Disabled 323 Associated basic status code: 525 324 Description: Sometimes a system administrator will have to 325 disable a user's account (e.g., due to lack of 326 payment, abuse, evidence of a break-in attempt, 327 etc). This error code occurs after a successful 328 authentication to a disabled account. This 329 informs the client that the failure is permanent 330 until the user contacts their system 331 administrator to get the account re-enabled. It 332 differs from a generic authentication failure 333 where the client's best option is to present the 334 passphrase entry dialog in case the user simply 335 mistyped their passphrase. 336 Reference: RFC XXXX. (Standards track) 337 Submitter: T. Hansen, J. Klensin 338 Change controller: IESG. 340 Code: X.7.14 341 Sample Text: Trust relationship required 342 Associated basic status code: 535, 554 343 Description: The submission server requires a configured trust 344 relationship with a third-party server in order 345 to access the message content. This value 346 replaces the prior use of X.7.8 for this error 347 condition. thereby updating [RFC4468]. 348 Reference: RFC XXXX. (Standards track) 349 Submitter: T. Hansen, J. Klensin 350 Change controller: IESG. 352 3. Security Considerations 354 As stated in [RFC1893], use of enhanced status codes may disclose 355 additional information about how an internal mail system is 356 implemented beyond that available through the SMTP status codes. 358 Many proposed additions to the response code list are security 359 related. Having these registered in one place to prevent collisions 360 will improve their value. Security error responses can leak 361 information to active attackers (e.g., the distinction between "user 362 not found" and "bad password" during authentication). Documents 363 defining security error codes should make it clear when this is the 364 case so SMTP server software subject to such threats can provide 365 appropriate controls to restrict exposure. 367 4. Acknowledgements 369 While the need for this registry should have become clear shortly 370 after [RFC3463] was approved, the growth of the code table through 371 additional documents and work done as part of email 372 internationalization and [RFC2821] updating efforts made the 373 requirement much more clear. The comments of the participants in 374 those efforts are gratefully acknowledged, particularly the members 375 of the ietf-smtp@imc.org mailing list. Chris Newman and Randy 376 Gellens provided useful comments and some text for early versions of 377 the document. 379 5. References 381 5.1. Normative References 383 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 384 RFC 3463, January 2003. 386 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 387 April 2001. 389 [RFC3886] Allman, E., "An Extensible Message Format for Message 390 Tracking Responses", RFC 3886, September 2004. 392 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 393 Standards Track Code Points", BCP 100, RFC 4020, 394 February 2005. 396 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 397 May 2006. 399 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 400 for Authentication", RFC 4954, July 2007. 402 5.2. Informative References 404 [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", 405 RFC 1893, January 1996. 407 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 408 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 409 October 1998. 411 Authors' Addresses 413 Tony Hansen 414 AT&T Laboratories 415 200 Laurel Ave. 416 Middletown, NJ 07748 417 USA 419 Email: tony+mailesc@maillennium.att.com 420 John C Klensin 421 1770 Massachusetts Ave, Ste 322 422 Cambridge, MA 02140 423 USA 425 Phone: +1 617 245 1457 426 Email: john+ietf@jck.com 428 Full Copyright Statement 430 Copyright (C) The IETF Trust (2008). 432 This document is subject to the rights, licenses and restrictions 433 contained in BCP 78, and except as set forth therein, the authors 434 retain all their rights. 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 439 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 440 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 441 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 Intellectual Property 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at 466 ietf-ipr@ietf.org.