On Tue, 1 Apr 2025, Alessandro Vesely wrote:
The only trace header I think it's likely we'll sign is the previous DKIM2
signatures which is easy enough, just sign them in order up through the
current one.
Rather than signing DKIM2-Signature:'s (or whatever they're named), the idea
of an hh= hash of them seems to be more resilient. If there is a
non-reversible, complex change, we can still verify the chain, similar to
ARC's AS.
That makes no sense. If you can't reverse the changes, this is no better
than ARC so there's no point.
I suppose there's the Resent-blah: trace headers, but since we're signing
the envelope recipient already, do we care?
A duly compiled and signed chain of Resent-*: fields would allow a check
equivalent to comparing the envelope. If we seek extended compatibility, it
could allow re-entering the DKIM2 ecosystem.
Please, no. This is a great deal of extra complication for no actual
utility if it even worked, which it wouldn't. To point out the obvious,
you can't expect the Resent-To address to match the envelope receipient
eny more than you can expect To or Cc.
R's,
John
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
