On 12/8/24 01:58, John R Levine wrote: > Well, you know, I have a domain dmarc.fail, and if I wanted I could send > you dmarc reports from dmarc.fail that are 100% DKIM signed and SPF pass > and DMARC aligned and 100% valid XML but that are also 100% fictional.
And if I suddenly start to get bogus DMARC reports from you, I can filter out everything reported by dmarc.fail > I do not understand what problem you think exists here. As stated elsewhere, I'm reading through the drafts looking for inconsistencies, and pointing them out in case changes are warranted. Even if no change is made, the extra scrutiny at least means that we have more than "it was carried over from RFC 7489" as the reason the text is there. Here, I think the problem was stated in the part of my initial message that you cut out. As written now, carried over from 7489: Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. By our discussion here, DMARC alignment reduces no such risk. The fact that no one seems to send fraudulent reports, is a happy coincidence. There are two types of fraudulent reports: * the one you described above; bogus reports from dmarc.fail. This is hard to protect against. But they can be filtered out if discovered. * the one I described; someone claiming to report on behalf of third parties. Like Yahoo, and others, currently does on behalf of its subsidiaries, or due to misconfiguration. This is easy to discover. Right now all of them seem to be legitimate, but there is no way to know for sure. > Anyone can send > fake DMARC reports but as I said, I've never seen one and it's hard to > imagine a plausible reason to do so other than just being perverse. Suddenly someone clever may come up with a use case, and start sending bogus third-party reports. If we want to take action, right now seems to be the time to add further requirements of alignment that will eliminate this third-party kind of fraud. At least then, a sender can only send fraudulent reports on its own behalf, not on the behalf of others. Daniel K. _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org