Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Seth Blank <[e-mail]>]

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <[e-mail]>
wrote:
>
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender.  Otherwise that site will bounce the email.
>
> You still have to rewrite the sender until there is either full adoption
> or sufficient adoption that you just don't care about the stragglers.
>
> ARC doesn't solve that unless every receiver is either ARC-aware or
> DMARC-unaware.  Hence the suggestion that I think Hector is making - to
> define a new policy p=rejectnonarc or something, which means that sites
> which are ARC-unaware accept rather than reject.
>

So this is an excellent and crucial point that has been discussed again and
again on and off this list.

ARC only works if critical mass can be reached - both of intermediaries who
break DKIM and receivers who evaluate ARC.

Fundamentally, ARC will never reach critical mass if senders now also need
to enter into the equation with an additional flag on their DMARC record.
This is too high a bar and increases the interoperability problems as
opposed to reducing them.

For now, there is a clear unanswered question: what coverage of receivers
is needed for most mailing lists to achieve stable delivery once ARC is in
the mix? Knowing the landscape of receiving domains, I believe this to be a
small number. From the above comments, I'm guessing you think this is a
large number. We're not going to resolve this difference of opinion in an
open forum. However, releasing ARC as an experiment into the wild for major
lists like the IETF and M3AAWG will give us very clear data very quickly on
what the actual landscape looks like, and what ARC does and does not solve.

In its current form, ARC only helps mail flows, it does not harm them. How
effective this improvement is remains to be seen, but preliminary
information I've been hearing about (which could be totally wrong) makes it
seem like the improvements are dramatic. So let's get ARC tied off as an
Experiment (thank you, Dave Crocker), collect some data, and see where
things stand. Maybe things are great and ARC can move to proposed standard.
Maybe it fundamentally needs more receivers in the mix than currently
expected, and some fix for that is needed. But we'll know that after the
experiment has begun, not before.