]>

1770 Massachusetts Ave, Ste 322 Cambridge MA 02140 USA +1 617 245 1457 john+ietf@jck.com

Huawei Technologies

+1 646 827 0648 barryleiba@computer.org http://internetmessagingtechnology.org/

Applications YAM Working Group SMTP RFC 2821ter This memo is a preliminary evaluation of RFC 5321, Simple Mail Transfer Protocol for advancement from Draft to Full Standard. It has been prepared by the The Yet Another Mail Working Group. THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS WRITTEN TO FACILITATE DISCUSSION WITH THE IESG.

A preliminary evaluation has been made of Simple Mail Tranfer Protocol by the Yet Another Mail (YAM) Working Group for advancing it from Draft to Full Standard. The YAM WG requests feedback from the IESG on this decision.

This Internet-Draft is not meant to be published as an RFC. It is written to facilitate processing within the IESG.

Simple Mail Transfer Protocol http://tools.ietf.org/html/rfc5321

"A specification shall remain at the Draft Standard level for at least four (4) months, or until at least one IETF meeting has occurred." October 2008

"significant implementation and successful operational experience ... characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community." Very high. Electronic mail (historically known as "netmail" before "email" came into common use) has been in active use in the Internet community since the early 1970s. Although many small adjustments and clarifications have been made, the basic transport protocol that is now used has been changed in only two important ways since the publication of RFC 821 in August 1982. One of those changes was the introduction of DNS-based mail routing with the MX record with RFC 974 in January 1986 (with some small clarifications in RFC 1123 in October 1979). The second was the introduction of a model for negotiating optional services with RFC 1425 in February 1993. While many mail systems over the years have relied more on the robustness of receiving systems in the face of deviations (or creative interpretations of RFC 821 language in spite of changes and clarifications over the last 27 years), the DRUMS WG work that produced RFC 2821 in April 2001 was largely an update to clarify various provisions. With the exception of a very few edge-case clarifications and changes in requirements levels, systems that conform to the combination of RFC 821 and RFC 1869 (both Full Standards) conform to RFCs 2821 (April 2001) and 5321. Those differences represented existing practice when RFC 5321 was written and have been well-tested and widely deployed.

The YAM WG proposes making the changes listed below in a revision. That the working group will review or consider an issue means that when RFC 5321bis is submitted for IESG approval, either changes will have be made for that issue or the working group will provide the IESG a summary of why it decided not to. There has been ongoing controversy about the terminology in RFC 5321 and especially changes made between 821 and 2821 or between 2821 and 5321. While we assume that 5321 is adequate, the WG will review terminology as appropriate and may make some adjustments. During and after IETF Last Call on 5321, some suggestions were made about how to make metalanguage productions easier to find and connect. A complete rewrite or restructuring of the metalanguage should be avoided on the grounds that it would carry a very high risk of introducing errors. Instead, resources and tools permitting (significant manual work is now required), the revised document will contain an index to productions and where they are defined. RFC 5321 is worded in a way that makes some references normative that are not strictly required to be. The WG will consider whether those rewordings are appropriate. In particular, the reference to RFC 821 will be moved to Informative because all normative uses have been removed. The working group will incorporate corrections to accepted errata, as shown in the RFC Editor's errata tool. Errata ID 1683 is currently the only such item. IDs 1543 and 1851 are reported, but unverified; the working group will consider those. See for details. 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 for details. The working group will attempt to address things that have ben identified as unclear in RFC 5321. YAM issue tracker issues 7, 8, 10, and 11 refer to issues of this sort. There has been discussion of these on the mailing list, and the resolutions of each may or may not result in a change in the document. See for details. In no case will clarification changes be significant enough to violate "Non-Changes", .

