In article <20180208203207.26575.qm...@f3-external.bushwire.net> 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
