On Fri, Aug 29, 2025 at 1:51 PM Alessandro Vesely <[email protected]> wrote:
> On Fri 29/Aug/2025 19:02:56 +0200 Dotzero wrote: > > > > I do have some thoughts on the use of message-id to identify the > original > > (intended) recipient of the rejected message. Only the originator of the > > message could match the message-id back. This means any redaction of PII > > protects privacy but still allows the originator of the message to do > analysis. > > I believe that any discussion of these types of approaches is better > left for a > > BCP. > > > I assume you're thinking this applies to the case where the reported > message > header was redacted in such a way as to hide any To:/Cc:/Bcc: values. I > agree > using Message-Id: would be clever, allowing for heavy redaction —indeed, > one > could omit the third MIME part altogether. But does anyone actually > redact the > reported message? > > Privacy aside, RFC 5965 provides for having "Original-Rcpt-To" fields in > message/feedback-report. Linkedin uses them. Currently, > Original-Rcpt-To's > are missing from the example in Appendix A. I'll add some. > > I would be opposed to including Original-Rcpt-To in a DMARC failure report, due to the possibility of the scenario I described in a different thread: - A is the domain owner that published the DMARC policy and consumes reports - B is the entity sending email that makes unauthorized use of A's domain - C is the recipient of said email, an entity heretofore unknown to A - D is the report generator Any report generated by D that is sent to A and that contains any of C's PII creates a privacy concern for D and also by extension an exposure of that PII to A. DMARC failure reports are different from spam complaint feedback reports. For spam complaint feedback reports, there is a high degree of certainty that the recipient of the feedback report was responsible for generating the message being complained about, either because of the source IP or the DKIM signing domain. This means that the complainant's email address was known to the recipient of the feedback report prior to receiving the feedback report. With DMARC failure reports, we have much less certainty, because an authentication failure of a message authorized by the domain owner of the RFC5322.From header domain is indistinguishable from an authentication failure of a message that has not been authorized by the domain owner of the of the RFC5322.From header domain. Therefore, the report generator has no idea whether or not the intended recipient's email address was known to the domain owner, and so the intended recipient's email address should not be shared in the DMARC failure report. -- Todd Herr Some Guy in VA LLC [email protected] 703-220-4153
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
