[*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.
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.
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.
I have this now in a draft that I plan to move through the Applications area of
the IETF as an individual submission since it's fairly minor:
http://datatracker.ietf.org/doc/draft-kucherawy-authres-header-b/
Comments welcome.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html