On 7/12/23 9:26 AM, Wei Chuang wrote:
Hi folks,
Hi Wei,
Being able to reverse mailing-list message modifications to repair
the message and enable digital signature verification, would resolve
a significant roadblock for further DMARC deployment. Potentially it
would allow better attribution of which party contributed which
content in the message. I propose some ideas around reversible
mailing-list message modifications in:
https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00.
These modifications are: 1) prepending a description string to the
Subject header, 2) rewriting the From header, 3) removing the
original DKIM-Signature and 4) appending a footer to the message
body. (Apologies that -00 draft is still in a rough form)
N.B. I've not read draft-chuang-replay-resistant-arc yet.
I have some questions:
1) Why limit the supported modifications to the four listed above?
2) What if we turned the problem on it's head and instead of recording
old values along with the new values, instead we record the new values
and the permutation used to derive the new values.
Consider:
2 + 3 = 5
to be:
O + C = N
Instead of recording O and N as headers, what if we recorded C and N?
Would recording the Change method -- dare I say -- regular expression --
for want of a better example for discussion -- make reverting the change
simpler?
Old:
Subject: This is a test
Change:
s/^Subject:\s+\(.*\)$/Subject: [ietf-dkim] \1/
New:
Subject: [ietf-dkim] This is a test
I would think that it would be possible to mutate the RE to reverse the
change. E.g.:
New:
Subject: [ietf-dkim] This is a test
Change-Back:
s/^Subject: [ietf-dkim] \(.*\)/Subject: \1/
Original:
Subject: This is a test
I absolutely agree that regular expressions have problems and may open
up a can of worms. I'm mostly using them as a place holder for
something, maybe a dialect of BNF, to describe the change.
I would think that such descriptions of 1) what was changed and 2) how
the change was made would be more flexible than specifying specific
things supported.
I'm going to assume that you have thought of this and have a perfectly
valid reason to not do it that I'm ignorant of. If you can, please
enlighten me as to why such delta descriptions might not work.
Thank you and have a good day,
Grant. . . .
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
