Subject: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

From: Todd Herr <[email-masked]>
Date: Thu, 19 Aug 2021 14:23:50 -0400

Greetings.

Opening a discussion on two tickets at once, because I think they're
related, especially as presented in the current revision of DMARCbis.

Both topics are addressed in Section 8, Minimum Implementations, which
currently reads in its entirety:

8.  Minimum Implementations

   Domain owners, mediators, and mail receivers can all claim to

   implement DMARC, but what that means will depend on their role in the

   transmission of mail.  To remove any ambiguity from the claims, this

   document specifies the following minimum criteria that must be met

   for each agent to rightly claim to be "implementing DMARC".

   Domain Owner: To implement DMARC, a Domain Owner MUST configure its

   domain to convey its concern that unauthenticated mail be rejected or

   at least treated with suspicion.  This means that it MUST publish a

   policy record that:

   *  Has a p tag with a value of 'quarantine' or 'reject'

   *  Has a rua tag with at least one valid URI

   *  If applicable, has an sp tag with a value of 'quarantine' or

      'reject'

   While 'none' is a syntactically valid value for both the p and sp

   tags, the practical value of either the p tag or sp tag being 'none'

   means that the Domain Owner is still gathering information about mail

   flows for the domain or sub-domains.  It is not yet ready to commit

   to conveying a severity of concern for unauthenticated email using

   its domain.

   Mediator: To implement DMARC, a mediator MUST do the following before

   passing the message to the next hop or rejecting it as appropriate:

   *  Perform DMARC validation checks on inbound mail

   *  Perform validation on any authentication checks recorded by

      previous mediators.

   *  Record the results of its authentication checks in message headers

      for consumption by later hosts.

   Mail Receiver: To implement DMARC, a mail receiver MUST do the

   following:

   *  Perform DMARC validation checks on inbound mail

   *  Perform validation checks on any authentication check results

      recorded by mediators that handled the message prior to its

      reaching the Mail Receiver.

   *  Send aggregate reports to Domain Owners at least every 24 hours

      when a minimum of 100 messages with that domain in the

      RFC5322.From header field have been seen during the reporting

      period

Let's discuss...

-- 

*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: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2021 12:16:05 -0700

>       RFC5322.From header field have been seen during the reporting

