Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

["John Levine" <[e-mail]>]

In article <[e-mail]> you write:
>After all, what are most senders going to do? They will not want their
>signatures to be suddenly unrecognized by 99% of the planet so they'll continue
>to generate a v=1 header and they will also want to reap the bennies of your
>fantastic SpamAssassin feature so they'll additionally generate a v=2 header.

In my application, the feature that requires v=2 is double signing,
i.e. this signature is valid only if there's also a signature from X.  It
was intended as a workaround for the DMARC mailing list problem

The idea is that in addition to your regular v=1 signature, you'd also
put a weak v=2 signature that requires re-signing by the mailing list.
If you don't use conditional signing (or something else subsequently
added that depends on v=2 semantics), then v=1 signatures are fine
forever.

The reason to make then both DKIM-Signature headers is that there is
code, some of which I've written, that looks for DKIM-Signature
headers in a message and calls a DKIM verifier library if it sees
them.  DKIM is slow, do you don't want to waste time verifying
messages with nothing to verify.  If you don't change the
DKIM-Signature header, all of this code keeps working when you upgrade
your DKIM library.  If you invent a new header, it doesn't.

>The end result is two DKIM-Signature headers with different versions for decades
>to come. This will no doubt tweak some receiver is a negative way.

Only if their validators are broken.  I realize that's likely to be
the case now and then but I can't feel too sorry for them.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html