All - Thanks for considering the issues related to concluding the ARC experiment… this conversation is exactly what I was hoping we could have to identify the path forward. Most importantly, we (i.e. the industry) needs clarity about the status of ARC as its current status is causing no end of confusion.
From my read on the conversation so far, we’ve essentially identified three options: 1. Do Nothing - Leave ARC RFC8617 as “Experimental” and let folks figure out what that means, or else allow another group / process to take the work on. 2. Recharter to Designate RFC8617 as “Historical” - This could be accompanied by an Informational RFC that clearly states what was learned during the experiment and points to where / how the information is being directed (e.g. DKIM2). 3. Recharter to Move RFC8617 to “Standards Track” - A long road toward taking the learning from the ARC experiment, updating the specification, and officially adopting it as a mitigation for the intermediary breakage problem. In my opinion, doing nothing will continue to support confusion in the industry and syphon resources away from leveraging what we learned from the experiment and improve the overall situation. Similarly, moving ARC to the “Standards Track” will take a lot of time / energy / effort which is better spent on a more effective and efficient solution with a higher likelihood of adoption and deployment (e.g. DKIM2). Considering a finite set of resources to address intermediary breakage, and given the work in-flight currently within the DKIM Working Group, I believe that the most efficient path forward is to clearly signal to the community that the ARC experiment is concluded, and the signals it was designed to indicate are being incorporated into the proposed DKIM2 specification. My $0.02, Trent From: Douglas Foster <[email protected]> Date: Monday, February 9, 2026 at 9:07 AM To: Murray S. Kucherawy <[email protected]> Cc: Seth Blank <[email protected]>, IETF DMARC WG <[email protected]> Subject: [dmarc-ietf] Re: Proposed Recharter to Conclude the ARC Experiment This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ORgEfCBsr282Fw!YLP3Cs5bHH3L8LB-nhJduMi_3Lt7uK6U1kAbI8ue_j7xUKI_3f0DNfx5Ka_fwuD88dVZR4gHrUzvBjsa34361DL9JtR5m2i3OAOpsQZC53EcJ3rz_2XBE2Gt2bIO$> I would like to discuss whether dkim2 will be a sufficient replacement for ARC, as that seems unlikely to me Is that topic open now? It will also permits discussion of use cases, which speaks to current utility. On Mon, Feb 9, 2026, 7:06 AM Murray S. Kucherawy <[email protected]<mailto:[email protected]>> wrote: On Fri, Feb 6, 2026 at 8:27 PM Douglas Foster <[email protected]<mailto:[email protected]>> wrote: Terminating ARC should require one of two data points: ARC is clearly harmful to some people without evident remedy, or ARC is useful to nobody. The latter can be disproven with one dissent, and I am one dissenter. I am willing to listen to any assertions of harm, as those need to be addressed. There's a false premise here, which is that a contrary existence proof is enough to declare a motion dead. But we operate on consensus here, not unanimity; if consensus exists to change the status of ARC to "Historic", then a single opposing position isn't enough to change the story once the associated concerns have been discussed and addressed (which does not equate to "the point ceded"). The premise that's been put forward is that ARC at Experimental does harm of some sort, chiefly by creating a false notion that it's broadly useful and thus compelling implementations likely to provide marginal value, if any. If that's false, we should do something to clear the air. Are you perhaps suggesting that ARC is useful enough that it warrants standardization instead of deprecation? Or perhaps that it should stay at Experimental longer as there's a chance we'll learn something further from it? A decade of experimentation is a long time to wait for something meaningful to result. There are very big differences between evaluators, depending whether their daily volume is measured in thousands, millions, or billions. I absolutely filter based on mailing list subscription issues because we regularly receive traffic where GoogleGrouos or Groups Outlook.com are used as a spam vector. Are there other small operators that find this output useful? Why aren't we hearing from them? What are people at M3AAWG hearing? Those who consider ARC to be useless are not inconvenienced by those who think it useful. We say that IETF is not the Internet police, so why is IETF trying to shut down a protocol that some participants are voluntarily using? This proposal continues ti look like a political move by DKIM2, and that type of move should be ignored. I'm confused by this assertion. DKIM2 claims that its own results would obviate the need for ARC. I don't understand how that makes this a political move so much as a pragmatic one, at least eventually. -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
