The issue of ARC trust is irrelevant to the topic that Ale has raised. ARC is useful for an evaluator to detect forwarding, but it is useless for the problem of "From munging" that has consumed so much time in this WG.
A solution to From Munging requires three pieces: 1) A subscriber's domain that does not enforce From authentication against the list. 2) A mailing list that learns about non-enforcing subscriber domains 3) A mailing list that adapts its munging behavior based on the enforcement policy of subscriber domains. There are many ways that achieve this result. Step 1 may be achieved by subscriber request to his email admin or achieved by default at an organization which ignores DMARC entirely. Step 2 can be achieved by notification from the subscriber, from the subscriber's admin, by information published in DNS, or by sending test messages through the list from an enforcing domain controlled by the list owner. Step 3 can be achieved most easily by conditional munging, but it could also be achieved by waiting, without conditional processing, by waiting until all subscriber domains are known to be non-enforcing. ARC fails to address the Munging problem because it does not provide feedback from the non-enforcing domain to the list. Without feedback, the list does not change its behavior, so the problem remains. It should be obvious that lists need conditional munging. Since the feature is lacking, I have to ask why? The problem has festered for more than 10+ years, so there has been plenty of time for new code to be written. I have to conclude that people like to complain about the problem but don't really care to get it fixed. This is especially true of IETF, since they had the resources to develop a custom munging algorithm but never had the motivation to make it conditional. Any real fix to the munging problem depends on the lists changing their behavior. The lack of interest in Ale's solution, or anything like it, is consistent with the historic pattern of whining about the problem rather than solving it. DF On Fri, Feb 28, 2025 at 4:39 AM Alessandro Vesely <[email protected]> wrote: > On Thu 27/Feb/2025 13:38:00 +0100 Steven M Jones wrote: > > On 2/25/25 3:19 AM, Alessandro Vesely wrote: > >> > >> Many people, including myself, were skeptical about ARC because of the > >> requirement that it be trusted unconditionally. > > > > No, ARC leaves the question of which sealers to trust - and what to do > based on > > the information it conveyed - up to the receiver. It deferred the > question of > > how to make that decision, because it wasn't going to be feasible to > include a > > one-size-fits-all solution as part of a protocol specification. Some > receivers > > have the scale and resources to track reputation in-house, while others > lack > > one or both and might rely on some external source like a datafeed (e.g. > > Spamhaus, SURBL, etc) or manual allowlist (see the neglected GitHub > community > > sealer list), or a fixed list reflected established relationships. > > > > If I'm mistaken and ARC has text that says "trust seals and what they > tell you > > unconditionally," please share a reference so that I can learn the error > of my > > ways. > > > You are right, the actual ARC protocol, RFC 8617, does not enforce trust, > of > course. However, one proposed approach was to unconditionally trust ARC > sealers > to override DMARC. And that was the only practical way. The only other > alternative at the time, reputation monitoring, is a rather vague matter, > whose > semantics clash badly with the deterministic nature of cryptographic > verification. > > > Best > Ale > -- > > > > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
