Subject: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

From: "Brotman, Alex" <[email-masked]>
Date: Sat, 5 Dec 2020 13:51:52 +0000

Hello,

There's currently a ticket that suggests that the requirement for external validation be removed.  Today, if example.com has an RUA that points at example.net, the latter must create a record as such:

example.com._report._dmarc.example.net TXT "v=DMARC1"

The original thought was that a bad actor could overwhelm a target with unrequested reports.  It seems in reality, most report generators only send once per day.  Additionally, there appear to be some generators who ignore the absence of these records.

https://tools.ietf.org/html/rfc7489#section-7.1

We'd like to have discussion wrapped up in about two weeks or so.  Again, thank you for your participation.

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

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2020 13:33:07 -0500

In article <[email-masked]> you write:
>Hello,
>
>There's currently a ticket that suggests that the requirement for external validation be removed.  Today, if
>example.com has an RUA that points at example.net, the latter must create a record as such:
>

Whether or not the mailbombing problem is a practical problem,
everyone has already implemented this check so I do not see what
problem we would solve by getting rid of it. It's not like the
test is expensive or publishing the record is hard.

I think it may somewhat mitigate hammering on third parties when
someone misspells its rua= target.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 13:06:12 +0100

> example.com._report._dmarc.example.net TXT "v=DMARC1"

Actually, the record can also be:

example.com._report._dmarc.example.net TXT "v=DMARC1; rua=[email-masked]"

or even, considering a parallel thread:

example.com._report._dmarc.example.net TXT "v=DMARC1; rua=[email-masked], /https://www.example.net/report/"

That way, external services have the ability to control or suspend  their service.  I think this is an essential requirement.  Let's keep it.

> The original thought was that a bad actor could overwhelm a target with unrequested reports.  It seems in reality, most report generators only send once per day.

Once-per-day has to be amended.  See ticket #71.

> Additionally, there appear to be some generators who ignore the absence of these records.

Aggregate reports are often tagged as spam anyway, but when sent in violation of the spec such tagging is certainly deserved.

> https://tools.ietf.org/html/rfc7489#section-7.1

Why don't you refer to either of the drafts we're editing:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00#section-2.1
https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2

BTW, this duplication is worth yet another ticket.

Best
Ale
--

---

From: "Marc Bradshaw" <[email-masked]>
Date: Tue, 08 Dec 2020 09:25:10 +1100

Removing this opens up the potential for abuse, I don't see the value in removing it.

On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>