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]
