[mail-vet-discuss] Auth-Results issues? #2 headerspec

[Murray S. Kucherawy]

Tony Hansen wrote:
> I have a variety of problems with the "headerspec" value.
> 
> It's unclear how multiple methods are to be combined together into a
> single header; what happens with the "headerspec" value? If you wanted
> to put in an A-R header saying that the message passed CSV, SIDF, SPF
> and DKIM, how would those be combined?

You would have a separate A-R header for each thing that was evaluated.  For 
example, one would report all the results pertaining to header.From, one would 
show all the results matching smtp.FROM, etc.

> My proposal is to either eliminate the headerspec from A-R, or to make
> it subordinate to the method=result. In other words, the headerspec
> should be supporting information to what was validated, not the other
> way around.

I think it is that way now, or at least it's intended to be.  It's meant to be a 
common-factoring of the results rendered by various methods which all evaluated 
the same thing.  This is done mostly for compression, versus adding an A-R 
header for each method regardless of what each one evaluated.

> If headerspec is kept, note the varying use of what's put there. Let's
> think about what the values for ptype first. The spec says either "smtp"
> or "header". Note that DKIM doesn't match either of these, because it
> uses both the header and the body to do verification (and a DNS entry
> too). Hmmm; should token be listed? No, I wouldn't want that. But I'm
> not sure what to replace it with. Note that in the samples, some people
> ignored the "ptype" entirely; perhaps it should be eliminated after all.

In this case I blame the nascence of the specification.  An older draft didn't 
have the "ptype", which is probably why you're not seeing it in some cases.

In the DKIM case I would think we'd want A-R to relay either the purported 
sender (DK used "Sender", then "From") or the (express or implied) value of the 
"i=" tag.

> Back to first principles: what's the headerspec supposed to provide?
> From the comments in the ABNF, I see three things: 1) which part(s) of
> the message transmission was being evaluated (smtp, header or body); 2)
> what identity was extracted from those parts; and 3) what in particular
> within those parts was used to determine the identity. (Ok, body isn't
> listed in #1, but should have been.)

It's intended to report who the sender of the message was according to the 
sender authentication method being evaluated.  In the case of Sender-ID, that's 
the PRA; in the case of SPF, that's the envelope sender; in the case of DKIM, 
that's either the purported sender or the "i=" value.

> From this, we can see that a headerspec should be totally dependent on
> the type of authentication that's being performed, and the types of
> values that should go into it are also totally dependent on the type of
> authentication.

Exactly.

> This implies to me that the headerspec should be: 1) subordinate to the
> authentication results; and the choice of what should be used for ptype
> and property should be specified by protocols that use this specification.

I think the common-factoring described above takes care of the first point, but 
I'd be happy to add text to cover the second.