The YAM WG discussed and chose not to make the following changes: Complete revision, rearrangement, or reformatting of metalanguage (see #2 above). Any extensions that would violate the rules for Full Standard or otherwise require revisiting the approved interoperability report for RFC 5321. A number of extensions and changes that would have imposed significant new requirements on SMTP, or that would have implied incompatible changes, were proposed both during the DRUMS WG period (leading up to RFC 2821) and during the subsequent discussions that led to RFC 5321. In each case, the authors were advised to prepare a specific Internet-Draft describing the change, convince the community to progress it to Proposed Standard, and then implement and deploy the change quickly enough to "catch up" with the progress that started with RFC 2821. The notion was that those changes could then be integrated with the progression at the same maturity level. It is important to note that, independent of any constraints imposed by the YAM charter design, none of those proposals have appeared and been progressed even to IETF Last Call. As agreed when RFC 5321 was reviewed, the examples will not be revised to bring them into alignment with RFC 2606 (BCP 32) conventions (example.com, etc.). The issues are explained in Section 1.3 of RFC 5321. The community also noted at the time that the relevant examples have been in use, substantially unchanged, for more than a quarter-century with no serious claims of confusion or other harm being caused. The Security Considerations section was extensively reviewed in 2008 (during the review and approval of RFC 5321). No evidence has appeared since then that would require further review or additional changes.

At Full Standard, the following references would be downward references: RFC 5322 if 5322bis is not progressed simultaneously with 5321bis. (This is not expected to happen.) RFC 4291, IP Version 6 Addressing Architecture. RFC 3848, ESMTP and LMTP Transmission Types Registration. Note that it is possible to rephrase RFC 5321bis to avoid this normative reference and the WG will consider doing that.

The YAM WG requests feedback from the IESG on this decision. In particular: Does the IESG believe the proposed changes are suitable during a move from Draft to Full Standard? Excluding the previous proposed changes and expected IESG support for technically substantive IETF last call feedback, does the IESG believe any additional changes are critical to advance this document from draft to full standard? If so, please provide sufficient information so the WG can address these issues prior to IETF last call or determine that the document is inappropriate for the YAM WG to process at this time. Does the IESG consider the downward references acceptable for a full standard? If not, please cite which specific downward reference or references are problematic and why so the WG can address these issues prior to IETF last call or determine the document is inappropriate for the YAM WG to process at this time.

This document contains no IANA actions.

This document requests IESG feedback and does not raise any security concerns. Security considerations for RFC 5321 have been taken into account during the preliminary evaluation and appear in either Section 2.4 or Section 2.5 of this document.

This document was prepared from a template supplied by Subramanian Moonesamy. Some of the information provided in this document, but not provided in the RFC 1652 evaluation (http://www.ietf.org/id/draft-ietf-yam-rfc1652bis-pre-evaluation-00.txt), was inspired by brief discussions with Pasi Eronen and Subramanian Moonesamy during IETF 76.

&RFC5321; &RFC0821; &RFC1869; &RFC2821;

Added classes of changes for "errata" and "clarifications". Included YAM issue tracker numbers in the lists of possible changes.

Added Security Considerations and Examples to the "no change" list in . Identified RFC 821 as a specific reference to be moved from Normative to Informative. Add blanket placeholder for changes due to small editorial errors.

What follows are abbreviated details of the errata and tracker issues at the time of this writing, along with URLs to the actual entries. They are provided here to make it easier for IESG members -- and others -- to review them. If your browser does not automatically turn URLs into clickable links, copy/paste should still be convenient. In section 3.8, client should treat a closed connection as a 451 response, not as 421 (current). http://www.rfc-editor.org/errata_search.php?rfc=5321 The working group will consider this item. Discussion so far leans toward not making the change. In section 4.4, missing repeat in grammar for Additional-Registered-Clauses. http://www.rfc-editor.org/errata_search.php?rfc=5321 This item has been accepted, and the working group will make a change for it. In section 4.1.1.5, text specifying server behaviour on a closed connection is misplaced, and should be in section 4.1.1.10 or section 3.8. http://www.rfc-editor.org/errata_search.php?rfc=5321 The working group will consider this item. In section 6.1, reword "next subsection" to specify the section number, for clarity. http://trac.tools.ietf.org/wg/yam/trac/ticket/5 This item suggests an editorial change, and the working group will consider it. In section 4.4, there is extraneous text that should be removed or corrected (probably a paste error). http://trac.tools.ietf.org/wg/yam/trac/ticket/6 This item documents an editorial error, and the working group will make a change for it. In section 2.2.2, add a bullet saying "Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port." http://trac.tools.ietf.org/wg/yam/trac/ticket/7 The working group will consider this item. In section 4.1.1.3, remove text about source routes and move text about failed recipients here. http://trac.tools.ietf.org/wg/yam/trac/ticket/8 The working group will consider this item. In section 3.9.2, there is extraneous text that should be removed or corrected (probably a paste error). http://trac.tools.ietf.org/wg/yam/trac/ticket/9 This item documents an editorial error, and the working group will make a change for it. In section 3.9, add a subsection for "Backup MX" or "Plain forwarding". http://trac.tools.ietf.org/wg/yam/trac/ticket/10 The working group will consider this item. In section 3.1, a server can offer two greeting codes to a new connection: 220 or 554. Clarify the semantics of the 554 code. http://trac.tools.ietf.org/wg/yam/trac/ticket/11 The working group will consider this item. In examples, explicitly state that the examples will not be changed to use RFC 2606 domain names (such as example.com). http://trac.tools.ietf.org/wg/yam/trac/ticket/12 This item suggests an editorial change, and the working group will consider it. 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.