On Thu, Jul 13, 2023 at 6:09 AM Steffen Nurpmeso <[email protected]> wrote:
> Alessandro Vesely wrote in > <[email protected]>: > |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?) > If we could do it all over again, I agree we should have asked forwarder to describe their headers with an ARC instance tag-value. So the draft-chuang-mailing-list-modifications in some sense is trying to provide that capability to a subset of headers likely to be modified by mailing-lists. Also we should have been more ambitious with ARC and have it explicitly be a message authenticator which it isn't today. ARC today just provides prior Authentication-Results in a verifiable way. draft-chuang-replay-resistant-arc is attempting to extend ARC in two important ways: - It asks that the sender define who it will send the message to and will sign for the message to show intent. This can be verified by a 3rd party. (Levine had ideas along in this direction as well) - It asks the sender to specify all recipients and for the receiver to verify that the message went to one of those recipients to prevent replay amplification. Notably it isn't absolutist about message modifications like DKIM signatures, and instead uses ARC's message-signatures, which tolerate forwarder changes in a controlled way. -Wei > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
