ietf-smtp
[Top] [All Lists]

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

2005-06-20 10:46:58

On Fri June 3 2005 09:47, The IESG wrote:
The IESG has received a request from an individual submitter to consider the 
following document:

- 'Email Submission Between Independent Networks '
   <draft-hutzler-spamops-04.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by 
2005-07-01.

Comments:


Internet-Drafts and RFCs are required to meet certain criteria:
[R1.Checklist] (see also references in that document), [R2.ID],
[R3.Instruct].  These can be checked by using the "idnits" tool:
[R4.idnits].  That tool noted the following regarding the document:

  idnits 1.73 (17 Jun 2005)

  draft-hutzler-spamops-04.txt:


    Checking nits according to
    http://www.ietf.org/ID-Checklist.html:
    * The document seems to lack an IANA Considerations section.
      Checking conformance with RFC 3978/3979 boilerplate...
    * The document seems to lack an RFC 3978 Section 5.1 IPR
      Disclosure Acknowledgement.

    (Expected a match on the following text:
      "By submitting this Internet-Draft, each author represents that
      any applicable patent or other IPR claims of which he or she is
      aware have been or will be disclosed, and any of which he or she
      becomes aware will be disclosed, in accordance with Section 6 of
      BCP 79.")

      (The document uses RFC 3667 boilerplate or RFC 3978-like
      boilerplate instead of verbatim RFC 3978 boilerplate.  After 6
      May 2005, submission of drafts without verbatim RFC 3978
      boilerplate is not accepted.)

    Checking nits according to
    http://www.ietf.org/ietf/1id-guidelines.txt:
      Nothing found here (but these checks do not cover all of
      1id-guidelines.txt yet).

    Miscellaneous warnings:
      None.

The wording of the document is poor.  [R5.editor62] may be useful.  Many
terms (details below) are undefined, poorly defined, or inconsistently
defined.  Many "sentences" suffer from odd placement of punctuation,
particularly commas, which make parsing those "sentences" impossible.

The (intended) status of the document is:

   [ ] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [X] Best Current Practice

   However, the status as defined in [R6.BCP9] should be:

   [ ] Experimental (typically denotes a specification that is part of
       some research or development effort, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [X] Informational (published for the general information of the
       Internet community, does not represent an Internet community
       consensus or recommendation, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
       choices, is believed to be well-understood, has received
       significant community review, appears to enjoy enough community
       interest to be considered valuable, has no known technical
       omissions)

   [ ] Draft Standard (at least two independent and fully interoperable
       implementations from different code bases have been developed,
       sufficient successful operational experience has been obtained,
       unused options and features have been removed, well-understood,
       known to be quite stable both in its semantics and as a basis for
       developing an implementation, must have been Proposed Standard
       for at least six months)

   [ ] Internet Standard (significant implementation and successful
       operational experience has been obtained, 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, must have been Draft Standard for at
       least four months)

   [ ] Historic (A specification that has been superseded by a more
       recent specification or is for any other reason considered to be
       obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
       results of community deliberations, subject to the same basic set
       of procedures as standards track documents, the community's best
       current thinking on a statement of principle or on what is
       believed to be the best way to perform some operations or IETF
       process function, common guidelines for policies and operations
       which are generally different in scope and style from protocol
       standards, not well suited to the phased roll-in nature of the
       three stage standards track and instead generally only make sense
       for full and immediate instantiation)

   [ ] None of the above (see discussion)

BCP is inappropriate for the document in its current state because:

   o Too much text is ambiguous or vague

   o Specified requirements conflict with widespread current practice
     unsuitable for immediate instantiation

   o A phased roll-in would be more appropriate considering conflicts
     with current practice

   o Despite hyperbole to the contrary, the document has not been
     subject to adequate community deliberations

The document suffers from the following serious defects:

   [X] missing IANA considerations

   [X] inadequate security considerations

   [X] incompatible with the Internet Architecture (RFC 1958).  In
       particular, authentication specified is not end-to-end (RFC 1958
       section 2.3), terminology is unclear and inconsistent (section
       3.13), and security has not been adequately addressed (section 6
       and subsections).

   [X] incompatible with one or more approved Internet specifications

   [X] uses non-standard, inconsistent, or poorly-defined terminology
       which may lead to confusion, misinterpretation, and loss of
       interoperability

   [X] not backwards compatible with widely deployed,
       standards-conforming infrastructure

   [X] [R7.BCP14] is referenced, but keywords are not used, or are used
       inappropriately

Specific examples of the aforementioned issues include:

   o Draft section 2 states that an MSA is always used for "submission",
     but that is not universal current practice.  Many service providers
     support only MTAs, and messages may be initially transported by an
     MUA sending to an MTA.

   o The same draft section refers to an "inbox", which is not defined.
     It is unclear whether the term is intended to be a "mailbox", as in
     "A mailbox receives mail" [R8.RFC822], [R9.RFC2822].

   o A statement is made in the same draft section that an MDA delivers
     to the undefined "inbox" which is part of an MUA; however in
     reality, an MDA may deliver to a message store which an MUA
     accesses via a separate "pull" mechanism (e.g. file access, POP,
     IMAP).

   o In some cases, an MDA may continue transport of a message based on
     per-mailbox forwarding, aliasing, or list expansion operations.  As
     noted in [R10.RFC2821], "It is sometimes difficult for an SMTP
     server to determine whether or not it is making final delivery".

   o Draft section 3 refers to "sender", which is not defined.  It is
     unclear whether this term refers to an SMTP client or to some user
     or to a mailbox ([R9.RFC2822]) or to some other entity (or indeed
     if the term is inconsistently used).  With no definition of
     "sender", it is unclear what is meant by "sender authentication".

   o Section 3 also refers to "the final MTA-to-MDA transmission",
     ignoring the caveat in [R10.RFC2821].

   o It also refers to "MDA-to-MUA delivery" contrary to actual
     operation (use of access protocols by MUAs as noted above).

   o The same draft section refers to a "relationship between client and
     server" but does not specify what the nature of the supposed
     relationship is; it is possible that what is meant is that there
     may be a contractual agreement between a user responsible for
     initiating message transfer (but that is not a "client" as that
     term is used in relevant approved Internet specifications relating
     to the mail system) and the administrative entity operating an MSA
     (but that administrative entity is not itself a "server" as that
     term is used).

   o The same section claims that "the MDA can determine that it will be
     effecting final delivery" in direct contradiction to the statement
     quoted above from the approved Internet specification contained in
     [R10.RFC2821].

   o While the qualifying word "typically" appears in part of the
     compound statement discussed above, the section goes on to imply
     that all "MSAs and MDAs can take advantage of having prior
     relationships", whereas that is only true for a subset of cases.
     In this case as well as the example noted above, it is likely that
     the "relationship" is not between MSA/MDA and "users", but is a
     contractual arrangement between some user and some administrative
     entity in the one case, and is a configuration item linking an
     MDA's operation to a mailbox (as defined in [R9.RFC2822]) in the
     other case.

   o The first bullet point at the end of draft section 3 uses the
     undefined term "submitting entity".  It is unclear whether that
     term refers to an SMTP client host, to a particular piece of
     software running on some host, to a responsible human user, or to
     some other entity.

   o That bullet point uses a BCP 14 imperative keyword, but no
     rationale or justification is given corresponding to the
     restrictions on usage for such imperatives as specified in section
     6 of BCP 14.

   o That bullet point also refers to "all mail submission mechanisms",
     and a subsequent part of the draft makes a nebulous reference to
     treating ordinary transfer "as mail submission".  Earlier draft
     text refers to software which incorporates multiple functions.  It
     is unclear precisely whether these are meant to be included in
     "all", or if "all" is being used carelessly.

   o The second bullet point uses awkward wording which is at best
     extremely difficult to parse.  It should be reworded to remove
     ambiguities so as to prevent likely incompatible interpretations.
     Specifically:

      * See above re. bizarre use of punctuation.

      * The term "received from" is undefined.  Does this refer to an IP
        address?  Something else?

      * "local operational environment" is extraordinarily vague.  What
        is the term supposed to mean?  The only constructive comment
        that can be made about such an extremely vague and poorly worded
        statement in a document intended for Standards Track or BCP is
        that its presence precludes reaching consensus agreement to the
        intended meaning of the specification in the document (since the
        intent is not communicated sufficiently clearly).

      * It fails to account for the difficulty in determining when
        "final delivery" takes place, as noted in [R10.RFC2821].

   o The third bullet point at the end of draft section 3 has problems
     of a similar nature and number:

      * "coming from" is undefined.  The lack of a definition is
        compounded by the similarity to, but distinct difference from,
        the earlier undefined term "received from".  One wonders not
        only what is meant by each of those terms, but what distinction
        is being made by the use of subtly different terms.

      * Likewise, "operator's local environment" is undefined and is
        similar to but distinct from the earlier undefined term "local
        operational environment".  The same concerns as immediately
        above also apply to this pair of undefined terms.

      * A BCP 14 imperative keyword is used with no rationale for such
        an imperative.

      * reference is made to transfer "treated as mail submission", but
        the meaning is unclear; does this refer to an implied permission
        to mangle message content?  To something else; if so
        specifically what is included and what is excluded?

      * The terms "authorization" and "validation" are used but are
        undefined by the draft (and no specific external reference is
        supplied) in that context.

      * It uses the term "RCPT-TO address" in a manner which is
        self-inconsistent (vs. "RCPT TO address" in section 4), is
        inconsistent with approved internet specifications (
        [R11.RFC821] and [R10.RFC2821]), both of which associate a
        "path" (not "address") with the RCPT TO (not hyphenated)
        command, and conflicts with other standard use of the term
        "address" (e.g. IP address, [R9.RFC2822] "address" (mailbox or
        named group)).

   o The last bullet point in draft section 3 also uses undefined terms,
     BCP 14 imperative keywords with no justification or rationale, and
     conflicts with current practice:

      * "recipients" is undefined.

      * "arrangement" is nebulous

      * no rationale for "SHALL NOT"

      * Some mail system operators provide a "catch-all" mailbox; the
        bullet point could be construed as prohibiting that current
        practice.

      * "delivery" is vague, especially in light of [R10.RFC2821] and
        forwarding, aliasing, list expansion, and the noted difficulty
        in determining when final delivery takes place.

   o The first sentence of the first paragraph of draft section 4 has a
     conflict between the words "desiring" and "need"; clearly either
     one term is too weak or the other is too strong.  The remainder of
     the paragraph is extraordinarily vague, and it is difficult to see
     how either a need or desire for end-to-end privacy is related to
     the hop-by-hop transfer implied by the draft text.  End-to-end
     privacy can be obtained with security multiparts as used by S/MIME
     and PGP/MIME, and are unrelated to transfer (except to the extent
     that transfer:

      * must not corrupt content, invalidating digital signatures

      * requires an end-to-end privacy mechanism to ensure privacy (i.e.
        if a transport intermediary is able to defeat security, there is
        no privacy)

      ).

   o The draft text makes an extremely brief reference to blocking of
     the SMTP well-known port number (25).  It claims that it "can be
     problematic for some users", but that is incorrect and
     irresponsibly understates the scope of the problem.  Blocking port
     25 precludes use of the SMTP VRFY command to determine the validity
     of a mailbox (e.g. dcrocker(_at_)bbiw(_dot_)net).  With the ability to 
verify
     by a concise SMTP transaction blocked (N.B. none of RFC 2476, its
     draft successor, and/or the draft under discussion require support
     for VRFY in the "submission" protocol), it becomes necessary to
     transmit a full-blown message and hope for the best.  In the event
     of an invalid, expired, etc. mailbox, the typical result will be an
     additional delivery notification message which typically contains
     the entire original message plus transport markings plus plain text
     plus structured information regarding non-delivery, plus additional
     transport markings.  The resulting volume of (unnecessary if port
     25 is not blocked) traffic affects *all* users.  Port 25 blocking
     thus results in precisely the sort of situations for which use of
     BCP imperatives are intended, and the blocking and the harm which
     it causes should be proscribed by use of suitable BCP 14 text, e.g.
     "The well-known SMTP port MUST NOT be blocked".  It is
     irresponsible to misstate the scope of the problem caused by
     blocking ("some users") and to fail to address the problem by
     appropriate use of BCP 14 imperatives, especially as such
     imperatives are elsewhere used with no apparent justification.

   o Draft section 4 makes the (probably unintentionally) humorous claim
     that the draft document *uses* a particular TCP port.

   o The first bullet point at the end of draft section 4 is unclear
     because of:

      * Bizarre misuse of punctuation.

      * Unjustified use of BCP 14 imperative keywords (which conflicts
        with current practice).

      * The undefined term "support".  Does a server which always
        responds with a 421 greeting response code count as "support"?
        What about software that has a configurable option, but is
        operated with the option disabled?

      * The undefined term "local environment".

      * Direct conflict with approved Internet specifications RFC 2476
        and its draft successor, which both explicitly permit use  of
        the submission protocol on the well-known SMTP port (25).

   o The second bullet point in draft section 4:

      * Uses a BCP 14 imperative keyword with no rationale or
        justification

      * Does not define what or who is the object of "authentication",
        by what or whom, or on what basis or for what purpose.

      * Uses the term "RCPT TO address" in a manner which is
        self-inconsistent (vs. hyphenated "RCPT-TO address" in section
        3), is inconsistent with approved internet specifications
        ([R11.RFC821] and [R10.RFC2821]), both of which associate a
        "path" (not "address") with the RCPT TO command, and conflicts
        with other standard use of the term "address".

   o The third and last bullet points in draft section 4 presume that
     MSAs are in universal use, which is not currently true.  The last
     bullet point further presumes:

      * that there exists some MSA (as opposed to an MTA) operating on
        some host that can be used, and

      * that MUAs universally can be configured to use port 587, and

      * that somebody is able to perform the necessary configuration.

   o The figure in draft section 4 and the accompanying text refer to a
     "'home' MSA", which is nowhere defined.

   o The figure and text also presume the availability of a suitable MSA
     using port 587; both presumptions do not conform to universal
     current practice.

   o Draft section 5 conflates authentication and authorization.

   o Draft section 5 mentions POP-before-SMTP, which has known security
     defects and which therefore should not be encouraged; at minimum it
     should be strongly deprecated, ideally it would be prohibited with
     a corresponding BCP 14 imperative due to the security risks.

   o Draft section 5 fails to provide for authentication of an SMTP
     server to the connecting client, as discussed on the IETF
     discussion list regarding man-in-the-middle "evil twin" attacks.

   o In light of discussions on the IETF discussion list, the draft
     security considerations section is woefully inadequate.

   o The draft lacks the required IANA considerations section.

   o The normative references include:

      * RFC 821, which has been obsoleted according to the rfc-index and
        std-index

      * RFC 2476, which has Proposed Standard status

      * RFC 2821, which has Proposed Standard Status

      These may constitute improper downward references for a document
      intended as BCP.

   o BCP 14, a.k.a. RFC 2119, is improperly listed as an informative
     (rather than normative) reference.

   o Additional references may be required if external references are
     needed for terms which are presently undefined.

   o The Authors' Addresses section conflicts with the draft page one
     heading.

Please carefully review the references and resources indicated:

   [X] [R12.FYI36]

   [X] [R13.BCP22]

   [X] [R14.BCP26]

   [X] [R15.BCP61]

   [X] [R16.BCP72]

   [X] [R17.BCP97]

   [X] [R18.BCP104]

   [X] [R19.RFC1796]

   [X] [R20.RFC1925]

   [X] [R21.RFC1958]

   [X] [R22.RFC2223]

   [X] [R23.RFC3426]

   [X] [R24.RFC3439]

   [X] [R25.Errata]

The following applies to the document being reviewed:

   [X] The document needs substantial rework before serious review can
       take place.  In particular, substantive comment on any principles
       or practices which may have been intended is precluded at this
       time due to the extreme vagueness of the specification.  At least
       one additional broad community review cycle is desirable once the
       ambiguities, inconsistencies, etc. have been resolved.

References:

   [R1.Checklist] Wijnen, B., "Checklist for Internet-Drafts (IDs)
                  submitted for RFC publication", February 2005,
                  http://www.ietf.org/ID-Checklist.html

   [R2.ID]        Fenner, B., "Guidelines to Authors of
                  Internet-Drafts", March 2005,
                  ftp://ftp.ietf.org/ietf/1id-guidelines.txt

   [R3.Instruct]  Reynolds, J. and R. Braden, "Instructions to Request
                  for Comments (RFC) Authors"
                  (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

   [R4.idnits]    http://ietf.levkowetz.com/tools/idnits/

   [R5.editor62]  RFC Editor, "Tutorial Slides",
                  ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial62.pdf

   [R6.BCP9]      Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

   [R7.BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [R8.RFC822]    Crocker, D., "Standard for the format of ARPA Internet
                  text messages", STD 11, RFC 822, August 1982.

   [R9.RFC2822]   Resnick, P., "Internet Message Format", RFC 2822,
                  April 2001.

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

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

   [R12.FYI36]    Shirey, R., "Internet Security Glossary", RFC 2828,
                  May 2000.

   [R13.BCP22]    Scott, G., "Guide for Internet Standards Writers",
                  BCP 22, RFC 2360, June 1998.

   [R14.BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26,
                  RFC 2434, October 1998.

   [R15.BCP61]    Schiller, J., "Strong Security Requirements for
                  Internet Engineering Task Force Standard Protocols",
                  BCP 61, RFC 3365, August 2002.

   [R16.BCP72]    Rescorla, E. and B. Korver, "Guidelines for Writing
                  RFC Text on Security Considerations", BCP 72,
                  RFC 3552, July 2003.

   [R17.BCP97]    Bush, R. and T. Narten, "Clarifying when Standards
                  Track Documents may Refer Normatively to Documents at
                  a Lower Level", BCP 97, RFC 3967, December 2004.

   [R18.BCP104]   Klensin, J., "Terminology for Describing Internet
                  Connectivity", BCP 104, RFC 4084, May 2005.

   [R19.RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs
                  are Standards", RFC 1796, April 1995.

   [R20.RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
                  April 1996.

   [R21.RFC1958]  Carpenter, B., "Architectural Principles of the
                  Internet", RFC 1958, June 1996.

   [R22.RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC
                  Authors", RFC 2223, October 1997.

   [R23.RFC3426]  Floyd, S., "General Architectural and Policy
                  Considerations", RFC 3426, November 2002.

   [R24.RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
                  Guidelines and Philosophy", RFC 3439, December 2002.

   [R25.Errata]   RFC-Editor errata page,
                  http://www.rfc-editor.org/errata.html