Steffen Nurpmeso wrote in
<20250416174856.ASXeYj5H@steffen%sdaoden.eu>:
|John Levine wrote in
| <20250416172847.8886ec4e0...@ary.qy>:
...
||We could except that the Resent-xx headers are not trace headers, even \
||though
||anything you might say about trace headers applies to them, too.
||
||That's why I keep bringing them up. They're an annoying special case. \
|| Per my
||previous message, I still can't figure out if anyone cares. I just \
||found that
||the Alpine command to resend a message does something that breaks DKIM \
||signatures
||and I doubt that anyone ever noticed before.
Actually i want to thank you for this, as i had an excellent idea
that is so simple that i wonder why it took a year and this
message of yours to get there. Don't run away from the credit.
I will (unfortunately i spent now eight hours with feeding etc the
dozens so not yet!) add two special aka pseudo ietf-{resent,list}
"headers" (in that spirit), and if the configuration mentions
those then oversigning/sealing will kick in for Resent-* aka
List-* only if an according header field was actually seen and
signed, but otherwise not! (Ie, "get one", "seal the entire
family".)
Like this i can drop the mailing-list specific postfix
configuration, and all that.
|I did.
|The MUA i maintain generates them for `resend'.
|It however also has `Resend' which does not generate them.
And can blindly `resend'. (Mostly, at least.)
Unfortunately domain-wise signing is pretty inflexible otherwise.
I am actually not so sure which other software does
oversigning/sealing of only headers which were actually signed,
i am pretty sure however noone does that "family-wise" (yet).
This seems like a pretty good solution (tm) for at least a single
level of resending, for dkim-forte / dkimacdc / edkim / dkim2 / xx
it could even be a way per se.
John Levine wrote in
<20250416212246.614d4c4e6...@ary.qy>:
|It appears that Larry M. Smith <ietf....@fahq2.com> said:
...
|>I just wish that things like mailing lists didn't do that. In fact, I
|>have been told recently that some will formulate messages differently
|>based on the sender's envelope's DMARC policy. I have not been able to
|>verify this yet.
|
|Not the envelope but the From: header domain's DMARC policy. Lots of \
|lists do
|that including this one, rewriting the From: address into one that \
|will survive
|DMARC handling.
Actually *only* in relation to the DNS-announced DMARC policy.
Other messages are kicked down the road "just like that",
consciously breaking DKIM signatures of the "RFC5322.From".
This only survives because DKIM specifies ~"one successful
verification is enough". It is a shame given that other
mailing-lists ensure the original==broken signature is removed or
renamed, but not even a bug report can change the situation for
IETF lists! This makes me sad.
This will (aka would AKA SHOULD) not work with DKIMACDC. Which is
why i say "one configuration switch to be toggled" (beside the DNS
entry that announces the desire of SMTP envelope protection.)
I give an example, here Jim Fenton's last message. Sorry for
that, but i filter out my own (on ingress):
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type:
MIME-Version:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscr ibe:List-Post:List-Owner:List-Archive; bh=..; b=..;
From: Jim Fenton <fen...@bluepopcorn.net>
Consciously broken by the IETF. But many verifiers will try it
first, and can only fail. For ACDC i would want to avoid that,
somehow. It is -- sorry moderator -- total brain damage, is it??
(And noting that, in my personal opinion, including List-* for
sealing in an initial private DKIM signature is .. interesting.)
|>I would like to make the argument that such modification to the end-user
|>viewable parts of the message, like what is happening on this list, is
|>superfluous E.g.;
...
|>Superfluous because of RFCs 2369, 2919, and 8058... I'm sure that there
|>are others.
|
|The problem is that recipients apply the From: domain's DMARC policy \
|without
|regard to whether the message might have come through a list.
The problem is that the mailing-list does not take care to avoid
problems further down the line!
It is de-facto "creating a new message" and has to act responsibly
not to discredit anyone, including the author.
And then: how could my domain *know* that it was the IETF list
that broke the signature? I know its DKIM signature is correct,
but i would not know, i could only believe that Jim Fenton's
initial DKIM signature was correct, too. Now his signature is
still in, and broken, while he is still "RFC5322.From".
(And hey: he *sealed* List-* headers!!!)
So for DKIMACDC aka dkim-forte aka edkim aka also that dkim2 thing
i would hope that the above will not work out.
You change the message and/or the envelope, you must (MUST) flag
that and claim the message origin, and you must (MUST) ensure that
and non-DKIMACDC/*-aware downstream consumer gets "a good"
message. And that means active mitigation, and not what the IETF
lists do, *regardless* of DMARC or whatever else technology is in
use.
I really would like to "sanitize email", as there are a thousand
islands with lots of misconfigurations, but especially with/out
DKIM / SPF / DMARC / ARC, and any/no combination of those.
The current situation is a total mess, and --- you know how the
I-H list maintainer, and the trouble with Barbara Denny's yahoooo
emails, how they suffered, and how long it took to get it right,
and what effort it was! That is bogus, that is too complicated,
that is insane!
Whatever the future will bring, it should try to improve that
situation, and that means that for some time (maybe even a decade)
that distorted island that is email today needs to be embraced to
the best possible extend. So ...
|When ARC came along[.]
...
|ARC was supposed to fix[.]
anything but yet another "island of the happy" can it be, in my
humble opinion. At best an existing infrastructure is iterated
and alongside this stabilized, whereas over time the rest decays.
And at some future time one may reconsider what to do about
mitigation.
Until then, in my opinion, and for access-control and
differential-changes, mitigation has to become reintroduced
again -- as necessary even by the DKIM software itself! -- because
the world did not stop and for example mailman3 seems to have
heard the screams "i do not want the From: to be changed!!" that
also i screamed in the past, so now the situation as for example
above with Jim Fenton's email (or likely my own here) is the
terrible de-facto state, and it is de-facto broken.
--End of <20250416212246.614d4c4e6...@ary.qy>
--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
To unsubscribe send an email to ietf-dkim-le...@ietf.org
