Some of the posts suggest that ARC caused them positive harm. I have a hard time understanding how more information is harmful. Even false data provides valuable reputation information when the falsehood is exposed. If harm is the justification for this charter, that charge needs to be in the charter and the charge needs to be litigated early.
The original request seems to be based on a fear that ARC and DKIM2 are in competition, so DKIM2 wants to kill ARC to eliminate that threat. I find that tactic inappropriate as a concept, and flawed as a question of fact. I am doubtful that the potential benefits from DKIM2 will prove to be a perfect superset of the potential benefits from ARC. I think it more likely that organizations will find that both techniques add value to different problems. If DKIM2 proves itself to be widely successful, ARC will be replaced with DKIM2 without any action by IETF. So this charter seems premature, if the charter is premised on the success of DKIM2. It remains an open question in my mind whether any ARC-termination effort matters. If the opponents to ARC succeed in deprecating ARC, will all of the existing implementers know that the document exists and feel motivated by that document to turn off their implementations? I suspect not. Organizations can already turn ARC on or off at any time based on their perceived benefit or risk from using it. I don't know how often organizations check IETF for a new document, but I suspect rarely. I do not see the need to waste time killing ARC if ARC is as useless as some participants currently believe. There is a lot of tunnel vision in these discussions around the mailing list problem. This can be restated in full as: - Most organizations accept malicious impersonation from 95% of all domains because they are afraid of rejecting wanted messages. - They block all impersonation from the 5% with p=reject whether malicious or not. - Therefore, wanted mailing list traffic is blocked for the 5%, while the other wanted 95% of mailing list traffic is accepted without authentication because of the general exemption given to most mail. - Some evaluators seem unable to create exceptions for the 5%, so IETF needs to help mail originators and mailing lists configure their messages to fix that 5%. When stated this way, I hope it helps everyone see that the more important problem is how to solve the 95% acceptance rate for malicious impersonation. If ARC adds any value to that effort, let it stand. I would prefer a charter for an A/S document which explains its correct and potential uses. Doug Foster On Fri, Feb 6, 2026 at 3:27 AM Baptiste Carvello < [email protected]> wrote: > Hi, > > Le 05/02/2026 à 17:19, Murray S. Kucherawy a écrit : > > > > But as you rightly point out, (2) could take many years given recent > > evidence about how fast this community (doesn't) converge. > > If this is so, then maybe it doesn't make so much sense to throw away > the existing deployments and start all over again from first principles. > > ARC provides the receiver side half of a hop-by-hop message > authentication chain. The only hole that remains to be plugged is the > sender side half: each sender's certification of their "To" header > (together with "From", "Date", but independent from content). This could > be added to all messages on egress, using the same machinery as DKIM > signatures, just with different semantics. > > Then, assuming that every receiver is an authorized forwarder (which is > an acceptable assumption in the common case), the whole forwarding trail > can be followed and verified. > > Those questions might not be appropriate for an already winding-down and > burnt-out working group, but IMHO they deserve to be asked. > > Cheers, > B.C. > > _______________________________________________ > 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]
