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
