[mail-vet-discuss] Proposed "header.b" tag for DKIM signatures

Alessandro Vesely vesely at tana.it
Wed Mar 24 10:46:19 PDT 2010

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

More information about the mail-vet-discuss mailing list