Subject: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC

From: Seth Blank <[email-masked]>
Date: Sun, 7 Jun 2020 14:23:17 -0700

https://trac.ietf.org/trac/dmarc/ticket/66

Many different entities participate in DMARC, and to each, there is a
different definition of what is needed to "implement" or participate in
DMARC.

Should the spec be clear about the different participants, and what it
means for each to participate partially and completely?

As a straw man to start conversation (assume this is all wrong):

The domain owner:
    - partially participating: valid record?
    - complete participation: no part of the domain hierarchy can be
spoofed by an unauthenticated sender?

The receiver/MTA:
    - partially participating: validates DMARC?
    - complete participation: validates DMARC and ARC, and sends aggregate
reports?

The intermediary (is this different than a receiver?):
    - partially: validates DMARC?
    - complete participation: validates DMARC and validates and seals ARC?

-- 

*Seth Blank* | VP, Standards and New Technologies
*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: "John Levine" <[email-masked]>
Date: 7 Jun 2020 20:06:18 -0400

In article <CAOZAAfMSFm5iGG2f-AyL=R7gNvYFmw+fEv1bL=[email-masked]> you write:
>-=-=-=-=-=-

I would rather put this in a separate non-normative BCP.

>    - partially participating: validates DMARC?

My MTA validates DMARC and then does nothing with it other than put the result
in an A-R header.  

It currently only validates ARC on mail that will be run through a mailing list.

This can be a rather deep rabbit hole.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 8 Jun 2020 11:19:30 +0200

On Sun 07/Jun/2020 23:23:17 +0200 Seth Blank wrote:
> Many different entities participate in DMARC, and to each, there is a different
> definition of what is needed to "implement" or participate in DMARC.
> 
> Should the spec be clear about the different participants, and what it means
> for each to participate partially and completely?

The spec should encourage participation, but there is no badge to be won.

>     - complete participation: no part of the domain hierarchy can be spoofed by
> an unauthenticated sender?

That's what many MTA-check tools improperly hint at.  It is wrong.  We cannot
/recommend/ strict policies, at least until the mailing list problem persists.

>     - complete participation: validates DMARC and ARC, and sends aggregate reports?

ARC is not a subset of DMARC, as the substring occurrence could mistakenly
suggest.  It should not even be mentioned in a DMARC spec.

To validate DMARC is an obvious requisite to participation.  It doesn't mean
that the suggested disposition should be (blindly) honored.  To generate
aggregate reports in order to inform the sender /as well as the receiver/ on
how DMARC works is a useful, recommended exercise.

>     - complete participation: validates DMARC and validates and seals ARC?

I tend to identify intermediaries with mailing list operators.  It is time to
say something about From: rewriting, otherwise DMARC remains a wannabe.

ARC is not going to solve the mailing list problem any time soon.  Since From:
rewriting is the de-facto standard, we should at least report our experience
with it.  It may be an integral part of the DMARC spec or a separate document.

Best
Ale
--

---

From: David I <[email-masked]>
Date: Mon, 8 Jun 2020 16:45:17 +0000

