Hi!
Why can, in your example, the changes mv=3 to mv=5 not be coalesced?
That ought to be not so difficult algorithmically. (Similarly as one can
merge two consecutive "diff" patchsets into one without having the whole
file or running a full diff algorithm.)
And once one coalesces the patchsets, the property would hold again that
each DKIM2-Signature (i=) has either 0 or 1 "patch" associated, like it
was in the older proposals (when it was still named DKIM2-Changes or
similar).
In what I see here, you'd have to check 2 sets of sequence numbers to
know that history doesn't go backwards (i.e. there's a monotonous
mapping from i= to mv=).
Hannah.
On 11/3/25 20:33, Bron Gondwana wrote:
On Mon, Nov 3, 2025, at 10:28, Wei Chuang wrote:
While I understand the desire to keep DKIM2 simpler, pp= permits
delegation to an email hosting provider as already pointed out above.
One consideration I didn't think of till now is this pp= delegation
can help with the DKIM2 adoption especially when we consider the
algorithmic agility requirement. DKIM2 at some near point wants to
mandate publishing and signing both with RSA and ED25519. My guess is
that many senders and forwarders will have trouble deploying ED25519,
and one avenue to smooth adoption is allowing them to delegate
publishing and signing to their platform. That said, I noticed that
pp= has been removed in draft-clayton-dkim2-spec-03, so perhaps this
discussion is perhaps moot.
We need to discuss this point, it will be a major discussion point for
the headers/
Regarding the mv= tag, can more clarity be provided how that is
different from the i= instance number? Is the idea that a more recent
(higher i= number) DKIM2 signature can reference an older (low mv=)
MailVersion header?
Sure, in my example, I have a message in which the same mv= is signed
twice, then multiple new versions are created before signing again:
brong@elg:~/src/interop/brong$ perl validate.pl brong-final.eml
OK DKIM2-Signature: i=4; mv=5; s=sel3; d=test1.dkim2.com
OK Mail-Version: mv=5
OK Mail-Version: mv=4
OK Mail-Version: mv=3
OK DKIM2-Signature: i=3; mv=2; s=sel2; d=test1.dkim2.com
OK DKIM2-Signature: i=2; mv=2; s=sel2; d=test1.dkim2.com
OK Mail-Version: mv=2
OK DKIM2-Signature: i=1; mv=1; s=sel1; d=test1.dkim2.com
OK Mail-Version: mv=1
So there are two separate things here. Versions of the email, and
signatures on those versions. Right now I'm not checking that the
signatures chain with d/mf/rt alignment, which is why they need their
own monotonically increasing series.
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig,
Dr. Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte
den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this e-mail
in any way is prohibited. If you have received this e-mail in error,
please notify the sender and delete the e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
