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 <[email protected]> On Behalf Of Marc Bradshaw Sent: Monday, December 7, 2020 5:25 PM To: DMARC IETF <[email protected]> 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; [email protected]<mailto:[email protected]>" or even, considering a parallel thread: example.com._report._dmarc.example.net TXT "v=DMARC1; [email protected]<mailto:[email protected]>, /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 [email protected]<mailto:[email protected]> 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$>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
