Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt

[Bruce Lilly <[e-mail]>]

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.