idnits 2.17.00 (12 Aug 2021) /tmp/idnits32645/draft-ietf-yam-5321bis-smtp-pre-evaluation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 370: '... extensions SHOULD explicitly spe...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Small Editorial Errors: Clear up various small editorial errors, e.g., the use of "SHOULD not" in one location. YAM issue tracker issues 5, 6, 9, 12, and 13 refer to issues of this sort. The working group will add others that may be identified in its detailed review. See Appendix B for details. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Tracker Issue 13: In section 4.2.5, "SHOULD not" appears, with lowercase "not". The "NOT" should be in uppercase. http://trac.tools.ietf.org/wg/yam/trac/ticket/13 This item documents an editorial error, and the working group will make a change for it. -- The document date (January 28, 2010) is 4495 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 1869 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 YAM Working Group J. Klensin 3 Internet-Draft 4 Intended status: Informational B. Leiba 5 Expires: August 1, 2010 Huawei Technologies 6 January 28, 2010 8 Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP), 9 for advancement from Draft Standard to Full Standard by the YAM Working 10 Group 11 draft-ietf-yam-5321bis-smtp-pre-evaluation-03.txt 13 Abstract 15 This memo is a preliminary evaluation of RFC 5321, Simple Mail 16 Transfer Protocol for advancement from Draft to Full Standard. It 17 has been prepared by the The Yet Another Mail Working Group. 19 THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS 20 WRITTEN TO FACILITATE DISCUSSION WITH THE IESG. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 1, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . . 3 64 2. Preliminary Evaluation . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Document . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Time in Place . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.3. Implementation and Operational Experience . . . . . . . . . 3 68 2.4. Proposed Changes . . . . . . . . . . . . . . . . . . . . . 4 69 2.5. Non-Changes . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Downward references . . . . . . . . . . . . . . . . . . . . 6 71 2.7. IESG Feedback . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 79 A.1. Changes from version -01 to -02 . . . . . . . . . . . . . . 7 80 A.2. Changes from version -00 to -01 . . . . . . . . . . . . . . 8 81 Appendix B. Detailed Issues List . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 A preliminary evaluation has been made of Simple Mail Tranfer 87 Protocol [RFC5321] by the Yet Another Mail (YAM) Working Group for 88 advancing it from Draft to Full Standard. The YAM WG requests 89 feedback from the IESG on this decision. 91 1.1. Note to RFC Editor 93 This Internet-Draft is not meant to be published as an RFC. It is 94 written to facilitate processing within the IESG. 96 2. Preliminary Evaluation 98 2.1. Document 100 Title: Simple Mail Transfer Protocol 102 Link: http://tools.ietf.org/html/rfc5321 104 2.2. Time in Place 106 RFC2026: _ "A specification shall remain at the Draft Standard 107 level for at least four (4) months, or until at least one IETF 108 meeting has occurred." _ 110 Published: October 2008 112 2.3. Implementation and Operational Experience 114 RFC2026: _ "significant implementation and successful operational 115 experience ... characterized by a high degree of technical 116 maturity and by a generally held belief that the specified 117 protocol or service provides significant benefit to the Internet 118 community." _ 120 Confidence level: Very high. 122 Electronic mail (historically known as "netmail" before "email" came 123 into common use) has been in active use in the Internet community 124 since the early 1970s. Although many small adjustments and 125 clarifications have been made, the basic transport protocol that is 126 now used has been changed in only two important ways since the 127 publication of RFC 821 in August 1982. One of those changes was the 128 introduction of DNS-based mail routing with the MX record with RFC 129 974 in January 1986 (with some small clarifications in RFC 1123 in 130 October 1979). The second was the introduction of a model for 131 negotiating optional services with RFC 1425 in February 1993. 133 While many mail systems over the years have relied more on the 134 robustness of receiving systems in the face of deviations (or 135 creative interpretations of RFC 821 language in spite of changes and 136 clarifications over the last 27 years), the DRUMS WG work that 137 produced RFC 2821 [RFC2821] in April 2001 was largely an update to 138 clarify various provisions. With the exception of a very few edge- 139 case clarifications and changes in requirements levels, systems that 140 conform to the combination of RFC 821 [RFC0821] and RFC 1869 141 [RFC1869] (both Full Standards) conform to RFCs 2821 (April 2001) and 142 5321. Those differences represented existing practice when RFC 5321 143 was written and have been well-tested and widely deployed. 145 2.4. Proposed Changes 147 The YAM WG proposes making the changes listed below in a revision. 148 That the working group will review or consider an issue means that 149 when RFC 5321bis is submitted for IESG approval, either changes will 150 have be made for that issue or the working group will provide the 151 IESG a summary of why it decided not to. 153 Terminology: There has been ongoing controversy about the 154 terminology in RFC 5321 and especially changes made between 821 155 and 2821 or between 2821 and 5321. While we assume that 5321 is 156 adequate, the WG will review terminology as appropriate and may 157 make some adjustments. 159 Metalanguage: During and after IETF Last Call on 5321, some 160 suggestions were made about how to make metalanguage productions 161 easier to find and connect. A complete rewrite or restructuring 162 of the metalanguage should be avoided on the grounds that it would 163 carry a very high risk of introducing errors. Instead, resources 164 and tools permitting (significant manual work is now required), 165 the revised document will contain an index to productions and 166 where they are defined. 168 Normative References: RFC 5321 is worded in a way that makes some 169 references normative that are not strictly required to be. The WG 170 will consider whether those rewordings are appropriate. In 171 particular, the reference to RFC 821 will be moved to Informative 172 because all normative uses have been removed. 174 Existing Errata Reports: The working group will incorporate 175 corrections to accepted errata, as shown in the RFC Editor's 176 errata tool. Errata ID 1683 is currently the only such item. IDs 177 1543 and 1851 are reported, but unverified; the working group will 178 consider those. See Appendix B for details. 180 Small Editorial Errors: Clear up various small editorial errors, 181 e.g., the use of "SHOULD not" in one location. YAM issue tracker 182 issues 5, 6, 9, 12, and 13 refer to issues of this sort. The 183 working group will add others that may be identified in its 184 detailed review. See Appendix B for details. 186 Clarifications: The working group will attempt to address things 187 that have ben identified as unclear in RFC 5321. YAM issue 188 tracker issues 7, 8, 10, and 11 refer to issues of this sort. 189 There has been discussion of these on the mailing list, and the 190 resolutions of each may or may not result in a change in the 191 document. See Appendix B for details. In no case will 192 clarification changes be significant enough to violate "Non- 193 Changes", Section 2.5. 195 2.5. Non-Changes 197 The YAM WG discussed and chose not to make the following changes: 199 1. Complete revision, rearrangement, or reformatting of metalanguage 200 (see #2 above). 202 2. Any extensions that would violate the rules for Full Standard or 203 otherwise require revisiting the approved interoperability report 204 for RFC 5321. 206 3. A number of extensions and changes that would have imposed 207 significant new requirements on SMTP, or that would have implied 208 incompatible changes, were proposed both during the DRUMS WG 209 period (leading up to RFC 2821) and during the subsequent 210 discussions that led to RFC 5321. In each case, the authors were 211 advised to prepare a specific Internet-Draft describing the 212 change, convince the community to progress it to Proposed 213 Standard, and then implement and deploy the change quickly enough 214 to "catch up" with the progress that started with RFC 2821. The 215 notion was that those changes could then be integrated with the 216 progression at the same maturity level. It is important to note 217 that, independent of any constraints imposed by the YAM charter 218 design, none of those proposals have appeared and been progressed 219 even to IETF Last Call. 221 4. As agreed when RFC 5321 was reviewed, the examples will not be 222 revised to bring them into alignment with RFC 2606 (BCP 32) 223 conventions (example.com, etc.). The issues are explained in 224 Section 1.3 of RFC 5321. The community also noted at the time 225 that the relevant examples have been in use, substantially 226 unchanged, for more than a quarter-century with no serious claims 227 of confusion or other harm being caused. 229 5. The Security Considerations section was extensively reviewed last 230 year (during the review and approval of RFC 5321). No evidence 231 has appeared since then that would require further review or 232 additional changes. 234 2.6. Downward references 236 At Full Standard, the following references would be downward 237 references: 239 RFC 5322 if 5322bis is not progressed simultaneously with 5321bis. 240 (This is not expected to happen.) 242 RFC 4291, IP Version 6 Addressing Architecture. 244 RFC 3848, ESMTP and LMTP Transmission Types Registration. Note 245 that it is possible to rephrase RFC 5321bis to avoid this 246 normative reference and the WG will consider doing that. 248 2.7. IESG Feedback 250 The YAM WG requests feedback from the IESG on this decision. In 251 particular: 253 o Does the IESG believe the proposed changes are suitable during a 254 move from Draft to Full Standard? 256 o Excluding the previous proposed changes and expected IESG support 257 for technically substantive IETF last call feedback, does the IESG 258 believe any additional changes are critical to advance this 259 document from draft to full standard? If so, please provide 260 sufficient information so the WG can address these issues prior to 261 IETF last call or determine that the document is inappropriate for 262 the YAM WG to process at this time. 264 o Does the IESG consider the downward references acceptable for a 265 full standard? If not, please cite which specific downward 266 reference or references are problematic and why so the WG can 267 address these issues prior to IETF last call or determine the 268 document is inappropriate for the YAM WG to process at this time. 270 3. IANA Considerations 272 This document contains no IANA actions. 274 4. Security Considerations 276 This document requests IESG feedback and does not raise any security 277 concerns. Security considerations for RFC 5321 have been taken into 278 account during the preliminary evaluation and appear in either 279 Section 2.4 or Section 2.5 of this document. 281 5. Acknowledgments 283 This document was prepared from a template supplied by Subramanian 284 Moonesamy. 286 Some of the information provided in this document, but not provided 287 in the RFC 1652 evaluation (http://www.ietf.org/id/ 288 draft-ietf-yam-rfc1652bis-pre-evaluation-00.txt), was inspired by 289 brief discussions with Pasi Eronen and Subramanian Moonesamy during 290 IETF 76. 292 6. References 294 6.1. Normative References 296 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 297 October 2008. 299 6.2. Informative References 301 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 302 RFC 821, August 1982. 304 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 305 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 306 November 1995. 308 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 309 April 2001. 311 Appendix A. Change Log 313 A.1. Changes from version -01 to -02 315 o Added classes of changes for "errata" and "clarifications". 317 o Included YAM issue tracker numbers in the lists of possible 318 changes. 320 A.2. Changes from version -00 to -01 322 o Added Security Considerations and Examples to the "no change" list 323 in Section 2.5. 325 o Identified RFC 821 as a specific reference to be moved from 326 Normative to Informative. 328 o Add blanket placeholder for changes due to small editorial errors. 330 Appendix B. Detailed Issues List 332 What follows are abbreviated details of the errata and tracker issues 333 at the time of this writing, along with URLs to the actual entries. 334 They are provided here to make it easier for IESG members -- and 335 others -- to review them. If your browser does not automatically 336 turn URLs into clickable links, copy/paste should still be 337 convenient. 339 Errata ID 1543: In section 3.8, client should treat a closed 340 connection as a 451 response, not as 421 (current). 341 http://www.rfc-editor.org/errata_search.php?rfc=5321 342 The working group will consider this item. Discussion so far 343 leans toward not making the change. 345 Errata ID 1683: In section 4.4, missing repeat in grammar for 346 Additional-Registered-Clauses. 347 http://www.rfc-editor.org/errata_search.php?rfc=5321 348 This item has been accepted, and the working group will make a 349 change for it. 351 Errata ID 1851: In section 4.1.1.5, text specifying server behaviour 352 on a closed connection is misplaced, and should be in section 353 4.1.1.10 or section 3.8. 354 http://www.rfc-editor.org/errata_search.php?rfc=5321 355 The working group will consider this item. 357 Tracker Issue 5: In section 6.1, reword "next subsection" to specify 358 the section number, for clarity. 359 http://trac.tools.ietf.org/wg/yam/trac/ticket/5 360 This item suggests an editorial change, and the working group will 361 consider it. 363 Tracker Issue 6: In section 4.4, there is extraneous text that 364 should be removed or corrected (probably a paste error). 365 http://trac.tools.ietf.org/wg/yam/trac/ticket/6 366 This item documents an editorial error, and the working group will 367 make a change for it. 369 Tracker Issue 7: In section 2.2.2, add a bullet saying "Future SMTP 370 extensions SHOULD explicitly specify if they are valid on the 371 Submission port." 372 http://trac.tools.ietf.org/wg/yam/trac/ticket/7 373 The working group will consider this item. 375 Tracker Issue 8: In section 4.1.1.3, remove text about source routes 376 and move text about failed recipients here. 377 http://trac.tools.ietf.org/wg/yam/trac/ticket/8 378 The working group will consider this item. 380 Tracker Issue 9: In section 3.9.2, there is extraneous text that 381 should be removed or corrected (probably a paste error). 382 http://trac.tools.ietf.org/wg/yam/trac/ticket/9 383 This item documents an editorial error, and the working group will 384 make a change for it. 386 Tracker Issue 10: In section 3.9, add a subsection for "Backup MX" 387 or "Plain forwarding". 388 http://trac.tools.ietf.org/wg/yam/trac/ticket/10 389 The working group will consider this item. 391 Tracker Issue 11: In section 3.1, a server can offer two greeting 392 codes to a new connection: 220 or 554. Clarify the semantics of 393 the 554 code. 394 http://trac.tools.ietf.org/wg/yam/trac/ticket/11 395 The working group will consider this item. 397 Tracker Issue 12: In examples, explicitly state that the examples 398 will not be changed to use RFC 2606 domain names (such as 399 example.com). 400 http://trac.tools.ietf.org/wg/yam/trac/ticket/12 401 This item suggests an editorial change, and the working group will 402 consider it. 404 Tracker Issue 13: In section 4.2.5, "SHOULD not" appears, with 405 lowercase "not". The "NOT" should be in uppercase. 406 http://trac.tools.ietf.org/wg/yam/trac/ticket/13 407 This item documents an editorial error, and the working group will 408 make a change for it. 410 Authors' Addresses 412 John C Klensin 413 1770 Massachusetts Ave, Ste 322 414 Cambridge, MA 02140 415 USA 417 Phone: +1 617 245 1457 418 Email: john+ietf@jck.com 420 Barry Leiba 421 Huawei Technologies 423 Phone: +1 646 827 0648 424 Email: barryleiba@computer.org 425 URI: http://internetmessagingtechnology.org/