On Thu, Jul 13, 2023 at 1:29 AM Alessandro Vesely <ves...@tana.it> 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
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