I'm of the opinion that this last bullet can't be a MUST.  I understand
that operators in this space really want this to be mandatory, but we are
going to run into cases where doing this is difficult or impossible either
because of operational difficulties (think resource-constrained
environments) or policies ("I am not willing to share any detail about what
mail arrives here").  Making this a MUST explicitly disqualifies them.

Moreover, I would claim that not generating aggregate reports does not
impede interoperability at all, which means use of MUST or even SHOULD here
is not appropriate.

-MSK, participating only

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 19 Aug 2021 19:51:57 +0000

I tend to agree on that last Receiver bullet being unenforced.  If I had to choose between an organization deploying DMARC without reporting, or holding up on deploying DMARC because they can’t provide reporting for X,Y,Z reasons .. I’m choosing the former.  Does it potentially leave a hole in intelligence?  Yes, though doesn’t leave a hole in protection.  I suppose there’s the case where they just say they’ve only “partially” implemented DMARC, but then what’s the point of the MUST.

I want to stew on some of the other bits.  I’m on the fence for the Domain Owner requirements.  I also feel like the document needs a better definition of Mediator (I didn’t see one in the document).

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: Thursday, August 19, 2021 3:16 PM
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

On Thu, Aug 19, 2021 at 11:24 AM Todd Herr <todd.herr=[email-masked]<mailto:[email-masked]>> wrote:

   following:

      period

Let's discuss...

I'm of the opinion that this last bullet can't be a MUST.  I understand that operators in this space really want this to be mandatory, but we are going to run into cases where doing this is difficult or impossible either because of operational difficulties (think resource-constrained environments) or policies ("I am not willing to share any detail about what mail arrives here").  Making this a MUST explicitly disqualifies them.

Moreover, I would claim that not generating aggregate reports does not impede interoperability at all, which means use of MUST or even SHOULD here is not appropriate.

-MSK, participating only

---

From: Todd Herr <[email-masked]>
Date: Thu, 19 Aug 2021 16:02:24 -0400

On Thu, Aug 19, 2021 at 3:53 PM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

>   I also feel like the document needs a better definition of Mediator (I
> didn’t see one in the document).
>

It's implied/inferred from this text in Section 3.1, Conventions Used in
This Document:

   Readers are encouraged to be familiar with the contents of [RFC5598].

   In particular, that document defines various roles in the messaging

   infrastructure that can appear the same or separate in various
   contexts.

--

---

From: Dotzero <[email-masked]>
Date: Thu, 19 Aug 2021 16:50:07 -0400

I'm troubled by this whole section. Unless IETF is getting into the
certification or enforcement business, documenting anything about
"implementation claims" would seem to be a non-starter. Do we have any
similar requirements for "claims" about implementing SMTP, DNS or other
standards? We should stick to the normative requirements for
interoperability and avoid dealing with "claims". Folks who implement
poorly will get an earful from both their mail users and the folks they
interoperate with and that should be sufficient.

This really does seem like pushing on a rope.

Michael Hammer

On Thu, Aug 19, 2021 at 2:24 PM Todd Herr <todd.herr=
[email-masked]> wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2021 17:43:44 -0400

>   to conveying a severity of concern for unauthenticated email using

That's just wrong.  I've looked at the numbers, and p=none perfectly communicates
my level of concern.

If you want to say that someone only implements DMARC if they publish p=quarantine
or p=reject, OK, but please don't try to read people's minds.

R's,
John

>      RFC5322.From header field have been seen during the reporting

I agree that's desirable but not mandatory.  We are not the protocol police,
if people don't want to do something, we can't force them.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2021 22:21:43 -0700

> This really does seem like pushing on a rope.

I could see specifying the minimum implementation needed to interoperate in
a useful way, if it's necessary to do so in a summary section.  Of course,
one should be able to glean that from the collection of MUSTs and SHOULDs
in the document anyway, but summaries can be helpful.

I should add to my other remarks that I don't think it's a bad idea to
spend some text in the document describing how valuable we think generating
reports is, and that we think it's a really good idea to find some way to
participate because the intelligence it provides can be valuable, etc.  I
just don't think a mandate is defensible.

-MSK, continuing hatless

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Aug 2021 10:42:18 +0200

>     *  Has a p tag with a value of 'quarantine' or 'reject'

IMHO this is too much, given the current situation with mailing lists 
(a.k.a. mediators.)  First problem, mail sites with lots of mailing 
list traffic would compulsorily have to set pct=0, which shouldn't be 
a requirement.  Second problem, pct=0 forces mailing lists to rewrite 
From:, and that way the domain owner misses all the feedback resulting 
from mailing lists spread.

For the first problem, I propose an intermediate value, p=validate. 
It is meant for first hops only, and mediators in particular.  A 
mediator should reject posts failing DMARC check if p=validate. 
Normal receivers should ignore p=validate unless they know they're 
routinely going to resend the message to external users (i.e. unless 
they're mediators.)

For the second problem, we'd need a way to ask for reports even after 
From: rewriting.

>     *  Perform validation on any authentication checks recorded by

A MUST here wants at a minimum a specification of how can one validate 
authentication checks, and how can previous mediators be recognized 
and trusted.

>        reaching the Mail Receiver.

See above.  Requiring ARC to implement DMARC is overblown, especially 
since you need a full blown global reputation system to trust ARC 
assertions.

>        RFC5322.From header field have been seen during the reporting

Please drop that 100 messages.  Is it a way to say that feedback from 
personal and SOHO domains is not needed?

Best
Ale
--