On Mon, Dec 7, 2020 at 4:41 PM John Levine <[email protected]> wrote: > >I don't understand the security or GDPR references. > > Well this is amusing. I wondered if anyone had ever implemented some > version of the http reporting in early DMARC drafts, so I set up a new > domain > with a server that will accept POST or PUT requests and added its URI to my > DMARC records. >
What is tht "mantra"? Running code and rough consensus? Has anyone implemented such reporting? > > I didn't get any of those (the POSTs below are not to the right URI) > but it's impressive how fast Russian bots started to probe it, within > hours. > I thought it's about interoperability. Simply having a webserver running doesn't come close to interoperability, and certainly not at scale. > > This is not a reason to avoid https reporting. Every web site gets > probed like this and so long as your web server rejects unknown URIs, > they're harmless. After all, my e-mail reporting addresses get a > certain amount of spam, too. > > R's, > John > My question was not intended to imply that HTTPS reporting should be avoided. My point was that there has been basically no security discussion or scrutiny of such an implementation. This document is now proposed Standards Track, not Informational or Experimental. As such, proposed changes or additions should be given. Your surprise at what happened so quickly after your "implementation" proves my point that there has been little if any thought of security considerations for this proposed change. My comment about GDPR was simply meant to indicate that the world has changed quite a bit since DMARC was made public in 2011. So too have security considerations evolved. I have no objection in principle to HTTPS reporting, only that such an addition be given the same consideration and scrutiny that DMARC itself is being held to. Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
