Also, we'll get them to switch to ed25519 at the same time. I have a hard time believing that all the libraries focusing on DKIMv1 will go back and create some code to handle this case. It's better to create a proper delineation. If the header string doesn't match, we don't have to worry about how it might handle deviation from what it believes should be happening.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Taavi Eomäe <taavi=40zone...@dmarc.ietf.org> > Sent: Monday, March 31, 2025 5:54 AM > To: Alessandro Vesely <ves...@tana.it>; ietf-dkim@ietf.org > Subject: [Ietf-dkim] Re: On the rationale for a new protocol (from the > meeting) > > On 31/03/2025 11:55, Alessandro Vesely wrote: > > If we don't change the canonicalizations, a DKIM1 verifier will be > > able to verify a DKIM2 signature, limited to DKIM1 semantics. A > > successful verification still adds something to the properties of a > > message. > > And as mentioned in some other thread I can't find right now. Keeping the same > header and incrementing the version will also allow DKIM-aware software to > remove DKIM(v2) signatures that they know that they'll break, for example > mailing list milters. > > I can't predict however which is better, missing or broken DKIMv2 signatures. _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
