On Thu 30/May/2024 00:02:40 +0200 Murray S. Kucherawy wrote:
"z=" has been around since RFC 4871. The "z=" tag, when used, typically
contains an encoding of the entire original header. This could be used to
recover a signature that was invalidated by a header field modification of some
kind. Has anyone heard of a verifier actually doing so?
OpenDKIM can do this. It won't then switch the result to a valid one, but it
will at least tell you what change was made to the header that invalidated the
signature so you can pass that information back to the signer if you wish. I
thought this was a valuable thing to add at the time, but I don't think I've
ever heard of anyone trying to extend it to change the validation result.
z= is a valuable tool for debugging and learning why signatures fail. For
reversing purposes, instead, Original-* fields are preferable as they can be
individually added and possibly signed also by different operators. Reversal
must not blindly replace altered fields so as to force verification. It should
check whether the applied changes meet per-field acceptance criteria.
Likewise for identifying the footer. To store the original body hash obviously
is not an acceptable solution.
All of that is meant to say that the idea of undoing mutations you're able to
identify has existed for a while, at least in one implementation. However,
since it hasn't been identified as an interesting capability in the intervening
years, it would seem to support Barry's claim that a broken signature oughta
just stay broken.
There is a set of gentle changes that we learned to accept and treasure during
decades of mailing list usage. However, that set, which we may call
traditional, was never standardized. In addition, there are other kinds of
community-distributed messages that might also be called mailing list, even
though they don't follow that tradition. Thence some confusion.
Rather than not interesting, the reversing capability has been identified as
fragile and messy. Yet it is the only possible /unilateral/ remedy to From:
munging, AFAICS. The latter, in turn, is the preferred unilateral remedy to
DMARC. In this respect, it looks like we lost the ability to develop
cooperative solutions.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]