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

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

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <[e-mail]>
wrote:

> On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
>
> 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.
>
>
> Goodness, it's a wonder that we've ever successfully deployed anything
> incremental around here.  ;-)
> -MSK
>
>
> I laugh as well, but it's more than p=reject isn't enough in the ARC
> world, because it doesn't distinguish between:
> a) I'm OK with email from my domain being sent via mailing lists; and
> b) no, this domain is only ever used for direct messages, it should never
> appear in ARC chains that don't also pass DKIM.
>
> The existing behaviour of p=reject is (b) for receivers that don't support
> ARC - so the question becomes:  are we defining ARC to changing the
> behaviour of p=reject to (a)?  If so, will we define a different (b) later,
> when we could instead have
> defined a different p= for (a).
>

My point is that the "SINGLE SITE" posture is absurd.  In all likelihood
there are still some MTAs out there that don't implement ESMTP and nothing
has melted.  We should fully expect things to roll out gradually, as they
always have.  Anyone planning for a flag day should speak up now so we can
disabuse them (and, of course, abuse them).

If the success of DMARC depends on 100% deployment of ARC, we may as well
pack up and go home now.  It'll never happen.

I support the idea of trying ARC even in the form you claim includes
superfluous operations.  (For the record, I find your technical argument
compelling.)  If after a period of experimentation and data collecting we
find that the seal is not itself useful, we can negotiate a reduced form
and try that.

If you really want to prove your point sooner, implement both, run them for
a while, and publish the results.  But given that there are interoperating
implementations now, I think there's enough to be learned from the
experiment to continue from here rather than reset.

-MSK