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