Alessandro Vesely wrote in <e40a7d42-5c2a-6a4d-a070-fa0bd11d3...@tana.it>: |On Thu 13/Jul/2023 05:33:44 +0200 Grant Taylor wrote: ... |> 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
Unfortunately it seems it becomes the new norm -- on those MLs which still place tags (and footers) -- to ignore RFCs and turn 'Re: [TAG] bla]' to '[TAG] Re: bla'. I think, .., could it be Mailman 3 which does that. (Note there still is only one tag, not two, as you show.) I am about to do something for the MUA i maintain ("have it on my TODO") because we deal badly. (I was already about to email the mutt MUA list to ask what they are doing.) Well i already had to implement space normalization after that TAB/SPACE mixup "fun" people had a couple of years ago, why not also special-treat a ML tag. (Of course this US-ASCII-centric Re: thing was counteracted long ago, by default we also support other things like wg:, aw: etc, and it is hookable. I see commercially used (and browser-based, for sure) software doing things like Re-2:, Re-4: recently, which also requires adjustments to be made; i have to ask what software is doing that crime, msg-id is DIIE.000008220004F734@HOST and the local thing then says "david3 by Tobit.Software", maybe i should buy myself a Harley-Goliathson, just to be on the safe side, what do i know.) I never understood what DMARC is for. Don't mind. I mean it all fails if ML software simply does its ML thing like it did for decades. If it knows otherwise it can adjust the headers fields, which results in that ugly "x via y" mess. If SPF / DKIM / ARC would be holistic, and if all parties support it, and if MLs would have been in the minds, then maybe ML software should add some sort of compressed base64 encoded comma separated list of field:body pairs of those headers that were modified as part of its business, and a DKIM extension should enforce inclusion of that header if present, and ARC should, too, (i have to reread those RFCs), and so restoration of data during ARC set validation can happen. Maybe DKIM should gain an instance value like ARC has. (Isn't it strange that DKIM is simply unshifted, whereas ARC has an instance value. It can only be so that one of them is wrong, .. and i think ARC is. No?) What happened to Dave Crocker's idea against replay btw? Computing cost cannot be the problem can it. Especially if sendmail" milters, shall this be used regulary for signing purposes, really execute once per receiver; why not add a per-receiver thing header among these costly actions. Ciao. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim