Subject: [dmarc-ietf] Additions to introduction

From: Douglas Foster <[email-masked]>
Date: Fri, 3 Dec 2021 21:16:23 -0500

I propose that a paragraph along these lines be inserted into the
introduction:

The DMARC test is characterized by a one-tailed error distribution:
 Messages which pass verification have a low probability of being false
positives of actual impersonation. When a recipient intends to exempt a
high-value sender from content filtering, identity verification ensures
that such special treatment can be done safely, without concern for
impersonation.    However, the same cannot be said about verification
failures.  Verification failures can occur for many reasons, and many such
messages will be safe and desired by the recipient.   Messages which do not
verify are optimally handled with manual review, but this may not be
feasible due to message volume.    DMARC provides a way for senders and
receivers to safely cooperate to minimize the probability that automated
disposition decisions will be suboptimal.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Dec 2021 22:51:52 -0800

> disposition decisions will be suboptimal.

I have no objection to adding text such as this.  It's worth noting,
though, that DKIM certainly says this already (at least in its Section
6.1), SPF probably says something similar, and DMARC clearly depends on
those.  DMARC alludes to this in RFC 7489, Section 10.5, but it's not as
explicit as what's proposed here.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Sat, 4 Dec 2021 10:15:17 -0500

After I sent this, I wondered if I needed to add more text to explain that
"manual review" means "manual review, followed by local policy changes, so
that manual review will no longer be necessary on messages with the same
identifiers."   If a reader thinks "manual review" means "look at every
message individually, now and forever," the reader will laugh it off.   But
in an introduction, we cannot say everything.  So I am open to suggestions.

I can say with some confidence that the false-positive problem is not
understood in most of the commercial product market.   I shopped for a
commercial product by asking this question,

"Example.com moved to Office365, but did not update their SPF record.   How
do I treat their Office365 messages as SPF-PASS without enabling
impersonation from other sources?"

I found many that could not answer.   Vendors do not understand that an
"allow" override for sender-authentication must mimic the original:  Start
with a trusted identifier that is also verified, then use it to
authenticate an unverified identifier which has an expected value and is
received in the same message.  This type of rule has three parts
(independent identifier, verification mechanism, and dependent identifier),
most of the products that I surveyed could only implement single-part
rules.   Single-part rules work well for message blocking, because a
distrusted identifier generally remains untrusted in all contexts and is
untrusted whether true or spoofed.   But using them for allow rules can
undermine security.

This text introduces the concept that when an automated process applies a
uniform disposition to a mix of wanted and unwanted messages, the results
will always be suboptimal.   The only way to achieve optimal results is to
perform a manual review and classification.

Since unverified messages must also pass filters based on source reputation
and content, the expected consequences of allowed impersonation is low.
Consequently, this draft assumes that the automation will only block sender
authentication failure when the probability of a true impersonation has
reached a high value.  I think this assumption should be made explicit
somewhere in the document.

Doug Foster

---

From: "John Levine" <[email-masked]>
Date: 4 Dec 2021 12:55:28 -0500

It appears that Douglas Foster  <[email-masked]> said:
>-=-=-=-=-=-

The point of a spec is to tell people how to interpoerate.  I don't see how this
contributes to that.  

Also, as we have found from the past several years of argument, the
last sentence is simply wrong. In some cases DMARC lets you make
correct decisions, in others it does not/

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 13:25:12 -0800

> The point of a spec is to tell people how to interpoerate.  I don't see

Lots of specifications include informative guidance or best practices
advice as well as normative specification.  DKIM has loads of it.

-MSK

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 4 Dec 2021 16:34:25 -0500

I am Ok with adding text of this nature, and I think it's helpful in
explaining to folks approaching
DMARC for the first time. But I start to lose focus on reading long
introductions (okay boomer).

Maybe the Intro could get a section or two to help focus it.

I am glad to assist wordsmithing Doug's comments if that is useful.

tim

On Sat, Dec 4, 2021 at 4:25 PM Murray S. Kucherawy <[email-masked]>
wrote:

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

---

From: Seth Blank <[email-masked]>
Date: Sat, 4 Dec 2021 14:09:48 -0800

> I am glad to assist wordsmithing Doug's comments if that is useful.

as an individual, I don't like the wording that Doug has provided at all. I
think I understand what he's trying to say, but the text as proposed is far
more confusing than clarifying.

Further, with SPF and DKIM, it is explicit that you can treat a pass in
certain ways, but that you are to make no such determination when the
authentication method does not pass. But DMARC is explicitly about
providing policy when the auth methods do not validate in an aligned
manner. So, while we all know there are legitimate reasons such validation
might fail, this language feels out of place in DMARC because addressing
these failures is the purpose of the protocol.

As chair, if the group believes some clarification is still needed here,
that makes sense and follows from similar text in the other auth methods.
My ask would be that it provides clarity to address operational matters,
per the charter for this phase of work.

Seth

-- 

*Seth Blank * | Chief Product Officer
*e:* [email-masked]
*p:* 415.273.8818

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: Scott Kitterman <[email-masked]>
Date: Sun, 05 Dec 2021 03:23:45 +0000

>per the charter for this phase of work.

I don't think marketing materials belong in the document.  If you want to give an overview about utility and usage of DMARC, then it should be something about it being super useful and low risk for automated transactional email, but there are substantial false positive risks for email sent from people.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 5 Dec 2021 12:42:51 +0100

On Sun 05/Dec/2021 04:23:45 +0100 Scott Kitterman wrote:
>>> explaining to folks approaching DMARC for the first time. But I start to
>>> lose focus on reading long introductions (okay boomer). >>>

  From a practical POV, a filter can reject or pass a message.  So quarantine 
means pass but with Authentication-Results pointing out the fact, so that local 
delivery scripts can take are of it.

What I would add, perhaps in an appendix, is the usefulness of a domain 
database that the filter leans on.  Besides feeding aggregate reports, a 
database allows users to dynamically enable/ disable DMARC per domain, as well 
as to whitelist or kill-on-sight specific domains.

Best
Ale
--