On Thu 13/Jul/2023 05:33:44 +0200 Grant Taylor wrote:
On 7/12/23 9:26 AM, Wei Chuang wrote:
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)
(3) removing the original DKIM-Signature should never be done. If it's removed
there's no way you can verify it. MLM often rewrite them, which implies they
won't verify unless computed with the relaxed algorithm.
N.B. I've not read draft-chuang-replay-resistant-arc yet.
Me neither.
[...]
Old:
Subject: This is a test
Change:
s/^Subject:\s+\(.*\)$/Subject: [ietf-dkim] \1/
This would change:
Subject: Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D
to:
Subject: [ietf-dkim] Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D
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.
Wei's way to describe the change is probably better implemented by a
post-transformation filter which has the original message available for
comparison and can add all the Prior- headers. That's because MLM often do
change unwittingly, for example, from:
Content-Type: text/plain; charset="us-ascii"
to:
Content-Type: text/plain; charset="utf-8"
which is neither necessary nor documented, AFAIK. It breaks signatures if the
author domain signs Content-Type:. I'm not clear where is the culprit.
Over-signing causes other problems as well.
Grant's post arrived to me base64 encoded. I think that's not how it was sent.
This kind of transformation is easily reversible. However, reconstructing
quoted-printable is not feasible.
For MIME parts, I recall Murray's draft provided for plain single part, mimw
wrapped and mime added. I never saw adding footers inside multiple parts.
Finally, I think there should be some limitations such as the footer being
text/plain and not longer than a few lines, and subject tag being no longer
than a couple of words. That would likely protect the original intent of the
message.
jm2c
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
