On Tue 02/Apr/2024 15:35:05 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely <[email protected]> wrote:
By now, most mailing lists arranged to either rewrite From: or not break
DKIM signatures. We all hope those hacks are temporary.
What do you mean by "temporary", given the time scales that have already
passed since RFC 7489 saw wide deployment? Do you envision those
techniques ending sometime soon?
Yeah, the time scale is killing us. Is ten years soon enough?
You tell me. You say you're hoping they're temporary, yet they've been
around a long time and I'm not sure that there's an alternative on the
table. I'm asking you to explain.
I believe alternatives are possible. Can't say how long it's going to take,
but I presume when they are available, the nasty hacks will slowly fade out.
If "most" mailing lists have arranged rewrites or non-mutation, and this
appears to be working, are there specific techniques we should
standardize here?
I believe it's possible to leverage ARC so as to overcome those mailing
lists hacks, for an expanding set of domains. It is not difficult to
modify ML software in order to rewrite and/or mutate on a per-user basis.
One can obtain the same effect with existing software if it provides for
twin lists or similar means to split users into two categories. >
This isn't consistent with your previous comment, which claimed that "most"
lists are already doing this. Your language here is more like a proposal.
I'm having a hard time following.
Oh, perhaps you asked if we should standardize the nasty hack? IMHO, we
shouldn't. We didn't standardize COI either.
We should standardize some proposals that make ARC work consistently for
forwarders (including MLs) of any size and kind.
What is it that you believe we should be telling industry to do?
Experiment with new proposals until we find one that works?
Are you suggesting we need some standard way to calculate and/or share a
sealer's reputation for any of this to work?
Sealer's reputation is the same as domain reputation. Good to have it,
whenever it comes.
I interpreted your earlier remark to be a claim that this stuff won't work
absent such data.
A reliable reputation database will certainly make everything email work
better. However, ARC usage with local trust contracts, granted on a case by
case basis could work even without it, methinks.
For ARC, I'd rather consider per-forwarder contracts. Forwarding (of
which MLs are a case) doesn't happen out of the blue. It has to be set
up. Involving the target receiver in the setup may make it trust the
sender's seals, when they belong to the stream thus set up and
identified.
So, a "contract" between each mailing list and each subscriber? What would
that mean?
A contract would mean the same as COI, but involving (also) the subscriber's
MBP. Is it really you? You sure you want to subscribe to this? Then I'll
trust the ML when it ARC-seals messages with this List-Id: destined to you, for
example.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
