On Fri, Aug 29, 2025 at 2:28 PM Todd Herr <t...@someguyinva.com> wrote:
> On Fri, Aug 29, 2025 at 1:51 PM Alessandro Vesely <ves...@tana.it> 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 > t...@someguyinva.com > 703-220-4153 > I've been thinking about the potential problem space you describe, Todd. The question in my mind is whether the problem is the size of a slice of bread, a loaf of bread or the size of a bread truck. My experience inclines me to believe this is not even a slice of bread. Ale points out in many cases the account may not exist. Much of the mail involved is spam. For the most part, when it involves a real recipient we are talking email address and possibly name. How frequently do legitimate individuals or organizations send email using a domain that is not their own? Very rarely. I just don't see this issue at a scope or scale that even makes it a rounding error. The problem is with someone sending mail from a domain they don't have permission to use. Michael Hammer
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
