Do we need to handle the domain delegation for reports?

[mrisher]

John Levine has pointed out several times the mechanism in DMARC for delegating reports to a new domain, without which someone could potentially direct a flurry of mail to a domain. It seems like overkill to me given how remote the attack scenario is, but what do others think?

[danmarg]

One observation:

DMARC writes:

Without checks, this would allow a bad actor to publish a DMARC policy record that requests that reports be sent to a victim address, and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports.

In the STS world, the bad actor would have to induce the reporter to send a large volume of mail to the bad actor's domain. (It's also the case that he could simply point his MX records at the victim domain, though then the victim could filter on the RCPT verb.)

So does that substantially mitigate the risk? If not, we can include this, but I do feel it's a little bit of cognitive and implementation complexity.

[abrotman]

a) I'd be curious to know how many DMARC report generators actually follow this b) So, they'd have to falsify your TLSRPT record, and then induce the sender to attempt to send messages, and create some TLS failure on the receiving systems to cause reports to be generated. I think I'm reenforcing Dan's sentiment. And a spammer that is harvesting addresses won't care about the DMARC-style validation anyway.

[mrisher]

Discussion was to mention this as a risk but not to create a cryptographic delegation method