Re: Authentication-Results: header draft

Frank Ellermann wrote:
>
> In your table you limit spf2.0/mfrom to smtp.from.  I think you
> also need smtp.helo just as for v=spf1, because RFC 4406 states
> that spf2.mfrom is the "mfrom" defined in RFC 4408.
>   
Added.

> I think you could remove the "smpt.from" line from senderid, or
> add smtp.helo just in case, if implementations treat it like
> v=spf1.  
>   
Added smtp.helo.
> Another nit, what's the point of "smtp.helo" vs. "smtp.ehlo"
> in your table ?  I think it muddies the waters for MUAs trying
> to make sense of it.
>   
Removed smtp.ehlo, and modified the value to cover both the HELO and the 
EHLO case.

> Third nit, please update RFC 2554 (now 4954).  What you have
> as [IANA-HEADERS] RFC 2434 should be RFC 3864 and normative.
>   

Fixed.

> The proposed 'iprev' authentication is apparently the same as
> "v=spf1 ptr -all" minus the processing limits for PTR checks
> in RFC 4408.  One "IETF certified troll" will whine, you're
> in deep shit with this idea.  You should provide a reference
> to I-D.ietf-dnsop-reverse-mapping-considerations, and maybe
> acknowledge April Lorenzen's prior art "VarA".
>   
>   
>> Hoping to hand it off to our IETF AD soon
>>     
>
> IMO (s)he needs a fair warning about this 'iprev' beast.  I
> like it, but better copy some "security considerations" from
> RFC 4408 and the reverse mapping I-D.
>   

OK, I'll look into this stuff.
> In section 2.2 you forgot the terminating CRLF for <header>.
>   

Added.

> IMO <version> for a header field is hopeless, besides you
> can't have two different unrelated <version> definitions in
> the ABNF.  Just kill the first (used in <header>).  
>   
I don't follow.  There can't be later versions of the 
Authentication-Results: header specification that might require some 
means of disambiguation?

> The idea to allow [CFWS] before and after "." in the
> <propspec> is outright horrible, please get rid of it.
>   
Why is it horrible?  Spaces and wrapping have no semantic importance so 
you could crush the entire decommented header down by removing all 
whitespace of any kind and still be able to use the value of the header 
field.

> The <mailbox> is likely the <Mailbox> in RFC 2821, not the
> <mailbox> in RFC 2822, you'd get a parser problem with the
> latter.   Maybe you mean 2822 <addr-spec>, in both cases
> add the damned [CFWS] before and after the alternative:
>
>   value = [CFWS] ( token / addr-spec ) [CFWS]
>
> Better check which 2822 obs-cenities I've lost by going
> from <mailbox> to <addr-spec>, but I think you don't need
> <obs-angle-addr> with <obs-route>.  But maybe you need an
> empty path, I'm not sure where that is in RFC 2822.
>
>   
<addr-spec> is what I'm looking for there.  I can switch to that one.  I 
don't see any productions that I don't want in that case.
> Shouldn't the header field be a *trace* header field ?
> I don't see this at the moment in your I-D, please add it
> if it's missing.
>   

Section 4.1 already says it SHOULD be treated as a trace header field.

> Example 3:  Should spf=pass [email protected]
> actually be spf=pass [email protected] ?  Ditto
> in example 4+5.  It's rather odd that the example 4 border
> MTA bothers to check spf and sender-id after an auth=pass,
> ditto in example 5.  I think you'd better add an example
> for auth=pass where that's added by the MSA.
>  
>   
Why would the MSA add that for outbound mail?