Hi!
Top-posting my answer:
In my eyes, DKIM2 recipes (unless withheld for body changes) do have
information to eventually re-create the original message.
However, DKIM2 specifies some header canonicalization and body
canonicalization. Header recipes wouldn't need to reproduce the _exact_
original mail, if the canonicalized version of the original message is
still equal to the canonicalized version of the reconstructed message.
That is, after reconstruction, there can be differences:
In headers, whitespace including folding can be different between the
actual original message and the reconstructed version (basically, any
non-empty sequence of whitespace could be reconstructed to any
potentially different such sequence). Between the ':' and the header
field body, space could even change from none to a nonempty such
sequence or vice versa.
In addition, the header field keys can change case, and any space
between the header field key and the ':' could change at will.
So if your signature scheme covers headers too, that signature scheme
would need to cope with that, i.e. use a canonicalization that at least
flattens those differences.
For bodies the situation is simpler, the differences can only be
different numbers of empty lines at the very end, and/or presence or
absence of a final CRLF.
So again, if your signature scheme uses a canonicalization that flattens
at least those differences, it would probably work. Otherwise it will
likely break in case of DKIM2 recorded changes.
Hannah.
On 7/22/26 03:09, Gino Grossi wrote:
Hi everyone,
I'm new to DKIM2, and thank you for all the work this working group
has done. If my question has already been answered, I apologize and
ask to be pointed in the right direction.
My understanding is that an S/MIME or PGP signature can break when an
intermediary adds or removes content, such as a disclaimer or an
external-email warning. I'm wondering whether the record of changes
DKIM2 requires intermediaries to keep might let a verifier reconstruct
the earlier form of the message (the actual signed form before the
disclaimers or warnings were added).
Could another signature scheme use that reconstructed state to
re-check an earlier signature? For example, could a verifier re-check
an author's original S/MIME signature after a list's documented
changes, if the reconstruction is good enough, or is the "undo" really
only meant for DKIM2's own signatures?
I imagine this would only work if the reconstruction reproduced the
earlier state closely enough for the original signature to re-verify.
Mainly I'm asking about the design intent: is reconstruction meant to
be a feature other signature schemes could rely on that way, or is it
only an internal DKIM2 mechanism?
Thanks again,
Gino Grossi
_______________________________________________
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]
