I was slow to grasp the attack scenario that Richard described, but having put my brain around his information, I am ready to support ARC termination. Since I have seen nothing about the "why", I submit this draft language in case the group finds it useful.
Doug Foster By design, ARC permits a sender to request an evaluator to ignore a failed DKIM signature verification failure, on the assumption that the verification failure results from innocuous changes, particularly those changes made by mailing lists. Naturally, this same mechanism can be used by a malicious actor to request that malicious changes be ignored, or to request that a fabricated DKIM signature be treated as both legitimate and verified. Consequently, the RFC indicated that evaluators needed to assess the trustworthiness of the ARC signer, using resources external to the specification. In operation, the trust issues have been more difficulty to resolve than expected. A malicious ARC set may be disguised when it is routed through a trusted forwarder that adds a second ARC set which merely restates the fraudulent information in the first set. After an innocuous change invalidates a DKIM signature, a malicious downstream entity could insert malicious content to take advantage of the upstream trust. Overall, the ability to establish a reliable set of trusted ARC sources has proved very difficult, while the volume of trustworthy ARC sets has been low. ARC can also be used to address another risk, the possibility that an outbound gateway service can be duped into accept, sign, and forward a message from an impersonator of the service’s clients. This is less prone to false trust, rather it is prone to false suspicion. There are many possible ways for an outbound gateway service to authenticate its clients, and many of those techniques have no defined representation in an authentication results structure, and most of those could not be independently verified even if the representation existed. A small number of participants report SPF results for the handoff between client and service, but client configuration failures mean that these results generally promote false suspicion of legitimate messages rather than reliable detection of impersonation attacks. Given limited deployment and even more limited usability of ARC results, the ARC experiment is being terminated. On Wed, Feb 11, 2026 at 8:44 AM Murray S. Kucherawy <[email protected]> wrote: > On Wed, Feb 11, 2026 at 8:14 AM Jeroen Massar <jeroen= > [email protected]> wrote: > >> Thanks Richard, that coming from you is the solid signal, that indeed is >> enough for me to say: get rid of ARC. >> >> But yes, as you note above, would be good to have a 'why it is bad thus >> historic'. >> > > I think that given publishing Trent's document is the mechanism by which > the status change will happen, we will implicitly meet that requirement. > > -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]
