idnits 2.17.1 draft-hansen-4468upd-mailesc-registry-03.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 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 418. 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 147: '...tandards-track documents SHOULD accept...' -- 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 (January 10, 2008) is 5950 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: 4 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) January 10, 2008 6 Intended status: Standards Track 7 Expires: July 13, 2008 9 A Registry for SMTP Enhanced Mail System Status Codes 10 draft-hansen-4468upd-mailesc-registry-03 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 July 13, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The specification for enhanced mail system enhanced status codes, RFC 44 3463, establishes a new code model and lists a collection of status 45 codes. While it anticipated that more codes would be added over 46 time, it did not provide an explicit mechanism for registering and 47 tracking those codes. This document specifies an IANA registry for 48 mail system enhanced status codes, and initializes that registry with 49 the codes so far established in published standards-track documents, 50 as well as other codes that have become established in the industry. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . 4 57 2.2. Review Process for New Values . . . . . . . . . . . . . . 5 58 2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 5 59 2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 64 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . . . 13 68 1. Introduction 70 Enhanced Status Codes for SMTP were first defined in [RFC1893], 71 subsequently replaced by [RFC3463]. While it anticipated that more 72 codes would be added over time (see its Section 2), it did not 73 provide an explicit mechanism for registering and tracking those 74 codes. Since that time, various RFCs have been published and 75 internet drafts proposed that define further status codes. However, 76 without an IANA registry, conflicts in definitions have begun to 77 appear. 79 This RFC defines such an IANA registry and was written to help 80 prevent further conflicts from appearing in the future. It 81 initializes the registry with the established standards-track 82 enhanced status codes from [RFC3463], [RFC3886], [RFC4468] and 83 [RFC4954]. In addition, several codes are added that were 84 established by various internet drafts and have come into common use, 85 despite the expiration of the documents themselves. 87 NOTE: The values given in Table 1 below are incomplete. 89 This document is being discussed on the SMTP mailing list, 90 ietf-smtp@imc.org. (RFC EDITOR NOTE: Remove this paragraph on 91 publication.) 93 2. IANA Considerations 95 2.1. SMTP Enhanced Status Codes Registry 97 IANA is directed to create the registry "SMTP Enhanced Status Codes". 98 The Mail Enhanced Status Codes registry will have three tables: 100 o class sub-code, 102 o subject sub-code, and 104 o enumerated status codes, which include both a subject sub-code and 105 a detail sub-code. 107 Each entry in the tables will include: 109 1. The sub-code or enumerated status code, which will be a numeric 110 code consisting of three components, as specified in RFC 3463. 112 2. Text expected to be associated with the code. 114 3. If applicable, the basic status code of RFC 2821 [RFC2821] with 115 which it is usually associated. 117 4. A short description of the code. 119 5. A reference to the document in which the code is defined. This 120 reference should note whether the relevant specification is 121 standards-track or not. 123 6. The identity of the submitter, usually the document author. 125 7. The identity of the owner for the specification. This will be 126 "IESG" in the case of IETF-produced documents. 128 An example of an entry in the enumerated status code table would be: 130 X.0.0 Other undefined Status 131 Associated basic status code: any 132 Other undefined status is the only undefined error code. 133 X.0.0 should be used for all errors for which only the class of 134 the error is known. 136 Defined in RFC 3463. 138 Submitter: G. Vaudreuil 140 Owner: IESG. 142 2.2. Review Process for New Values 144 Entries in this registry are expected to follow the "Specification 145 Required" model ([RFC2434]) although, in practice, most entries are 146 expected to derive from standards-track documents. However, any 147 review process for non-standards-track documents SHOULD accept 148 evidence of significant deployment as a persuasive argument that the 149 registration should be permitted: the principal purpose of this 150 registry is to avoid confusion and conflicts among different 151 definitions or uses for the same code. 153 The procedures from [RFC4020] may be followed to pre-allocate an 154 Enhanced Status Code before final publication of an internet draft. 156 2.3. Registration Updates 158 Standards-track registrations may be updated if the relevant 159 standards are updated as a consequence of that action. Non- 160 standards-track entries may be updated by the listed responsible 161 party. Only the entry's short description or references may be 162 modified in this way, not the code or associated text. In 163 exceptional cases, any aspect of any registered entity may be updated 164 at the direction of the IESG (for example, to correct a conflict). 166 2.4. Initial Values 168 The initial values for the class and subject sub-code tables is to be 169 populated from section 2 of [RFC3463]. Specifically, these are the 170 values for 2.XXX.XXX, 4.XXX.XXX and 5.XXX.XXX for the class sub-code 171 table, and the values X.0.XXX, X.1.XXX, X.2.XXX, X.3.XXX, X.4.XXX, 172 X.5.XXX, X.6.XXX and X.7.XXX for the subject sub-code table. Each 173 entry is to be designated as defined in [RFC3463], submitted by G. 174 Vaudreuil, and owned by IESG. 176 The initial values for the enumerated status code table is to be 177 populated from: 179 1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through 180 X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through 181 X.4.7, 183 2. X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 through 184 X.7.7) section 3.3.4 of [RFC3886] (X.1.9), 186 3. X.6.6 found in section 5 of [RFC4468], 188 4. and X.5.6, X.7.8, X.7.9, X.7.11 and X.7.12, found in section 6 of 189 [RFC4954]. 191 Each entry is to be designated as defined in the corresponding RFC, 192 submitted by the corresponding RFC author, and owned by the IESG. 194 The initial values for the Associated Basic Status Code for each of 195 the above initial enhanced status codes is given in the following 196 table. 197 NOTE: this table is incomplete. 199 +--------------+------------------+--------------+------------------+ 200 | Enhanced | Associated Basic | Enhanced | Associated Basic | 201 | Status Code | Status Code | Status Code | Status Code | 202 +--------------+------------------+--------------+------------------+ 203 | X.0.0 | any | X.1.0 | ??? | 204 | | | | | 205 | X.1.1 | ??? | X.1.2 | ??? | 206 | | | | | 207 | X.1.3 | ??? | X.1.4 | ??? | 208 | | | | | 209 | X.1.5 | 250 | X.1.6 | ??? | 210 | | | | | 211 | X.1.7 | ??? | X.1.8 | ??? | 212 | | | | | 213 | X.2.0 | ??? | X.2.1 | ??? | 214 | | | | | 215 | X.2.2 | 552 | X.2.3 | ??? | 216 | | | | | 217 | X.2.4 | ??? | X.3.0 | ??? | 218 | | | | | 219 | X.3.1 | ??? | X.3.2 | ??? | 220 | | | | | 221 | X.3.3 | ??? | X.3.4 | 554 | 222 | | | | | 223 | X.3.5 | ??? | X.4.0 | ??? | 224 | | | | | 225 | X.4.1 | 451 | X.4.2 | ??? | 226 | | | | | 227 | X.4.3 | ??? | X.4.4 | ??? | 228 | | | | | 229 | X.4.5 | ??? | X.4.6 | ??? | 230 | | | | | 231 | X.4.7 | ??? | X.5.0 | 250, 554, 503 | 232 | | | | | 233 | X.5.1 | ??? | X.5.2 | ??? | 234 | X.5.3 | ??? | X.5.4 | ??? | 235 | | | | | 236 | X.5.5 | ??? | X.5.6 | 500 | 237 | | | | | 238 | X.6.0 | ??? | X.6.1 | ??? | 239 | | | | | 240 | X.6.2 | ??? | X.6.3 | 554 | 241 | | | | | 242 | X.6.4 | 250 | X.6.5 | ??? | 243 | | | | | 244 | X.6.6 | 554 | X.7.0 | 235, 454, 530, | 245 | | | | 554 | 246 | | | | | 247 | X.7.1 | 550 | X.7.2 | ??? | 248 | | | | | 249 | X.7.3 | ??? | X.7.4 | ??? | 250 | | | | | 251 | X.7.5 | ??? | X.7.6 | ??? | 252 | | | | | 253 | X.7.7 | ??? | X.7.8 | 554, 535 | 254 | | | | | 255 | X.7.9 | 534 | X.7.11 | 538 | 256 | | | | | 257 | X.7.12 | 432 | | | 258 +--------------+------------------+--------------+------------------+ 260 Table 1 262 The following additional definitions are to be registered in the 263 enumerated status code table. (RFC EDITOR NOTE: change XXXX below to 264 this document's RFC number.) 266 X.7.10 Encryption Needed 267 Associated basic status code: ??? 268 This indicates that external strong privacy layer is needed in 269 order to use the requested authentication mechanism. This is 270 primarily intended for use with clear text authentication 271 mechanisms. A client which receives this may activate a security 272 layer such as TLS prior to authenticating, or attempt to use a 273 stronger mechanism. 274 Defined: RFC XXXX. 275 Submitter: T. Hansen, J. Klensin 276 Owner: IESG. 278 X.7.13 User Account Disabled 279 Associated basic status code: ??? 280 Sometimes a system administrator will have to disable a user's 281 account (e.g., due to lack of payment, abuse, evidence of a 282 break-in attempt, etc). This error code occurs after a successful 283 authentication to a disabled account. This informs the client 284 that the failure is permanent until the user contacts their system 285 administrator to get the account re-enabled. It differs from a 286 generic authentication failure where the client's best option is 287 to present the passphrase entry dialog in case the user simply 288 mistyped their passphrase. 289 Defined: RFC XXXX. 290 Submitter: T. Hansen, J. Klensin 291 Owner: IESG. 293 X.7.14 Trust relationship required 294 Associated basic status code: ??? 295 The submission server requires a configured trust relationship 296 with a third-party server in order to access the message content. 297 This value replaces the prior use of X.7.8 for this error 298 condition. thereby updating [RFC4468]. 299 Defined: RFC XXXX. 300 Submitter: T. Hansen, J. Klensin 301 Owner: IESG. 303 3. Security Considerations 305 As stated in [RFC1893], use of enhanced status codes may disclose 306 additional information about how an internal mail system is 307 implemented beyond that available through the SMTP status codes. 309 Many proposed additions to the response code list are security 310 related. Having these registered in one place to prevent collisions 311 will improve their value. Security error responses can leak 312 information to active attackers (e.g., the distinction between "user 313 not found" and "bad password" during authentication). Documents 314 defining security error codes should make it clear when this is the 315 case so SMTP server software subject to such threats can provide 316 appropriate controls to restrict exposure. 318 4. Acknowledgements 320 While the need for this registry should have become clear shortly 321 after [RFC3463] was approved, the growth of the code table through 322 additional documents and work done as part of email 323 internationalization and [RFC2821] updating efforts made the 324 requirement much more clear. The comments of the participants in 325 those efforts are gratefully acknowledged, particularly the members 326 of the ietf-smtp@imc.org mailing list. Chris Newman and Randy 327 Gellens provided useful comments and some text for early versions of 328 the document. 330 5. References 332 5.1. Normative References 334 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 335 RFC 3463, January 2003. 337 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 338 April 2001. 340 [RFC3886] Allman, E., "An Extensible Message Format for Message 341 Tracking Responses", RFC 3886, September 2004. 343 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 344 Standards Track Code Points", BCP 100, RFC 4020, 345 February 2005. 347 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 348 May 2006. 350 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 351 for Authentication", RFC 4954, July 2007. 353 5.2. Informative References 355 [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", 356 RFC 1893, January 1996. 358 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 359 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 360 October 1998. 362 Authors' Addresses 364 Tony Hansen 365 AT&T Laboratories 366 200 Laurel Ave. 367 Middletown, NJ 07748 368 USA 370 Email: tony+mailesc@maillennium.att.com 372 John C Klensin 373 1770 Massachusetts Ave, Ste 322 374 Cambridge, MA 02140 375 USA 377 Phone: +1 617 245 1457 378 Email: john+ietf@jck.com 380 Full Copyright Statement 382 Copyright (C) The IETF Trust (2008). 384 This document is subject to the rights, licenses and restrictions 385 contained in BCP 78, and except as set forth therein, the authors 386 retain all their rights. 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 391 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 392 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 393 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Intellectual Property 398 The IETF takes no position regarding the validity or scope of any 399 Intellectual Property Rights or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; nor does it represent that it has 403 made any independent effort to identify any such rights. Information 404 on the procedures with respect to rights in RFC documents can be 405 found in BCP 78 and BCP 79. 407 Copies of IPR disclosures made to the IETF Secretariat and any 408 assurances of licenses to be made available, or the result of an 409 attempt made to obtain a general license or permission for the use of 410 such proprietary rights by implementers or users of this 411 specification can be obtained from the IETF on-line IPR repository at 412 http://www.ietf.org/ipr. 414 The IETF invites any interested party to bring to its attention any 415 copyrights, patents or patent applications, or other proprietary 416 rights that may cover technology that may be required to implement 417 this standard. Please address the information to the IETF at 418 ietf-ipr@ietf.org. 420 Acknowledgment 422 Funding for the RFC Editor function is provided by the IETF 423 Administrative Support Activity (IASA).