Bruce Lilly wrote:
> Credit goes to Henrik Levkowetz' idnits program.
ACK. [After some debugging with his help I found a
way to use the Web service, it works fine with Lynx]
[1.5 MB PDF]
> Heavens to Betsy, a whole floppy disk's worth of space :-).
Won't impress my nice USR Courier and AcroReader 3.0 -
I'll wait until you quote it again for an I-D where I
promised that it would survive your review.
>>> 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.
Maybe swap "specific examples" and "comments". Or
replace "comments" by "summary". Or add "specific
examples shown below" to the "serious defects".
I simply tried to read it top down (jumping from
RfC 2476bis to the I-D and back in another window).
>> please remove [R21] from your list.
> It is unclear what you're referring to; specific
> sections of RFC 1958 were referenced.
This "incompatible with the Internet architecture",
your death sentence. You could as well quote KISS
(3.5), the principle of constant change (1), build
on the work of others (3.2), running code (3.14),
or don't wait for perfect solutions (3.7). In some
way or another all relevant for hutzler-spamops-04.
> security multiparts (not referenced by RFC number,
> which is 1847
You never stop to amaze me with RfC numbers I have
never before heard of... oh, that stuff, okay, now
where's that related to MSA and MDA considerations ?
All they have to decide is "is this a submission ?",
"if yes, when should I accept it ?", "is this for
a local user ?", and "if no, what should I do ?".
Not at all related to the DATA or a potential MIME
multipart/signed or multipart/encrypted body. Dave
is listed in the RfC 1847 credits, so he would know
if there's any problem. I certainly don't see it.
> e.g. "RCPT-TO address" vs. RCPT TO path (no hyphen
> and "path" as used in RFCs 821, 2821)
Okay, I'd interpret it as the address identifying the
mailbox in the forward path. Or as RfC 821 put it,
"the mailbox is an absolute address", "to emphasize
the distinction between an adress and a route".
So "RCPT-TO address" is a forward-path minus route,
what else should it be. The hyphen might be a typo.
[skipping some text where we probably disagree]
> The underlying problem may be the lack of definition
> of an MDA.
Point, 2476(bis) offers only MUA, MSA, and MTA. And
your concept makes sense, but not in conjunction with
some ideas in the draft.
> other mail system components cannot determine whether
> or not delivery is "final"
Then they have to assume that it is, and if something
beyond their control has its own ideas it's responsible
to get it right, e.g. a mailing list.
> See above and RFC 3028 (esp. sect. 4.3).
MUA-stuff, a MUA claiming to be no MUA is still a MUA.
> think about the word "gateway" for a moment or two.
Yes, MUAs claiming to be a gateway are often a PITA.
[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?
It's something with an IP connecting to port 25 or 587
saying HELO or EHLO. And if that's you using telnet
it's perfectly okay.
>> Yes, it's simply the 2476(bis) 4.3 MUST, see above.
> Where's the justification for an imperative?
In section 4.3 of 2476(bis), without authentication it
would be an open relay and no MSA. Normally I'd hate
"green MUST be a colour" statements, maybe there's an
odd weak point in the draft and 2476(bis).
> (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)
Only typos, nothing bizarre about it from my POV.
[SMTP-afer-POP]
>> 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
Now wait, my next statement belonged to this part:
| If it's coupled with 2476(bis) "enforced submission rights".
> there is an open window that an attacker can exploit.
He had to get the "enabled" IP and had to know the MAIL FROM.
> Also, basic POP3 uses plaintext USER and PASS commands;
When I said _can_ be better than AUTH "LOGIN" it was of course
not about USER PASS. But APOP can be already slightly better.
>> 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.
RfC 2821 is a "proposed standard", and for some of the more
obscure RfC 821 features like SAML or SOML it says "read 821".
Besides RfC 821 had a logical concept of MAIL FROM, at least
in theory, where RfC 2821 offers only a "we broke it, sorry".
[rfc2223bis-08.txt]
> "Active" and "IESG Evaluation" according to the official
> Internet-Drafts Database. Your source?
A local copy of the draft, line 11: "Expires: February 2005".
Bye, Frank
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf