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
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
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.
NOTE WELL: This list operates according to