ietf
[Top] [All Lists]

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

2005-06-21 08:25:47
On Mon June 20 2005 21:40, Frank Ellermann wrote:

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.

Credit goes to Henrik Levkowetz' idnits program.

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

Heavens to Betsy, a whole floppy disk's worth of space :-).
It gives advice on writing comprehensible text (slides 42 through 54
are pertinent to the draft under discussion) among other things.

   o Too much text is ambiguous or vague

Statements like this are vague and therefore almost useless.

That's in a summary and is supported by detailed comments on specific
draft text which is ambiguous and/or vague.

[X] incompatible with the Internet Architecture (RFC 1958).

This "exponential-growth-info" is no standard of any kind,
please remove [R21] from your list.

It is unclear what you're referring to; specific sections of RFC 1958
were referenced.
 
[X] incompatible with one or more approved Internet
specifications

Care to name one or more specifications ?

Aside from RFC 1958, the review specifically mentioned issues related
to RFCs 2821, 2476, BCP 14, and security multiparts (not referenced by
RFC number, which is 1847).
 
[X] uses non-standard, inconsistent, or poorly-defined
terminology

Which "standard terminology" are you talking about ?

Several cases were specifically mentioned (e.g. "RCPT-TO address"
vs. RCPT TO path (no hyphen and "path" as used in RFCs 821, 2821)).
 
[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/

E.g. the conflict between 2476 et seq "MAY choose to use port 25" vs.
draft under discussion "MUST support the SUBMISSION port".  There are
of course other issues as listed in the review.
 
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.

No, while 2476 permits use of port 25 for an MSA, it does not specify
that use of port 25 automatically changes an MTA into an MSA.  MTA
transfer (other than gateways) precludes message modification; an
MSA is explicitly permitted by 2476 to modify message content without
notice to or approval of the client or author, and the draft's "treat
as submission" appears to encourage such unauthorized modification *by
MTAs*.
 
And as far as I can tell it this _is_ current practice.

Unauthorized message modification may indeed be current practice in
*some* places, but it's not *best* current practice, and in any event
although the abbreviation "BCP" stands for best current practice, the
BCP series of RFCs has specific uses as specified in BCP 9 and as
paraphrased in the review; the draft under discussion fails to meet
several of the requirements for BCP as noted in the review (and by
others in IETF discussion list comments).

o The same draft section refers to an "inbox", which
is not defined.

Actually "inbox" is defined in the next statement,

I see no *definition*.  Nothing resembling one.

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.

The underlying problem may be the lack of definition of an MDA.  As
far as I'm concerned, aliasing, forwarding, and list expansion take
place at an MDA, when the mailbox local-part is interpreted.  Such
interpretation is a delivery operation rather than a transport operation
as it involves changes to the SMTP envelope.  That the same message
(RFC 2822 sect. 3.6.4) is again transported as a result of delivery
to a mailbox simply means that the delivery isn't "final" (and in
practice this may happen via a distributed mechanism such as a Sieve
script, such that other mail system components cannot determine whether
or not delivery is "final").
 
"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.

See above and RFC 3028 (esp. sect. 4.3).  Also, think about the word
"gateway" for a moment or two.
 
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.

RFC 821 refers to "sender-SMTP" and to "the sender" and "the sender
mailbox", but provides no definition.  Use is not sufficiently
consistent to infer a definition; e.g. "the sender of the HELP command"
appears to refer to an SMTP client implementation (maybe "sender-SMTP"),
but a client certainly need not have a "sender mailbox".

RFC 1869 does not contain the word "sender" at all, and RFC 974 uses
the word exactly once, not as a definition.

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

The draft doesn't say what is being used (IP address? HELO/EHLO domain?
MAIL FROM path? message header field content? something else?), and
because some of those have been attempted to be used in inappropriate
circumstances, causing harm to the Internet, a vague blanket statement
such as in the draft under discussion is unsuitable as BCP or as a
Standards Track RFC precisely because it encompasses those harmful
practices.  The draft needs to be specific about precisely what may
and may not be used as a basis for authentication/authorization/validation,
of what/who, by what/whom, under which circumstances, and for what
specific purposes.  In addition, at least something needs to be said
about some specific methods which have known limitations or flaws.

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.

That's not what the draft says.  Nor is it at all clear that that is
the intent.  Indeed, the draft never once mentions "bounce" or the
more precise "notification".
 
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.

None of webmail, POP3, nor IMAP involve delivery; they are either "pull"
or "access" mechanisms associated with a message store of some sort.
ETRN is specifically prohibited by RFC 2476 et seq.   "ATRN" is only
mentioned in RFC 2645, which has been stuch at Proposed Standard for
six years, presumably because there aren't two implementations.  UUCP
is a low-level transport mechanism which is incapable of "to-MUA
delivery"; it sends files that may be saved to a message store.

Maybe "mailbox-by-MUA access" ?

The (convoluted and vague) text appears to be discussing MDAs, not
recipient MUAs.  I see no reason to mention recipient MUAs at all.
 
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,

As noted above, that's a problem because some of the "whatever" is
harmful.

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

No definition at all.
 
undefined term "submitting entity"

2476(bis) defines MSA and MUA, it must be the latter
in this case.

So is it a person, a piece of software, a host, an IP address, or
what?

That bullet point uses a BCP 14 imperative keyword

Yes, it's simply the 2476(bis) 4.3 MUST, see above.

Where's the justification for an imperative?
 
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.

It's not at all clear (specific 2476 et seq issues were discussed on
the IETF discussion list several months ago), and the draft under
current discussion is unclear about what "treat as submission" entails
(as noted by several reviewers).
 
The MDA oddity again.  The idea is simply "reject instead of
accept and later bounce",

That's your interpretation, not anything explicitly stated in the
document under discussion.   For Standards Track and BCP documents, we
need a clear specification, not something that will be interpreted in
dozens of different, incompatible, non-interoperable ways.

* Bizarre misuse of punctuation.

Spelling flames were already lame when I was much younger. :-(

The comment has nothing to do with spelling. 

(draft-under-discussion punctuation mode on)
If you, think, that adding random, commas, improves readability, you,
are mistaken.  It obfuscates, the meaning.
(bizarre punctuation mode off)

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.

The text can offer whatever its authors like.  The reality is that
many service providers do not provide MSAs, some that do choose to
use port 25 (as explicitly permitted by RFC 2476 et seq.), and that
combinations of requirements in the draft will cause serious damage
to the Internet unless a phased roll-in is used.

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

No. No matter what, there is an open window that an attacker can
exploit.  Also, basic POP3 uses plaintext USER and PASS commands;
use of that with SMTP-after-POP gives an attacker access to not
only SMTP, but to POP as well.
 
Removing features instead of doing it right or fixing them
is a stupid strategy.

Opening a window for exploit by attackers is a stupid strategy.

My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

std-index also says RFC 974.  std-index and rfc-index both say 821 et al.
are obsoleted by 2821, and 2821 itself says so.
 
(draft-rfc-editor-rfc2223bis-08.txt), July 2004.

Expired.

"Active" and "IESG Evaluation" according to the official Internet-Drafts
Database.  Your source?

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

True, but the draft's security considerations section is unacceptable,
and as it needs a rewrite, the authors should consult the appropriate
guidelines (BCP 72) and use standard terminology (FYI 36).  They can
of course ignore both, at the risk of having to rewrite yet again.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf