On Tue, Dec 22, 2020 at 11:39 AM John R Levine <jo...@taugh.com> wrote:
> I think that text is way too long and overspecific but we've already spent > too much time on this so I'll stop and see if there are other opinions. > > > On Tue, 22 Dec 2020, Alessandro Vesely wrote: > > OLD > > > > "Failure reports," or "failed message reports," provide diagnostic > > information about messages that a Mail Receiver has determined do not > > pass the DMARC mechanism. These reports are generally sent at the > > time such messages are received and evaluated, to provide the Domain > > Owner with timely notification that such failures are occurring, and > > to provide information that may assist in diagnosing the cause of the > > failures. > > > > > > NEW > > > > Failure reports provide detailed information about the failure of a > single > > message or a group of similar messages failing for the same reason. > They > > are meant to aid extreme cases where a domain owner is unable to > detect > why > > failures reported in aggregate form did occur. As an extension of > other > > kinds of failure notifications, these reports can contain either the > > content > > of a failed message or just its header. The latter characteristic > entails > > severe privacy concerns. For that reason, and because it turned out > not > to > > be important, failure reporting is usually disabled. > > The following is factually and technically incorrect: " The latter characteristic entails severe privacy concerns." The latter characteristic "the header". In fact, the full message can contain much more PII and/or PHI. > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly I agree with John. I'll go further and say that the working group should focus on what the IETF does best - technical specifications that involve interoperability - and avoid straying too far into the realms of law and politics. While the EU and GDPR may impact choices that operators make, there are other legal jurisdictions in the world. Further, my experience has been that many operators (receivers) only provide failure reports when contractual relationships (direct or indirect) exist between the parties involved. This can certainly meet the privacy requirements of GDPR and other privacy regulations. In conclusion, suppositional assertions such as " For that reason, and because it turned out not to be important, failure reporting is usually disabled." should not be included in the proposed standard. Could someone (anyone?) provide data that failure reports are not important? One example of the importance and usefulness of failure reports is for domains that actually have control of their mail flows. By pulling all the URLs from failure reports (received through a contracted party) and then removing all the URLs which we included in the mail that we had originally sent, all that was left was 100% badness and maliciousness. This significantly empowered our takedown efforts. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
