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@xxxxxxxx or ietf@xxxxxxxx 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@xxxxxxxx). 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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf