Subject: Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Jan 2022 07:32:37 -0800

On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster <
[email-masked]> wrote:

> I suggest the language should be more like this:
>
> If the set produced by the DNS Tree Walk contains no DMARC policy record
> (i.e., any indication that there is no such record as opposed to a
> transient DNS error), Mail Receivers MAY choose to proceed with the DMARC
> mechanism using a default alignment of "relaxed" and a default policy
> recommendation of "NONE".
>
>
This seems to me to be exactly the sort of thing Best Guess SPF tried to
do, and we've rejected that notion.  To paraphrase, this would not be
DMARC, but an action taken unilaterally by a receiver.  There's no
interoperation at the DMARC level happening here.

Moreover, if the default you're applying is "none", isn't that the same as
ignoring the message anyway?

-MSK, just participating

---

From: Douglas Foster <[email-masked]>
Date: Tue, 4 Jan 2022 19:52:53 -0500

There are two possible approaches to DMARC.

One approach says that FAIL should be reliably true, and non-FAIL for any
reason is ambiguous.   This means that domain owners should only publish a
reject policy when there is no possibility that their messages pass through
mailing list or any other path that drops authentication.   It also means
that they should not publish "reject" if there is any possibility of an
"acceptable" impersonation.  This is why John says that it is an abuse of
DMARC to publish reject for anything other than transaction-only domains.

If this approach could be done successfully, it would provide a very
limited benefit.  But it seems clear from this discussion that FAIL has too
many false positives, so the concept has already failed.

The opposite approach is to say that PASS is reliably true, and that
non-PASS is ambiguous.   As I have said before, PASS is very useful to make
whitelisting safe, and to identify messages that are free of impersonation
risk.  I need to worry about impersonation risk whether the sender has no
dmarc policy, a "none" policy, or a "reject" policy that oversimplifies
reality.   Consequently, I classify all messages as either "PASS" (free of
impersonation risk") or "non-PASS" (some impersonation risk").   The goal
is to supplement DMARC with local policy until the ambiguity is gone -
messages from acceptable source are unambiguously PASS, and messages from
unacceptable sources are blacklisted.

At last check, this approach allowed 85% of my messages to be classified as
passing sender authentication.   I continue to work on whittling down the
remaining 15%.

The PASS-centric approach is the only one that makes sense to me.  This is
why I have lobbied for changes to the introduction to explicitly state that
FAIL is an ambiguous result.   If you accept that PASS-centric is the goal,
then using default policies becomes the necessary way of coping with
missing information.

Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jan 2022 21:24:38 -0800

On Tue, Jan 4, 2022 at 4:53 PM Douglas Foster <
[email-masked]> wrote:

> [...]

I would argue that it's well understood by now that DKIM and SPF "pass"
results are the only things that convey usable information.  You know
something about a message that passes; when they fail, the algorithm itself
can't tell you what the exact nature of the failure is.  Section 6.3 of RFC
6376 spends some time discussing this.

I think in DMARC, a strong policy is a tacit expression that the domain
posting that policy understands the narrow but meaningful nature of the
"pass" cases of those protocols, and only wants participating receivers to
deliver messages within that definition.

But if we believe that's not implicit or made clear by the document as-is,
or if the industry at large has missed this point, then sure, we could say
so here.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 Jan 2022 06:32:17 -0500

There are good reasons for talking about a default DMARC policy.   It is
certainly not to give evaluators permission, because we know that
evaluators can do whatever they want, and they will do what they deem to be
in their best interest.

The point of a specification like this is to understand each participant's
best interest and channel that toward the common goal.   I perceive a false
assumption that when a sender does not publish p=reject, then his messages
cannot be blocked for failure to validate, and therefore DKIM signatures
are unnecessary.   Your question about "none" equaling "ignore" comes
across that way.    "None" means that the sender provides no guidance, it
does not mean that the message cannot be blocked because of sender
authentication failure.

As an evaluator, EVERY message that does not validate is a potential
impersonation threat, and therefore needs close inspection.   Inspection
may produce these outcomes:
- quarantine, manual review, and release, which produces temporary delay,
- quarantine which expires before manual review, producing the same effect
as a block
- manual review which determines that the source sends harmless but
unwanted advertising, resulting in a permanent block on the sender.
- manual review which confirms that the message contains unacceptable
impersonation, resulting in a permanent block on the sender.

