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

[Tony Hansen]

Murray S. Kucherawy wrote:
> 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.

Unfortunately, the different authentication mechanisms are usually
looking at totally different things. SIDF uses either or both
smtp.mailfrom and/or header.{from,sender,resent-from,resent-sender}.
DKIM potentially uses the entire header *and* the body. CSV uses
smtp.{helo,ehlo}. BATV uses smtp.mailfrom.

Also, the results produced by the different authentication mechanisms
may generate different values, further eliminating commonality.

I don't see being able to ever combine the A-R headers.

>> 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.

Ok, I can see this choice for DKIM. We're going to need specific
guidance for the different authentication schemes.

>> 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.

Ok.

>> 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.

As I said before, I don't think we'll be able to do common factoring on
the headerspec, as they'd all be checking different things and producing
different identities.

Putting the headerspec *after* the authentication results and not trying
to factor it out makes much more sense to me.

	Tony Hansen
	tony at att.com