On Mon May 9 2005 19:33, Frank Ellermann wrote:
Bruce Lilly wrote:
Review of draft-kucherawy-sender-auth-header-02 by B. Lilly
Is your review tool also available as Web form ?
No. It's a set of troff/nroff macros and template that can be used
to generate a review document (or one could edit the text version).
Something
like proto-I-D in, death sentence (or whatever) out ?
No, it requires human review.
The "idnits webservice" (and related tools like rfcdiff) does
not work from my POV, I get no output, only the "usage" page:
<http://ietf.levkowetz.com/tools/idnits/idnits.pyht>
I just run idnits locally.
[X] ABNF [R4.RFC2234]
Somewhat beside the point, but this draft doesn't contain the
string "2234" or "ABNF".
It should, since it uses ABNF. Since one needs to understand
ABNF and its core rules to understand the draft ABNF (well, maybe
if the draft ABNF weren't so badly broken), it should be a
normative reference.
And if you check it anyway Scott H.
wants us to use the new 2234bis in the References.
A normative reference would hold up publication, as the 2234
successor isn't yet a published RFC.
20:0: error: Empty rule
22:0: error: Empty rule
Clearly, the "ABNF" is badly broken.
That's not helpful, so how should we reference terms defined
elsewhere ?
a) use a term defined elsewhere, including the source as a normative
reference.
or
b) write the necessary ABNF. It's not rocket science.
Note that according to the IETF "I-D Checklist"
http://www.ietf.org/ID-Checklist.html
"All ABNF must be checked". Foisting unchecked broken "ABNF" on
reviewers is a waste of time.
[X] None of the above.
Is that your personal opinion or idnits output ?
My opinion, based on what I see (my guess is that the concept is so
incompatible with the Internet Architecture and the reality of SMTP
and the message format that it should be withdrawn; but I stopped
short of saying so in case there's some merit lurking somewhere
behind the broken ABNF and formatting).
[X] missing or inadequate IANA considerations
= missing 3864 header registration form
at least. Probably also keyword registries. Possibly some discussion
of private-use/experimental keywords and non-registration of same.
[X] incompatible with the Internet Architecture
If that's American humour please add an I18N version.
Not humor, see the specific references to RFC 1958, end-to-end issues,
and lack of transitive trust.
Trust needs to be end-to-end.
No. If you can partition the net into "ours" and "not-ours",
and find an imaginary border between these partitions along the
lines of "our MX", then you can reduce this admittedly simple
check to the hop from the last "not ours" to the first "ours"
MTA, The concept is known as MX.
Provides no useful information; "it came from somewhere". If all
received mail is local '"ours"' (and header content is trusted), then
any spam is a purely local problem. Conversely w/o an end-to-end
mechanism, all one can say about non-local content is that it's
not local '"not-ours"'.
there exist domain names which have no corresponding IP
addresses.
So what ?
So the domain name in an SMTP HELO or ESMTP EHLO might not
correspond to the IP address of the SMTP client. Nothing
suitable for authentication there. Ditto for the domain
part of reverse paths.
The last MTA used on the "not ours" side has an IP.
So what? "it came from somewhere". No unsigned content from there
(in particular, any plaintext assertions of prior authentication)
is trustworthy.
SMTP transfer does not alter content except for addition of
time-stamp fields (a.k.a. Received fields), and (at "final"
delivery) a Return-Path field.
Obviously this draft proposes a new trace header field.
No, it's more serious than that. The draft proposes *deletion* of
message header content, which does not now happen (other than at
gateways). Worse, it leaves such deletion optional (MAY), making
it unpredictable whether or not such content might make it through
transport [requiring deletion would break backwards compatibility
with the entire installed SMTP base, so I suspect that there's no
way to salvage this proposal].
modification of message header content in transit.
In other words it adds a header field, but does not modify any
existing header field.
No, see above.
[X] [R57.Errata]
That's a dubious source, I've tested it two times, and so far
nothing happened (after an inquiry I got the confirmation that
they got it for the first).
There exist errata for many of the documents suggested for consultation
(e.g. 2234).
Try to make these reviews shorter, e.g. remove anything that's
clearly not applicable.
Noted.
You managed to reference your own I-D,
therefore you could do the same with 2234bis or taobis.
Most of the references are approved BCP, FYI, STD or RFCs. Mere drafts
(e.g. "2234bis") are less desirable where there is a suitable stable
reference.