On 24/Mar/10 17:01, Murray S. Kucherawy wrote:
[*tap* **tap** is this thing still on?]
I mentioned this at the APPS area discussion at the IETF on Monday of
this week, and I’d like to get the ball rolling on it.
I'm not there, so I comment by mail: IMHO it is not a good idea, as it
complicates a header field that is fairly difficult already.
One thing that was brought up way back in the early DKIM years, but
dropped then as unimportant, was the idea that Authentication-Results
needs a way to specify which signature a DKIM result is conveying. Since
more than one signature might be on a message from the same domain, we
can’t rely on “header.d” and “header.i” to be able to make this distinction.
For example: A message comes to you with two signatures, both from the
signer. The only distinction is that one signature has an “l=” tag and
one does not. The message was altered by a mailing list. Therefore, the
signature with “l=” passes when you try it, and the other one fails. You
create a compliant Authentication-Results: header field to add to the
message. With the current specification, the best you can do is say
“dkim=pass header.d=example.com; dkim=fail header.d=example.com” and
perhaps rely on signature order to match them up.
As an alternative, the verifier can ignore the failed signature as
though it were not present in the message --as specified. Then, it
would just report a more concise “dkim=pass header.d=example.com”.
I propose that we need a new tag, “header.b”, which will contain the
first several characters of the actual digital signature, which is
pretty much guaranteed to be unique among signatures present. This will
allow unambiguous matching of signatures with results.
Yes it would. However, I'm not sure that would ease the job of a
downstream user of the A-R field. IME, it is difficult to find such a
user. My feeling is that A-R fields are ignored because their meaning
is not obvious. The ability to match A-R sub-fields with specific
signatures wouldn't apparently bring more clue. In facts, one may want
to look at A-Rs to avoid having to examine those nitty-gritty details.
Just my 2c
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html