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.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html