Closed toddherr closed 5 months ago
This seems to me like mission creep. We know that SPF is awful but it's not DMARC's job to fix it.
Awful or not, I think it's our job to explain the risks for using it for DMARC.
How slippery is this slope? Do we also need to opine on RSA vs. elliptic DKIM signatures? If not, what's the difference?
The difference is that there's no known risk associated with using RSA. The risk over using overbroad authentication assessments for DMARC results is specific to DMARC. Any time you depend on a third party to send your mail for you there's a risk that they will send mail using your Mail From, but not sent by you or them DKIM signing mail using your domain as the d= domain for messages you didn't send. Absent DMARC, the upgrade isn't a huge issue. For DMARC it's particularly bad, so we should address it.
We don't need to add a full section on the subject. Exemplifying ?include:example.com with an accompanying sentence should be enough. We have to do it, because all those papers describing the failure didn't.
Proposed text to the WG email list.
Text addressing the topic is in rev -31
Domain Owners using third parties such as ESPs and other hosting providers for sending email often add include directives to their SPF records that incorporate the entirety of the third party's address space.
If the third party is lax in its controls for use of its platform, this can leave the Domain Owner vulnerable to forged messages using its domain sent from the third party platform achieving SPF passes (both aligned and not aligned); if these SPF passes are aligned, this can also lead to forged messages passing DMARC. Such vulnerabilities have been exploited in the past (https://www.valimail.com/blog/how-an-spf-upgrade-attack-spoofed-googles-blue-checkmark/)
DMARCbis should discuss these vulnerabilities and methods that the Domain Owner can use to mitigate them.