On Mon, Dec 28, 2020 at 9:12 AM Dotzero <[email protected]> wrote: > > > On Mon, Dec 28, 2020 at 8:30 AM Todd Herr <todd.herr= > [email protected]> wrote: > >> On Thu, Dec 24, 2020 at 1:55 PM John R Levine <[email protected]> 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, > > 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 >
Michael, I am not opposed to the generic warning, but the following sentence in the proposed warning gives me pause: "They are meant to aid domain owners to detect why failures reported in aggregate form occured." The implication, to me, in that sentence is that the failure report will be sent to the party that originated the message, and that's not always going to be true. All failure reports will be sent to the domain owner, but the domain owner will not always be the originating party for the message in the failure report. I'm not a lawyer, but providing A with some information about a message that A sent to X seems different, from a privacy perspective, than providing A with some information about a message impersonating A that B sent to X, and I thought perhaps the generic warning might mention this distinction, if possible. Something like: 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, AND THAT THE DOMAIN OWNER RECEIVING THE REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S) REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain personally identifiable information, which should be considered when deciding whether to generate such reports. -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *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.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
