[dmarc-ietf] Re: Proposed Recharter to Conclude the ARC Experiment

[Bron Gondwana <[e-mail]>]

I will agree with Richard here.  Fastmail ALSO adds ARC headers and verifies ARC, but (still) doesn't treat it as having any spam prediction value.

I would say that operational experience with ARC has borne out the issues that Neil and I recognised, and I wrote about <https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ/> when first implementing ARC.

It was published as "Experimental" because of concerns raise by myself and others about its efficacy under attack.  As Richard has noted here, at one of the largest email receivers in the world, they have stopped treating a passing ARC chain as having a meaningful value.

I'm happy to say "ARC should remain un-deprecated until DKIM2 is published to replace it", but I'd be equally (or even more) happy to say "The ARC experiment should be concluded now".  For the reason that Richard lays out below - people are spending engineering effort implementing it, and customers are requesting it, because they don't know better.

Regards,

Bron.


On Sat, Jan 31, 2026, at 20:48, Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In message <[e-mail] <mailto:[e-mail]>
> il.com>, Seth Blank <[e-mail]> writes
> 
> >    As an individual, I have seen evidence that ARC is strongly adopted 
> >    by the major mailbox providers (Google and Microsoft in particular) 
> 
> it is true that they add ARC header fields
> 
> >    who find it valuable. 
> 
> they must comment for themselves ... at $DAYJOB$ we have found that the
> way in which Google adds ARC header fields makes it counter-productive
> to trust them, so they have been removed from our "trusted" list (they
> add a second set of ARC header fields despite the message having been in
> the hands of bad people, who have altered it to make the message
> malicious, and hence you will accept their assertions as to the
> provenance of the email at your (considerable) peril).
> 
> >    Their mainstream support articles that talk
> >    about authenticating your mail all have sections that tell senders 
> >    who modify messages to ARC Seal those messages, so it’s not niche 
> >    guidance either.
> 
> I think you will find that that advice has now disappeared (and/or has
> been significantly watered down)
> 
> >    I hope these MBPs can share data with this list on usage and impact 
> >    to inform the IETF’s decision making here.
> 
> experience from $DAYJOB$ is that implementing ARC checking does not
> improve email security -- despite considerable work to tweak our
> implementation to try and detect malicious flows.
> 
> > I think obsoleting a 
> >    standard that’s clearly in use and valuable, just because we don’t 
> >    have enough data on this list yet, is a mistake, and we should at 
> >    least endeavor to get the data first.
> 
> $DAYJOB$ has a lot of data ... and we have concluded that is not
> valuable. We have contributed some text to the IETF-draft to explain the
> nature of the failures we have seen.
> 
> >    My belief is that this working group should not recharter and 
> >    should wind down as intended. When there is a technology that 
> >    supersedes ARC (like DKIM2), that document should be what moves the 
> >    ARC bit to obsolete or historic, not us.
> 
> I believe that this draft should progress. I don't especially care in
> which working group that happens, but here is as simple as anywhere and
> since other work has concluded people who do not wish to read about ARC
> can simply unsubscribe.
> 
> We should not give anyone the impression that spending any new
> engineering cycles on ARC is worthwhile.
> 
> - -- 
> richard                       writing to inform and not as company policy
> 
> "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
> 
> iQA/AwUBaX6w/GHfC/FfW545EQIx/ACgycEOWToXLXir7tWu0zKk+s6SXPgAn0Jl
> 0epQ+wM2mvxZfPtJD4ikjXQ8
> =q0Cx
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> dmarc mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [e-mail]