Consequently, the best way for senders to avoid delayed or blocked messages
is to avoid getting close examination.  This is facilitated by ensuring
messages are both DKIM-verifiable and SPF-PASS, regardless of DMARC
policy.   P=NONE or T=Y or no policy are not valid substitutes.

It IS in the interest of an evaluator to apply the DMARC test to every
message, so I believe it is in the interest of the specification to
acknowledge that likelihood.  If someone in the group believes that it is
contrary to an evaluator's best interest, we need to discuss and document
that risk also.

Doug

---

From: Todd Herr <[email-masked]>
Date: Thu, 6 Jan 2022 08:35:33 -0500

On Thu, Jan 6, 2022 at 6:32 AM Douglas Foster <
[email-masked]> wrote:

> Consequently, the best way for senders to avoid delayed or blocked
> messages is to avoid getting close examination.  This is facilitated by
> ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of
> DMARC policy.   P=NONE or T=Y or no policy are not valid substitutes.
>
I believe there is merit to what you've written here, but I don't think
these ideas belong in the DMARC protocol specification but instead in a
separate document.

Within the IETF, it's my understanding that an Applicability Statement
might be a better place for advice on how best to implement a protocol and
what impacts various choices may have.

Outside of the IETF, there is literature already that describes best
practices for email authentication for senders, intermediaries, and
receivers; here is a link to one such document -
https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2022 11:07:09 -0500

It appears that Murray S. Kucherawy  <[email-masked]> said:
>results are the only things that convey usable information.

I agree.  I've never seen anyone have any trouble figuring out what SPF or
DKIM inputs to feed into DMARC and don't see anything to change here.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2022 11:11:50 -0500

>> DMARC policy.   P=NONE or T=Y or no policy are not valid substitutes. ...

No.  Just no.  This isn't mission creep, it's mission gallop.

DMARC is not a magic bullet to divide good mail from bad mail and we
would do nobody any favors by going down this path.

DMARC does what it does, and I really do not want to start opining about
the way other parts of a mail system should work.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 6 Jan 2022 08:18:39 -0800

On 1/6/2022 3:32 AM, Douglas Foster wrote:
> messages is to avoid getting close examination.  This is facilitated 
> by ensuring messages are both DKIM-verifiable and SPF-PASS, regardless 
> of DMARC policy.   P=NONE or T=Y or no policy are not valid substitutes.

That's doubly and impressively wrong.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 6 Jan 2022 19:59:31 +0100

On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote:
> The point of a specification like this is to understand each 
> participant's best interest and channel that toward the common goal.  
>   I perceive a false assumption that when a sender does not publish 
> p=reject, then his messages cannot be blocked for failure to validate, 
> and therefore DKIM signatures are unnecessary.

Or we could devise a protocol whereby a sender can supply customized policies to different (kinds of) receivers.  For example, I might want to publish p=reject for, say, ietf.org and some other receivers that I trust to verify correctly.  Queries could be arranged similar to external reporting authorization, exposing the receiver's FQDN:

; <<>> DiG 9.16.1-Ubuntu <<>> ietfa.amsl.com._dmarc.tana.it txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58470
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ietfa.amsl.com._dmarc.tana.it.	IN	TXT

;; ANSWER SECTION:
_dmarc.tana.it.		86400	IN	TXT	"v=DMARC1; p=reject; " "rua=mailto:[email-masked]; " "ruf=mailto:[email-masked];"

Hm... no fooling.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 Jan 2022 16:34:44 -0500

Please explain what you think is wrong and why.   We are not voting yet, we
are discussing.

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 Jan 2022 16:38:13 -0500

What is the basis of your conviction that everyone knows how to use SPF and
DMARC validation properly?

It ceased to be my perception when I tried to buy an email filtering
product that implements DMARC.

Doug

On Thu, Jan 6, 2022 at 11:07 AM John Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Jan 2022 21:42:31 +0000

>Please explain what you think is wrong and why.   We are not voting yet, we

This being the IETF, we aren't voting.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2022 16:50:42 -0500

It appears that Alessandro Vesely  <[email-masked]> said:
>Or we could devise a protocol whereby a sender can supply customized policies to different (kinds of) receivers. 

But that wouldn't be DMARC, so please, let's stop.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Jan 2022 18:03:09 -0800

> does not mean that the message cannot be blocked because of sender

I'm not sure I agree with the second paragraph's assertion.