I don't know how to represent it in documents, but I do think there would be value in clearer terminology to help people trying to adopt (and buy solutions). I worry that there are people saying they've 'implemented DMARC' who are doing one of inbound filtering, or have published a policy, but not both (I think most simply aren't aware of aggregate reporting as being potentially a separate thing).

I think issue #41 "Potentially separate reporting and policy into different documents" might be related as if there's a separate RFC number for sending aggregate reports, there's a clearer line about whether or not you've implemented it?

David
________________________________
From: dmarc <[email-masked]> on behalf of Seth Blank <seth=[email-masked]>
Sent: 07 June 2020 22:23
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC

https://trac.ietf.org/trac/dmarc/ticket/66<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fdmarc%2Fticket%2F66&data=02%7C01%7Cdavid.i%40ncsc.gov.uk%7Cdea9abc7f5364bb3308308d80b2920cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637271618558249757&sdata=ZNzgnrU80Q%2F5xqAfo9Nw46I1uXqcGWPzzobISlfUQm4%3D&reserved=0>

Many different entities participate in DMARC, and to each, there is a different definition of what is needed to "implement" or participate in DMARC.

Should the spec be clear about the different participants, and what it means for each to participate partially and completely?

The domain owner:
    - partially participating: valid record?
    - complete participation: no part of the domain hierarchy can be spoofed by an unauthenticated sender?

The receiver/MTA:

--

Seth Blank | VP, Standards and New Technologies
e: [email-masked]<mailto:[email-masked]>
p: 415.273.8818

[https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL]

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.

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 08 Jun 2020 12:54:04 -0400

Conformance requirements to support contracting is not something the IETF 
typically does.  I think deferring this to a follow-on BCP is appropriate.

Scott K

On Monday, June 8, 2020 12:45:17 PM EDT David I wrote:
> I don't know how to represent it in documents, but I do think there would be
> value in clearer terminology to help people trying to adopt (and buy
> solutions). I worry that there are people saying they've 'implemented
> DMARC' who are doing one of inbound filtering, or have published a policy,
> but not both (I think most simply aren't aware of aggregate reporting as
> being potentially a separate thing).
> 
> I think issue #41 "Potentially separate reporting and policy into different
> documents" might be related as if there's a separate RFC number for sending
> aggregate reports, there's a clearer line about whether or not you've
> implemented it?
> 
> David
> From: dmarc <[email-masked]> on behalf of Seth Blank
> <seth=[email-masked]> Sent: 07 June 2020 22:23
> https://trac.ietf.org/trac/dmarc/ticket/66<https://eur03.safelinks.protectio
> n.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fdmarc%2Fticket%2F66&
> data=02%7C01%7Cdavid.i%40ncsc.gov.uk%7Cdea9abc7f5364bb3308308d80b2920cb%7C14
> aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637271618558249757&sdata=ZNzgnrU80Q
> %2F5xqAfo9Nw46I1uXqcGWPzzobISlfUQm4%3D&reserved=0>
> 
> [https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0
> Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x
> 5EcZV3rjz19-Dx9rESL]
> 
> 
> This information is exempt under the Freedom of Information Act 2000 (FOIA)
> and may be exempt under other UK information legislation. Refer any FOIA
> queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Jun 2020 10:04:07 -0700

> typically does.  I think deferring this to a follow-on BCP is appropriate.

While true, of course, there is a continuing confusion between the two 
sides of protocol exchanges, especially the indirect kind involving a 
DNS entry.  Some specification help make the distinction rather clear, 
such as calling one client and the other server.  DKIM distinguishes 
'signing' from 'verifying'.

DMARC seem to provide clear labels for making the distinction. Worse, 
section 8 on implementations conflates send and recieve (and doesn't 
even comment on the DNS record.)

So public discussion might be aided by having and using some clear, 
consistent language, along the lines of:

  1.  DMARC Owner Record

  2. DMARC Report Sender

  3. DMARC Report Receiver

  4. ...?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Mon, 8 Jun 2020 10:21:24 -0700

> consistent language, along the lines of:

As Chair, what I'm hearing is that this is a real issue, and may
need clarification in a BCP, not the primary document.

That said, without having at least part of this conversation now (like the
specificity in actors Dave has mentioned above), I don't see how we'll end
up with a standards track document that is clear and has the appropriate
normative language.

Seth

--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Jun 2020 10:24:21 -0700

> need clarification in a BCP, not the primary document.

Assuming the base DMARC document is modified, I'd strongly suggest 
making these terminology distinctions in that document. Especially since 
it already has a section discussing 'implementation'.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 08 Jun 2020 13:49:35 -0400

> it already has a section discussing 'implementation'.

I think your point that the terminology needs improvement is valid, but I 
don't think it's this issue specifically.  I think it would make this issue 
easier to solve in an eventual BCP, but I think it stands on it's own as 
something we should look into for this document, not just a future one.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Jun 2020 10:54:47 -0700

> something we should look into for this document, not just a future one.

Separating basic terminology from basic technical specification doesn't 
make much sense to me.

Terminology and its use is established in the specification of 
architecture, format, and protocol, not some possible, later document 
about operational issues.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 08 Jun 2020 18:18:51 +0000

>about operational issues.

Sorry if I wasn't clear.

I was trying to suggest that the topic of this ticket (defining conformance requirements) should wait for a BCP and that as a separate topic the terminology should be fixed in the DMARC bis effort.

I think we agree.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Jun 2020 11:41:15 -0700

> I was trying to suggest that the topic of this ticket (defining conformance requirements) should wait for a BCP and that as a separate topic the terminology should be fixed in the DMARC bis effort.

ahh.  yes.  conformance is indeed quite separate.

d/

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2020 14:53:35 -0400

In article <[email-masked]> you write:
>> I was trying to suggest that the topic of this ticket (defining conformance requirements) should wait for a BCP
>and that as a separate topic the terminology should be fixed in the DMARC bis effort.
>>
>> I think we agree.
>

Agreed.  Quick, let's declare victory and move on to the next ticket.

R's,
John