[dmarc-ietf] Re: Review of draft-ietf-dmarc-arc-to-historic

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jul 2, 2026 at 7:50 AM Tero Kivinen <[e-mail]> wrote:

> > I think we need to consider whether the success criteria were met
> > generally.  I would argue that an existence proof, while
> > interesting, is probably not sufficient to establish consensus that
> > the experiment was broadly successful.
>
> So you say it is fine to change the goals of the experiment to make
> sure we can mark it as failed, as some big players do not want to
> continue using it.


I don't think I'm changing anything.  I think there are two questions to be
answered.  One was laid out in the success criteria in the RFC: Does this
technology yield the results we were looking for?  The answer to this seems
mixed: some large operators say "no", while some small operators say
"yes".  The other, I would argue, is implied for any experiment that's run
this long: Does the community at large find this useful enough to deploy
it?  The answer to this appears to be "no".  If, on the contrary, the
community had found value in it, vendors of all sizes would have broadly
deployed it by now, and we wouldn't be having this conversation.

> Put another way: You say it's valuable, but as I understand it,
> > operators handling enormous mail volumes across the broadest
> > cross-sections of the Internet have found that it's not.
>
> Yes, they are no the target audience for the ARC.


RFC 8617 didn't include an audience constraint.


> Note, that none of those big players have even implemented per user
> trusted forwarders list that would make ARC useful for validation
> purposes.
>

This supports the complexity argument.  And RFC 8617 didn't advise anyone
that they needed to build per user trusted forwarder lists.

Perhaps ARC by itself isn't enough; implementing several other things is
required for it to be helpful, which is enough to dissuade people from
using it.

Checking snapshot my logs in iki.fi from yesterday, and there was 8973
> arc=pass results, 666 arc=reject results out of 149538 emails my
> random snapshot included. That is about 6% of emails passed through
> had ARC headers that passed.
>
> Whether 6% is good results from this random sample I do not know, but
> it is not that low either.
>

How many distinct domains does that represent?


> Note, that there are lots of places who do NOT want to participate in
> experiments, thus they do not want to use anything that is marked as
> experemental and the participation might be different if this was
> actual standard not experimental RFC.
>

On the flipside, Trent has stated that they're being pressured to implement
ARC because ARC has an RFC, irrespective of its status.


> That is not really an experiment, that is deployment. In experiment we
> see whether this is useful, and then when we found out that it is
> useful, we can start deploying it and then we should be seeing how
> many people actually start using it.
>

The experiment has run for seven years.  What do you propose as a next
step?  Standardize it?  Maybe I'm wrong but to me there doesn't appear to
be momentum for going any further, and I'm not sure a status change to
Proposed Standard will make a difference.


> DKIM2 is going to be much more complex, so if ARC failed because it
> was too complex. One way did cause much more complexity was because it
> required forwarding MTAs to start actually checking SPF, DKIM, and
> DMARC. Before ARC they could simply pass everything through without
> modifications can assume that end MTA will sort things out (except for
> SPF, which would fail anyways, but that is different thing).
>

DKIM2 appears, so far at least, to have the momentum needed to overcome
that complexity, and deliver signal that operators find useful.  ARC
doesn't appear to have developed that momentum.

What might change that?

-MSK