[Search] [txt|html|xml|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05                                Informational
YAM Working Group                                             J. Klensin
Internet-Draft
Intended status: Informational                                  B. Leiba
Expires: November 5, 2010                            Huawei Technologies
                                                             May 4, 2010


Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP),
for advancement from Draft Standard to Full Standard by the YAM Working
                                 Group
             draft-ietf-yam-5321bis-smtp-pre-evaluation-05

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 5, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Klensin & Leiba         Expires November 5, 2010                [Page 1]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Note to RFC Editor . . . . . . . . . . . . . . . . . . . .  3
   2.  Preliminary Evaluation . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Document . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Time in Place  . . . . . . . . . . . . . . . . . . . . . .  3
     2.3.  Implementation and Operational Experience  . . . . . . . .  3
     2.4.  Proposed Changes . . . . . . . . . . . . . . . . . . . . .  4
     2.5.  Non-Changes  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.6.  Downward references  . . . . . . . . . . . . . . . . . . .  6
     2.7.  IESG Feedback  . . . . . . . . . . . . . . . . . . . . . .  6
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  7
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . .  7
     A.1.  Changes from version -01 to -02  . . . . . . . . . . . . .  8
     A.2.  Changes from version -00 to -01  . . . . . . . . . . . . .  8
   Appendix B.  Detailed Issues List  . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






















Klensin & Leiba         Expires November 5, 2010                [Page 2]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


1.  Introduction

   A preliminary evaluation has been made of Simple Mail Tranfer
   Protocol [RFC5321] 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.

1.1.  Note to RFC Editor

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


2.  Preliminary Evaluation

2.1.  Document

   Title:   Simple Mail Transfer Protocol

   Link:   http://tools.ietf.org/html/rfc5321

2.2.  Time in Place

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

   Published:   October 2008

2.3.  Implementation and Operational Experience

   RFC2026:   _ "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." _

   Confidence level:  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 1989).  The second was the introduction of a model for



Klensin & Leiba         Expires November 5, 2010                [Page 3]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


   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 [RFC2821] 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 [RFC0821] and RFC 1869
   [RFC1869] (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.

2.4.  Proposed Changes

   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.

   Terminology:  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.

   Metalanguage:  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.

   Normative References:  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.

   Existing Errata Reports:  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 Appendix B for details.



Klensin & Leiba         Expires November 5, 2010                [Page 4]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


   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.

   Clarifications:  The working group will attempt to address things
      that have been 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 Appendix B for details.  In no case will
      clarification changes be significant enough to violate "Non-
      Changes", Section 2.5.

   Updates to References:  Section 7.1 of RFC 5321 should have
      informational references to RFC 3207 (STARTTLS) and RFC 4954 (SMTP
      AUTH); they will be added in 5321bis.  RFC 3851 has been obsoleted
      by RFC 5751; that informational reference will be updated in
      5321bis.  Other obsolete references that may exist will be updated
      as appropriate.

2.5.  Non-Changes

   The YAM WG discussed and chose not to make the following changes:

   1.  Complete revision, rearrangement, or reformatting of metalanguage
       (see #2 above).

   2.  Any extensions that would violate the rules for Full Standard or
       otherwise require revisiting the approved interoperability report
       for RFC 5321.

   3.  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.




Klensin & Leiba         Expires November 5, 2010                [Page 5]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


   4.  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.

   5.  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.

2.6.  Downward references

   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.

2.7.  IESG Feedback

   The YAM WG requests feedback from the IESG on this decision.  In
   particular:

   o  Does the IESG believe the proposed changes are suitable during a
      move from Draft to Full Standard?

   o  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.

   o  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.



Klensin & Leiba         Expires November 5, 2010                [Page 6]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


3.  IANA Considerations

   This document contains no IANA actions.


4.  Security Considerations

   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.


5.  Acknowledgments

   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.


6.  References

6.1.  Normative References

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

6.2.  Informative References

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
              RFC 821, August 1982.

   [RFC1869]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
              November 1995.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.


Appendix A.  Change Log





Klensin & Leiba         Expires November 5, 2010                [Page 7]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


A.1.  Changes from version -01 to -02

   o  Added classes of changes for "errata" and "clarifications".

   o  Included YAM issue tracker numbers in the lists of possible
      changes.

A.2.  Changes from version -00 to -01

   o  Added Security Considerations and Examples to the "no change" list
      in Section 2.5.

   o  Identified RFC 821 as a specific reference to be moved from
      Normative to Informative.

   o  Add blanket placeholder for changes due to small editorial errors.


Appendix B.  Detailed Issues List

   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.

   Errata ID 1543:  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/doc/html/rfc5321
      The working group will consider this item.  Discussion so far
      leans toward not making the change.

   Errata ID 1683:  In section 4.4, missing repeat in grammar for
      Additional-Registered-Clauses.
      http://www.rfc-editor.org/errata_search.php/doc/html/rfc5321
      This item has been accepted, and the working group will make a
      change for it.

   Errata ID 1851:  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/doc/html/rfc5321
      The working group will consider this item.







Klensin & Leiba         Expires November 5, 2010                [Page 8]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


   Tracker Issue 5:  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.

   Tracker Issue 6:  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.

   Tracker Issue 7:  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.

   Tracker Issue 8:  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.

   Tracker Issue 9:  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.

   Tracker Issue 10:  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.

   Tracker Issue 11:  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.

   Tracker Issue 12:  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.





Klensin & Leiba         Expires November 5, 2010                [Page 9]


Internet-Draft           YAM 5321bis Evaluation                 May 2010


   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.


Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140
   USA

   Phone: +1 617 245 1457
   Email: john+ietf@jck.com


   Barry Leiba
   Huawei Technologies

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



























Klensin & Leiba         Expires November 5, 2010               [Page 10]