On Mon, Dec 28, 2020 at 8:30 AM Todd Herr <todd.herr= 40valimail....@dmarc.ietf.org> wrote:
> On Thu, Dec 24, 2020 at 1:55 PM John R Levine <jo...@taugh.com> wrote: > >> >> Security considerations >> >> 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 domain owners to detect why failures >> reported in aggregate form occured. It is important to note these >> reports can contain either the header or the entire content of a >> failed message, which in turn may contain personally identifiable >> information, which should be considered when deciding whether to >> generate such reports. >> >> > Sorry; late to the party due to the holiday... > > Is it not also important to note that the recipient of the failure report > (the domain owner) may not be the originator of the failed message, and > that fact should also weigh into the consideration of deciding whether to > generate such reports? > > If A publishes a DMARC policy record, and a bad actor sends intentionally > fraudulent mail using A's domain as the RFC5322.From to addresses that are > not among A's current customer base, and therefore unknown to A, sending > failure reports to A that don't redact these email addresses reveals PII to > A that A has no business receiving. > > -- > > *Todd Herr* | Sr. Technical Program Manager > *e:* todd.h...@valimail.com > *p:* 703.220.4153 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > Todd, Would this be akin to the proprietary and confidential information, as indicated in the footer of your email message, which you sent to a publicly accessible list operating under IETF's "Note Well" policy? Some might argue that receipt of this information in DMARC failure reports is a feature and not a bug. Just as the ability to use WHOIS in fighting abuse has been gutted as a result of GDPR, do we really want to go down a path of warning people of "dangers" in such an un-nuanced manner? I agree with John and others that a generic warning regarding security and privacy issues is the more useful approach given that this is a technical standard and vague hand waving is not particularly useful as an implementation guide. For bad guys using/abusing real email addresses as destinations, the privacy ship has sailed as someone somewhere got breached or the addresses got scraped. The same goes for originating From and Mail >From addresses, except the originating domain is already aware of them. Given the choice between writing a book that few will read and even less will understand, and writing a brief generic warning, I choose short and generic. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
