On Mon 02/Feb/2026 21:49:40 +0100 Murray S. Kucherawy wrote:
On Fri, Jan 30, 2026 at 11:41 AM Alessandro Vesely <[email protected]> wrote:
I agree with Seth that ARC could be useful. The fact that it hasn't been
widely implemented yet seems to be due to a lack of guidance on how to use
it.
This seems like a slippery slope to me. Sender-ID could've been useful
too, but it turns out it wasn't. In hindsight, I don't think any amount of
guidance would've changed that.
Yes, there was a well-known flaw in Sender-ID.
Rather, it seems to me the community understood the implications and made
its choice with its proverbial feet. This proposed rechartering is meant
to acknowledge this reality, much like RFC 6686 did.
I see this the same way.
SPF and Sender-ID were competing standards from the beginning. SPF, already
widely implemented at the time, was being reintroduced without major changes.
ARC and DKIM2 have a very different relationship.
Some statements in the I-D sound questionable, such as stating that:
[ARC] must address the uncontrolled nature of forwarding, which
spans countless unknown and dynamic systems, rather than only known
mailing lists or enterprise relays.
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?
As for (b), let me quote two messages that appeared earlier on this list. The
first is from John in 2017, saying why ARC can be useful:
The answer, at least at very large mail systems, is that a mailing
list sends nice clean mail, but then it starts forwarding lots of
spam. I've seen this on some of the ICANN lists where someone got his
address book stolen that had both the lists and individuals'
addresses, so we're now getting mail through the lists with faked
addresses of a frequent participant. ARC passes along info from
previous hops so the recipient can retroactively do filtering that the
mailing list didn't.
https://mailarchive.ietf.org/arch/msg/dmarc/Gy4kEMMtXXKQj6RnNiWk6RFOO1M/
The second is from me, but with «From: Seth Blank <[email protected]>», which
proves that even with p=reject, mailing lists still do indeed not filter.
https://mailarchive.ietf.org/arch/msg/dmarc/V9tThlW9TDMpMgpp7KMgKFlLYpo/
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."
The charter should not assume that ARC's momentum "is believed to be
unsupportable by evidence." Throughout the WG, discussions about ARC
usage have been postponed to allow for the completion of the main
documents. Is it possible to discuss these ideas now?>
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.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
