Subject: [dmarc-ietf] A policy weaker than quarantine, yet better than none

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Jan 2021 13:09:15 +0100

On Sun 17/Jan/2021 22:35:36 +0100 John Levine wrote:
> If I wanted, I could send a dozen replies to this list faking the addresses
> of previous senders saying that your suggestion is brilliant, or not.

And we tolerate this security hole because...?

On Tue 15/Dec/2020 10:50:10 +0100 I wrote:
> I wish there was an intermediate policy, call it p=mlm-validate, that 
> directs [an intermediate forwarder such as a mailing list] to reject if not
> authenticated, while final recipients can accept it as if p=none.

At least, we could specify in the General Record Format that unrecognized 
policies should be treated as p=none.  Currently, this is subject to the 
existence of a rua= tag.  In Policy Discovery, we have:

    6.  If a retrieved policy record does not contain a valid "p" tag, or
        contains an "sp" tag that is not valid, then:

        1.  if a "rua" tag is present and contains at least one
            syntactically valid reporting URI, the Mail Receiver SHOULD
            act as if a record containing a valid "v" tag and "p=none"
            was retrieved, and continue processing;

        2.  otherwise, the Mail Receiver applies no DMARC processing to
            this message.

(Such optimization should be inferred by the implementation, no?)

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2021 12:54:15 -0500

> And we tolerate this security hole because...?

Because it is not a problem worth solving in practice.  Mailing lists have 
all sorts of ways to validate submissions beyond looking at the From 
header, ranging from sender challenges to S/MIME signatures.  No list I 
know of turns them on.

> policies should be treated as p=none.

Absolutely not.  Any DMARC record with an invalid p= is just broken.  We 
write standards that say how to interoperate, not how to guess what other 
people had in mind when they implemented it wrong.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Jan 2021 19:48:25 +0100

On Mon 18/Jan/2021 18:54:15 +0100 John R Levine wrote:
> Absolutely not.  Any DMARC record with an invalid p= is just broken.  We write 
> standards that say how to interoperate, not how to guess what other people had 
> in mind when they implemented it wrong.

Right, but IF one day we introduce a new policy, we'll have to be compatible 
with installed base.  Please don't reply that we'll NEVER introduce new policies...

BTW, the current spec does not mean that an invalid p= implies the DMARC record 
is broken.  If it did, it wouldn't say to check rua= in that case.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2021 13:56:21 -0500

> with installed base.  Please don't reply that we'll NEVER introduce new 

It seems unlikely enough that I don't see any reason to worry about it 
until it happens.

> BTW, the current spec does not mean that an invalid p= implies the DMARC 
> record is broken.  If it did, it wouldn't say to check rua= in that case.

I know.  It would have been better if it didn't say that, but it's too 
late to change it now.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Jan 2021 20:14:32 +0100

On Mon 18/Jan/2021 19:56:21 +0100 John Levine wrote:

> 
>> BTW, the current spec does not mean that an invalid p= implies the 
>> DMARC record is broken.  If it did, it wouldn't say to check rua= in 
>> that case.
> 

I don't understand why you say it's too late.  This is not emailcore, 
and we don't risk getting back to proposed standard if we change too much.

We're just writing a proposed standard.  When choosing between a 
better spec and sticking to the existing one what criteria are we 
complying with?

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Mon, 18 Jan 2021 14:17:31 -0500

> better spec and sticking to the existing one what criteria are we

You are assuming facts not in evidence, namely that your proposal results
in a better standard.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Jan 2021 21:20:34 +0100

> You are assuming facts not in evidence, namely that your proposal results

Not my proposal.  John said "it would have been better if...

In general, why are we trying to minimize changes?

Best
Ale
--