To be clear, I think DKIM2 is an interesting proposal, and it will succeed or fail regardless of how the ARC paperwork plays out.
Understand the problems associated with using IETF to promote an authentication standard: IETF has no commitment to email authentication. When this DMARC list was exposed as being unable to protect against impersonation of a p=reject domain, there was no alarm raised, no CIRT ticket opened, and as far as I can tell, no changes made. Just a little whining that the white hat hacker should not have done that. IETF published ARC in hopes that it would help mailing lists, but this IETF list does not provide ARC data (or did not last time I looked inside a message.) IETF "mungs" the From address for p=reject domains, and that munging has created a lot of complaining, but IETF has made no effort to make munging conditional, depending whether the recipient was willing to trust IETF lists. People who know seem to think this behavior is characteristic of the mailing list community: the world should accept malicious impersonation so that mailing lists can continue to operate without even inbound authentication of posts. Some of the energy for killing ARC comes from people who will also be completely unsupportive of your authentication technique when it coms to market. IETF also has no marketing strategy, so you need your own. For DKIM2 to succeed, you need to have people involved who will be processing a sufficient mail volume to make it a de-facto success because they are implementing it: That means you probably need not just Google, but also the US Government, Mimecast, ProofPoint, and hopefully Microsoft. I have concerns that some of those players have no commitment to reliable authentication and elimination of malicious impersonation, but I hope they prove my doubts to be unfounded. In short, do what you need to do and don't worry about ARC. More generally, if IETF gets in your way, have Google create another forum that is committed to email authentication. Doug Foster On Tue, Feb 10, 2026 at 9:30 AM Trent Adams <[email protected]> wrote: > > Doug - > > Thanks (as always) for the detailed set of questions and comments! > > If you believe your support for the DMARC working group to recharter > depends on understanding the what / how of where the learning from the ARC > experiment will be picked up… my suggestion would be to direct your query > to the DKIM WG discussion list, as that’d be the right venue for > understanding the proposed work (and where you could suggest improvements > to ensure it covers your concerns). Hopefully, then, you’ll be comfortable > that the intermediary breakage problems are being adequately addressed. > > Cheers, > Trent > > > *From: *Douglas Foster <[email protected]> > *Date: *Monday, February 9, 2026 at 7:43 PM > *To: *Trent Adams <[email protected]> > *Cc: *IETF DMARC WG <[email protected]> > *Subject: *Re: [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!YLP3Cs5bHH3L8JbVUxqSk7siYFLqydec6jBdvNw0PaTBCI6kGNkZN7z3kvA8_NPHpYCwnUs1LTvd4q4vGZCvLnr-aCjC6cfMZVDrTiIy-ZwNRKtuDjS3o5ZWkTQ9$> > > Trent, I am hoping you can address my concerns about the proposed > migration from ARC to DKIM2 > > We know that SPF and DKIM work well when a message is received directly. > When a third organization is in the middle, these tools become unreliable > because credentials can be added or removed by the presence of the > middleman. For a flow with A=Originator, B=Intermediary, C=Recipient, we > have these use cases: > > · B is an outbound gateway service > > · B is an auto-forward service (no content changes) > > · B is a mailing list (content changes) > > Outbound Gateway Service > > The first situation, where B is an outbound gateway service, is of > particular interest to me, because most of these organizations apply a DKIM > signature on behalf of their clients. This signature is trustworthy if, > and only if, the submitting server was properly authenticated to the > receiving server. There are probably many ways for this authentication to > occur, not all of which can be easily represented using the defined > parameters for Authentication Results.. > > In my data, one organization uses the auth result term to indicate that > they authenticated a specified Mail From address as originating > organization. This is optimal. Another organization uses the auth > result term to indicate confidence that their client, indicated by a > particular host name has authenticated the stated Mail From address. The > basis of that confidence is not explained, in part because there is no way > for them to provide that explanation. Two large organizations indicate > that they authenticated the submitting server using SPF, DKIM, and DMARC. > Then they proceed to sign the message as if the submitter had been > authenticated. Did they authenticate the server by some other method? > It is impossible to know for sure. > > Have I encountered both public news sources and suspicious messages which > indicate that outbound gateway services do not perform perfect > authentication of submitted messages? Yes. Should this be acceptable? > No. > > DKIM2 does not solve this use case. Like DKIM, the signature is not tied > to the server that created it. Certain inferences can be made based on > header position, particularly if the possibility of header reordering is > ignored. But when a DKIM signature appears below the From header, does it > indicate that the signature was prepended by the originating server, or > appended by a downstream server? It is impossible to know for sure. > > Auto-Forwarder > > The problem for an auto-forwarder is that the inbound mail stream is > expected to have a very imperfect mix of credentials. When available, > DKIM2 merely adds another authentication method into the mix, without > solving the confusion unless DKIM2 participation reaches 100%. Assume > that a sophisticated auto-forwarder authenticates every message with a mix > of SPF, DKIM, DMARC, ARC, DKIM2, and local policy, so that downstream > impersonation is fully prevented. it has no way of communicating the > occurrence of local policy authentication downstream, although this could > be corrected with an updated specification. Even then, the forwarder must > rely on downstream trust to accept any decisions based on local policy. > In the ideal case, trust is established out-of-band based on other > relationships between the organizations. > > DKIM Relay Defense: When DKIM2 is applied by organization A to the > originating message, recipient C is able to detect with certainty that a > forwarding operation has occurred through organization B. The message is > also authenticated as long as the DKIM2 signature was applied by the > originating organizations. Without doubt, identifying forwarders is > valuable, and DKIM2 makes the identification easier to perform. However, > to use this data to defeat DKIM reply, recipient C must know whether or not > organization B is a known and trusted forwarder. With this reference > list, messages from approved forwarders can be accepted and messages from > unapproved forwarders cam be blocked or quarantined as suspected DKIM reply > attacks. Unfortunately, most organizations lack a master list of approved > forwarders, so the ability to defeat DKIM replay, using DKIM2, seems more > theory than substance. If organizations choose to build a list of > approved forwarders, which I gramt would be a very good idea, I suggest > that this can be accomplished and enforced using existing data, without > waiting for DKIM2. > > When ARC includes SPF, DKIM, and DMARC results, including the parameters > on which the results were based, the recipient organization can use the ARC > data to judge whether the originator appears acceptable based on local > policy. Quarantine or post-delivery audits can be used to determine if > the ARC data is correct or fraudulent. If fraudulent, then the ARC source > is blacklisted, as the identity of the signer is known with certainty. If > review indicates that the forwarder is easily misled, this is reason to > remove the forwarder from the list of allowed forwarders. DKIM2 provides > authentication of a single message, independent of the forwarder’s > operating practices, but it reveals nothing about whether the forwarder has > operating practices that are worthy of trust. > > Mailing Lists > > Mailing Lists are a special case of auto-forwarding. Because posting > requires approval, it would be reasonable to expect lists to require > authentication as a pre-condition for approval to post. Sadly, I have > been assured that this is rarely the case, including this IETF list. DKIM2 > provides a way for content changes to be documented and reversed, so the > DKIM verification can occur against the pre-modification version of the > message. Compared to ARC, this replaces one difficult trust problem with > another. Is vetting an ARC chain for trustworthiness more difficult than > vetting a transform map for trustworthiness? To my mind, the latter > problem will be much more difficult. > > I will grant that if DKIM2 can achieve 100% participation, many of these > concerns will be mitigated. > > Doug Foster > > On Mon, Feb 9, 2026 at 12:24 PM Trent Adams <tadams= > [email protected]> wrote: > > 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]> > wrote: > > On Fri, Feb 6, 2026 at 8:27 PM Douglas Foster < > [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] > >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
