Bruce Lilly wrote:
Checking nits according to
http://www.ietf.org/ID-Checklist.html:
[...]
Okay, you found nits above the typo level, draft -04
has to be fixed before it can be "last called" again.
[R5.editor62] may be useful
An 1.5 MB PDF, so that is most probably irrelevant to
create plain text 20 KB Internet Drafts with 10 pages.
Remove {R5] from your references please, or at the
very minimum add a warning about its size.
the status as defined in [R6.BCP9] should be:
Let's assume that we know the list of possibilities,
and just state what you think...
[X] Informational
...something's wrong if your review is longer than
the reviewed source.
o Too much text is ambiguous or vague
Statements like this are vague and therefore almost useless.
[X] incompatible with the Internet Architecture (RFC 1958).
This "exponential-growth-info" is no standard of any kind,
please remove [R21] from your list.
[X] incompatible with one or more approved Internet
specifications
Care to name one or more specifications ?
[X] uses non-standard, inconsistent, or poorly-defined
terminology
Which "standard terminology" are you talking about ?
The draft references exactly three normative texts,
you might get some more recursively, so if there's a
conflict please _show_ it. I can't check vague claims
based on what you might consider as "standard".
[X] not backwards compatible with widely deployed,
standards-conforming infrastructure
If there's a problem with 2476bis I didn't see it,
except from the obvious s/2476/gellens-submit-02/
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.
As defined in 2476bis that's a special case of an MSA:
| A site MAY choose to use port 25 for message
| submission, by designating some hosts to be MSAs and
| others to be MTAs.
And as far as I can tell it this _is_ current practice.
o The same draft section refers to an "inbox", which
is not defined.
Actually "inbox" is defined in the next statement, but I
agree that this definition is somewhat beside the point
in a piece of text about MDAs.
o In some cases, an MDA may continue transport of a
message based on per-mailbox forwarding, aliasing, or
list expansion operations.
If it's no final delivery it's no MDA.
"It is sometimes difficult for an SMTP server to
determine whether or not it is making final delivery".
Difficult or not, it will decide this, otherwise it's a
Schroedinger-MTA or science fiction.
Draft section 3 refers to "sender", which is not
defined.
It's defined in STD 10, everybody knows what it is.
And in the context of chapter 3 it's the submitter.
it is unclear what is meant by "sender authentication".
The complete chapter 3 explains what it's supposed to
be for an MSA, "submitter authentication".
Section 3 also refers to "the final MTA-to-MDA
transmission", ignoring the caveat in [R10.RFC2821].
"551 user not local" is an old and simple concept, not
the stuff to write a new BCP about. The idea in the
draft is to reject mails to unknown local users a.s.a,p.
instead of first accept and later bounce such crap.
And that's indeed "best current practice" everywhere.
It also refers to "MDA-to-MUA delivery"
What term do you propose to catch all these wild and
wonderful ways to get mail from an MDA to the user ?
This "MUA" could be a Webmail interface, it could be
IMAP, POP3, some ETRN or ATRN trick, UUCP, what else.
Maybe "mailbox-by-MUA access" ?
The same draft section refers to a "relationship
between client and server" but does not specify
what the nature of the supposed relationship is
This "supposed relationship" can be whatever the site
wants it to be, the text simply states "MUST perform
authentication during mail submission, based on an
existing relationship with the submitting entity."
This MUST directly reflects the MUST in chapter 4.3
of 2476 or 2476bis, it's nothing new.
"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].
Yes, something might be odd here, because if it's
not effecting final delivery it's no MDA, and that
might be a kind of circular definition.
undefined term "submitting entity"
2476(bis) defines MSA and MUA, it must be the latter
in this case. I'm less sure about "formail" forms,
that could be a special case of "submitting entity".
That bullet point uses a BCP 14 imperative keyword
Yes, it's simply the 2476(bis) 4.3 MUST, see above.
[chapter 3, 3rd bullet]
A BCP 14 imperative keyword is used with no rationale
for such an imperative.
That's about open relays. Treat mails from unknown
strangers to unknown strangers as submission. In fact
this MUST is odd. An open relay is no MSA, saying that
it MUST be an MSA (and reject the mail) is pointless,
the meaning is unclear; does this refer to an implied
permission to mangle message content?
Submit / MSA is defined in 2476(bis) and perfectly clear.
The terms "authorization" and "validation" are used but
are undefined by the draft
The draft is no _reprint_ of gellens-submit-02 (2476bis),
it's a BCP _based_ on 2476(bis).
no specific external reference is supplied
Okay, maybe they should first submit it to the SPF-community,
we're training to get I-Ds in shape for your famous reviews,
see
<http://mid.gmane.org/42B4624D(_dot_)5086(_at_)xyzzy(_dot_)claranet(_dot_)de>.
So what's it, missing informative RfC 2828 reference, right ?
The last bullet point in draft section 3 also uses undefined
terms, BCP 14 imperative keywords with no justification or
rationale
The MDA oddity again. The idea is simply "reject instead of
accept and later bounce", but that's a job for the MX, not
for the MDA.
I skip your chapter 4 comments because it's getting too long.
As far as blocking port 25 is concerned I tend to agree with
you, but not to the point of a "MUST NOT".
For obvious reasons there's nothing wrong with blocking known
abuse. And the draft just says "no recommendation".
* Bizarre misuse of punctuation.
Spelling flames were already lame when I was much younger. :-(
The figure and text also presume the availability of a
suitable MSA using port 587; both presumptions do not
conform to universal current practice.
It's the point of this text to offer MSAs for roaming users
even under "bizarre conditions" like a blocked port 25.
Draft section 5 mentions POP-before-SMTP, which has known
security defects
Depends on how you do it, it can be perfectly sane and even
better than the non-standard SMTP AUTH "LOGIN" scheme, or
PLAIN without TLS (not allowed, but not everybody knows it).
If it's coupled with 2476(bis) "enforced submission rights".
ideally it would be prohibited
Removing features instead of doing it right or fixing them
is a stupid strategy. This is an Internet Draft and not a
"security update" from whose-name-must-not-be-named.
The normative references include:
* RFC 821, which has been obsoleted according to the
rfc-index and std-index
My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.
* RFC 2476, which has Proposed Standard status
RfC 2476bis is AFAIK approved as Draft Standard. See also:
<http://mid.gmane.org/4285B85F(_dot_)624(_at_)xyzzy(_dot_)claranet(_dot_)de>
[R3.Instruct]
[...]
(draft-rfc-editor-rfc2223bis-08.txt), July 2004.
Expired.
[R12.FYI36]
[...]
RFC 2828, May 2000.
Oops, there it is. Note that 2476bis also doesn't use it,
nothing forces authors to use a glossary they don't like.
Bye, Frank