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

[Bron Gondwana <[e-mail]>]

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 havedefined a different p= for (a).

The interesting question is what happens at non-updated sites in each
case, because the answer is either "valid emails that should have been
accepted are rejected by old policy engine" or "spoofed emails that
should have been rejected are accepted by old policy engine"
That's a worthwhile question.  Maybe it's already been asked and
answered and I just missed that.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]