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

["[e-mail]" <[e-mail]>]

On 8/17/2017 4:09 AM, Bron Gondwana 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] <mailto:[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.
>
You assume that mailing lists are the only corner case that ARC might 
address. It’s quite possible that this is not true. It's also not clear 
what you mean by "direct messages". When an agent does an MX lookup, it 
has no way of knowing whether the indicated MX host is the final 
destination or whether there are additional internal (to the 
administrative domain) or external hops beyond the initially indicated 
MX host. That's one of the things that makes the wonderful wacky world 
of email so interesting. While mailing lists are important to many, they 
are the tail and not the dog in the email world.

> 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).
>

This is absolutely an incorrect statement. Policy within DMARC, as 
expressed by p=, is a request by the sending domain and can always be 
ignored or overridden by local policy. Using ARC as an input is no 
different than any other input that a mailbox provider/validator 
considers in making delivery decisions.

> 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"
>

In the DMARC world, emails are only valid in the sense that they pass 
either SPF or DKIM validation. A decision to accept or reject any given 
email involves many choices beyond simply passing DMARC validation for a 
given from domain. Spoofing may involve emails which pass DMARC 
validation but contain spoofing in the From display name, or any number 
of other ways.

Mike