DMARC, or any protocol specification really, is about interoperability
between two participants.  In DMARC's case, that's a sender and a
receiver.  When a policy is published, the receiver has asked the sender's
DNS for that information, received a reply, and put it to use in the DMARC
evaluation machine; the protocol has been followed.  However, when no
policy is published, or in the errant case where multiple policies are
published, the protocol cannot be said to have completed, since there was
no interaction between the sender and the receiver.

Similarly, the notion of a default DMARC policy suggests that when no
policy is published, the receiver has some means to assert "I think I know
what you probably would want" and then completes the protocol on that
basis.  But there's been no interoperability here; no interoperable
protocol has been executed.  It's on the same basis that Scott earlier said
Best-Guess SPF is not SPF.

> contrary to an evaluator's best interest, we need to discuss and document

I suggest that this might be the kind of advice we float in a Best Current
Practices document or similar, if that's the consensus opinion, but not in
the protocol itself.  At a minimum, I suggest that it should be informative
text, and certainly not mandatory.

-MSK, participating

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 Jan 2022 23:11:59 -0500

Protocols are created to solve a problem, and solution design should
include both normal operation and failure management.    That’s why
electrical panels use circuit breakers instead of simple on-off switches.

In this current case, we are defining an access control system for email,
so we have easy parallels with an access control system for doors.  The
core protocol defines how the badge is formatted, how the reader
interrogates the badge, and how it interprets the response.   But the
solution is much more.  The solution needs to include a way to cope with
employees who forgot their badges, badges that don’t work, guests who do
not have a badge, solenoids that don’t open doors when the badge reads
successfully, the emergency exit path if there is a fire, and probably
other things.

Mailing list messages can be considered equivalent to an employee who
arrives at work without his badge.   Assume that an organization wants to
trust mailing list messages from IETF.ORG.   How is this accomplished?  My
analysis says that there are ways to do this right and ways to do this
wrong.   I have seen an abundance of wrong implementations.  Defining how
to do it right is an example of failure management.  I do not believe that
it is irrelevant to the protocol; rather it should be an integral part of
it.

Doug

On Thu, Jan 6, 2022 at 9:03 PM Murray S. Kucherawy <[email-masked]>
wrote:

>> participant's best interest and channel that toward the common goal.   I
>> perceive a false assumption that when a sender does not publish p=reject,
>> then his messages cannot be blocked for failure to validate, and therefore
>> DKIM signatures are unnecessary.   Your question about "none" equaling
>> "ignore" comes across that way.    "None" means that the sender provides no
>> guidance, it does not mean that the message cannot be blocked because of
>> sender authentication failure.
>>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Jan 2022 20:52:15 -0800

On Thu, Jan 6, 2022 at 8:12 PM Douglas Foster <
[email-masked]> wrote:

> trust mailing list messages from IETF.ORG.   How is this accomplished?
> My analysis says that there are ways to do this right and ways to do this
I think if you extend that logic to its conclusion, the core protocol for
email should contain DKIM, SPF, DMARC, maybe MIME, maybe greylisting,
DNSXLs, and a host of other things.  It would be massive.

I would wager that the manual for the badge readers at your place of work
or mine probably doesn't talk about what policy you should have for
employees who forget badges, handling of guests, emergency exits, or most
of the other things you listed.  How could it possibly know the right
answers to such questions?  I'm sure at least for reasons of liability,
they are tightly scoped, and such things are left to the purview of the
customer who has full context of how the reader is going to be used.

Since the email ecosystem evolves, parts are added over time and other
parts become obsolete, best practices evolve with new usage, etc., it's
more agile for us to be crisp in separating protocol from advice.  We
commonly publish protocol specifications in Standards Track documents and
then include advice of the sort you're advocating in Informational
documents.  This also allows us to evolve the advice text separately from
the protocol documents when doing so is warranted.  It also means the
protocol can advance toward publication while we might still be haggling
about the advice part.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 7 Jan 2022 11:09:08 +0100

> But that wouldn't be DMARC, so please, let's stop.

I'd say customized policies are non-feasible rather than non-DMARC.

On the opposite side, enabling DMARC at the receiver, I have a 
per-domain setup which I think is handy and useful.  However, 
per-domain policies are not feasible because 1) they would break 
existing base and 2) would be too complicated to set up effectively.

I mentioned that (non-) possibility as a brainstorming means to foster 
thinking about per- kind of receiver policies (see p=validate, for 
example).

Best
Ale
--