One thing I will add to supplement the scenarios mentioned - many commercial DMARC products charge customers by total Aggregrate/Failure report volume, regardless of legitimacy. (but this isn't an RFC7489/DMARCbis problem IMO)

If an actor with mal-intent wanted to grief an organization identified using one of these services that bill their services this way, they could spoof unfathomable amounts of emails to receivers known to generate Aggregate and/or Failure reports, and blow said customer's paid-for DMARC reporting analytics licensing out of the water, and could increase their costs for using the tool extremely high.

- Mark Alley


On 12/8/2024 11:27 AM, Daniel K. wrote:
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 todmarc-le...@ietf.org
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

Reply via email to