On Thu 05/Feb/2026 17:29:00 +0100 Murray S. Kucherawy wrote:
On Tue, Feb 3, 2026 at 4:55 AM Alessandro Vesely <[email protected]> wrote:
What are those uncontrolled elements, beyond mailing lists and
enterprise relays? Dot-forward settings don't arise spontaneously, and
usually require user verification and consent. And the statistics we've
seen suggest that "the mailing list problem" affects a minimal portion of
email traffic. Therefore, if each subscription is managed individually,
it is not true that the number of potential forwarders is so vast and
dynamic that maintaining a list is unrealistic. Simply, no one has said
how to do it.
It seems to me that any system that seeks to identify a list subscription
or forwarder with high accuracy relies on either (a) humans to be error
free and never lazy, and/or (b) lists to all behave according to some
standard that doesn't exist.
I don't understand (a). What do you mean?
I think in your proposal above, "managed individually" is doing rather a
lot of lifting, and the idea of "maintaining a list" even with automation
will approach an acceptable level of reliability only at great cost which
most non-giant operators can't afford.
Oh, I see. I was trying to avoid the details. In reality, the current
subscription management system, the so-called COI, transacts each subscription
individually, completely automatically, but without involving the mailbox
provider. If lists and providers cooperated, sharing the COI results, lists
could avoid From munging and providers could whitelist confirmed streams.
Indeed, I've attempted to define a protocol to achieve this goal with minimal
cost and user disruption. Since it's already been rejected by this list (and
by the ISE), I've tried not to mention it. However, there may be other,
perhaps better, ways to achieve similar cooperation. Therefore, I believe the
argument is valid and worth discussing.
If I as a Gmail user have to do some manual extra step every time I
subscribe to a list someplace else, I'm going to forget or get it wrong, or
complain about complexity around what I think should be a simple thing. If
I expect Gmail to do that for me, then we're relying on automations based
on heuristics and/or a standard of identifying lists that doesn't exist.
Yes, such a standard doesn't exist, but it could. Since it would solve the
mailing list problem, I think we should consider this possibility.
But all of this is a massive digression into extending or evolving ARC,
which is not the question before us.
May I ask why we have to stick to a predetermined question?
So, the standard is DMARC, which exists, but mailing lists don't behave
according to it. A document proposing to put aside ARC should at least
include some text aimed at putting an end to such naively dissonant
behavior that mailing lists perpetuate "because that's how they've worked
since the 1970s.">
Dissonant with what? It's not dissonant with the standards.
Yes, it is dissonant. Section 7 of DMARCbis addresses this issue in depth.
Unless a post itself originates from another mailing list (a rather rare
occurrence, AFAIK), there is no reason for a mailing list to violate the
author's domain policy. DKIM errors are rare, and occasional rejections may
require the user to re-post the message, which seems more acceptable to me than
allowing uncontrolled access.
This is a political argument that has been rehashed time and time again
about whether DMARC proponents had the right in 2015 to arrive on the scene
and start telling list operators that they're doing it wrong. I suggest
that this is the wrong place to start that again.
Somewhat agreed. I've gotten irritated responses when I tried to tell list
operators how to run their infrastructure :-/
Is there any evidence that there would be momentum if ARC development were
to be given a venue? I don't think I've seen any, but maybe you're privy
to other conversations.
As you know, the draft I proposed was rejected because "the working group is
winding down with the bis documents moving through the IESG process". However,
if any other proposal ever attempts to solve the mailing list problem, it will
face the same scenario. Yes, until DKIM2. But this process should not be a
means of burning bridges in order to make its arrival unavoidable or more
desirable. It should produce an honest statement of the situation.
On that last sentence, I agree.
Thank you.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
