Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D

[Alessandro Vesely <[e-mail]>]

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
--