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

["Brotman, Alex" <[e-mail]>]

This came up in another thread elsewhere, and wanted to see if there was any more input before closing this as "wontfix".  The only feedback I got during this thread was that this external check should remain as it may prevent abuse and it appears that many have already implemented this.

The original thread is here: https://mailarchive.ietf.org/arch/msg/dmarc/pL7dsXjXn9BmADxly0yO2cDC_ro/

Thanks

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

From: dmarc <[e-mail]> On Behalf Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:25 PM
To: DMARC IETF <[e-mail]>
Subject: Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

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:
On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote:
>
> 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"


Actually, the record can also be:

example.com._report._dmarc.example.net TXT "v=DMARC1; rua=[e-mail]<mailto:[e-mail]>"

or even, considering a parallel thread:

example.com._report._dmarc.example.net TXT "v=DMARC1; rua=[e-mail]<mailto:[e-mail]>, /https://www.example.net/report/<https://urldefense.com/v3/__https:/www.example.net/report/__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivpAiHzHx$>"


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<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7489*section-7.1__;Iw!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivpuaI_16$>


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://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00*section-2.1__;Iw!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivpqSIEHa$>
https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00*section-3.2__;Iw!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivqDi6FH6$>

BTW, this duplication is worth yet another ticket.


Best
Ale
--


















_______________________________________________
dmarc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivrqoGdKN$>


--
[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]

  Marc Bradshaw
  marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivmARoKHF$> | @marcbradshaw<https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivu6ug4qh$>