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

[Wei Chuang <[e-mail]>]

On Thu, Jul 13, 2023 at 1:29 AM Alessandro Vesely <[e-mail]> wrote:

> 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.
>
>
Agreed.  For messages likely to undergo Content-Type encoding changes such
as base64, I also suspect the best way to support a reversible footer
addition IMHO is to add a new mime-part footer though this might require
adding multiple/mixed or multipart/related if I understand correctly.


>
> 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.
>
>
>
Not sure how to express that fairly.  I figured let the content
analysis/spam filter system figure out if excessively long footers of
subject are problematic.

-Wei