Alessandro Vesely wrote in
<[email protected]>:
|On 12/05/2025 17:50, John Levine wrote:
|> It appears that Alessandro Vesely <[email protected]> said:
|>>> When you deliver a message, if you want to undo that particular \
|>>> change to make
|>>> it easier to reply to list messages, that's not a bad idea, and \
|>>> it's something
|>>> I've been doing for years on my mail system.
|>>
|>> Yup, it's a curious protocol. The forwarder munges From: and the \
|>> receiver
|>> restores it, after DMARC evaluation. (Maybe someone should specify \
|>> what header
|>> field to use, Original-From:, X-Original-From:, Author:,...)
|>>
|>>> But it's not related to DKIM2*.
|>
|> Let us not forget that one of the goals of DKIM2 is to make this \
|> kind of munging
|> unnecessary.
|
|I also thought this was the desired solution to the mailing list
|problem. In fact, since a DKIM2 verifier can verify the original
|signature of the author's domain, it can issue a dmarc=pass in the face
|of admissible transformations.
|
|However, how does a list know which subscribers have a DKIM2 verifier?
|We should still stick to the curious, though improved, protocol above.
For EDKIM, aside ARC and DMARC etc:
. No, munging is necessary for many years to come, because there
is a very large software installation base which cannot do any
better.
o (Quite the opposite, *more* munging *possibly* should be done
in order to make all that software happy.)
. Yes, it becomes possible to "undo" munging.
o Either because a user made some "if that domain makes such
a change, that is ok" decision, because the user interface
made that possible. (Easy in an integrated system like eg
GMail, and in similar spirit to the "This email is spam"
button.)
o And/Or because a kind of "template" was (explicitly, thus)
registered for the domain which made the change.
* Not covering what "registered" means. It could be as easy as
allow .ietf.org
that i have to avoid greylising/sender address verification
for IETF.org, ie, a complete whitelist, or something like the
hypothetic
.ietf.org footer,from-rewrite
or
.ietf.org ok:mailman3,delivery-action:from-restore
or whatever.
(And "delivery-action:from-restore" only with very great
suspicion, please.) So your
|>> Yup, it's a curious protocol. The forwarder munges From: and the \
|>> receiver
|>> restores it, after DMARC evaluation. (Maybe someone should specify \
|>> what header
|>> field to use, Original-From:, X-Original-From:, Author:,...)
ends up here without restoration. Maybe it joins in Author: if
you are not doing a list reply, and if the address in Author: is
not in From:/Cc:? And there is no Reply-To: nor Mail-Followup-To:
that *really* should have become standardized.
Ie a MUA *could* restore From: to show it to the user, but that is
not part of EDKIM aka DKIMv1+ACDC: on the SMTP level, nothing such
happens. [AC]DC is only about the restoration possibility and the
cryptographical verification of message content up to the senders
original variant.
And it cannot become automatized, because the user (domain) must
recognize the mailing-list as such, and accept it as such, and for
it to make changes to the envelope / the message.
Now you could say "the mailing-list may announce it is
a mailing-list and makes according changes via some kind of DNS
entry", and that is true. But i had contact to @ietf.org which
have not been mailing-lists for one, and then the receiver would
have a need to trust that nonetheless? So what could such a DNS
entry announce? The acceptance can only happen by the receiver
(domain) thus.
(And *i* btw am not going to think of a "global RPKI-like registry
which announces exact mailing-list addresses and their kind of
being" in order to automatize this acceptance either. I think
solutions will come if the enhanced and hardened EDKIM is
implemented and in production use. And my humble opinion is that
DMARC is not a solution, has never been, and will never be; DMARC
is part of the problem.)
(Maybe really, at some time, such a database will come, in spirit
to letsencrypt, and then there will be a ML-Sig: header field with
a signature, and if you take part in that database and the
signature matches, you know for sure, and you trust, and then this
is automatized. But that is beyond EDKIM; EDKIM is the technical
foundation that enables it, no more, but also not less.)
--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]
To unsubscribe send an email to [email protected]
