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.5086@xxxxxxxxxxxxxxxxx>. 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.624@xxxxxxxxxxxxxxxxx> > [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 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf