This will still break DKIM (no signing for the fake second message, and even the first message's signature is going to be corrupt?), so a restrictive DMARC policy (p=reject; adkim=s) should mitigate this even if the server software is vulnerable, right?
And if someone tries to force a server to send email for an unauthorized source (e.g. make mail.example.org send a bogus mail for ycombinator.com) - well, this sucks in terms of potentially having to get the vulnerable host out of DNSBLs, but email is still not gonna get through (because of SPF) and I hope RBLs are gonna have a bit relaxed attitude towards this in the next few weeks?
(I don't seriously believe someone's not checking SPF, DKIM or DMARC those days - they're basically three cornerstones of modern mail server auth)
> so a restrictive DMARC policy (p=reject; adkim=s)
This isn't how DMARC works. Valid SPF OR DKIM will validate a message. So unless you drop your SPF policy DMARC will still pass. And unfortunately if you don't have a good SPF policy many mail servers will send your messages to the spam folder, so there isn't a good way to have only DKIM set up.
There are some discussions about requiring DKIM independent of SPF, but nothing published (nevermind adopted) yet.
Oops! Thank you for this, for some reason I always thought the policy is "AND", not "OR". My mistake.
Well, guess I have something to do for Christmas... (I run a non-Postfix MTA, gotta try to test it and see if I can implement a patch if it's vulnerable.)
I currently don't have DMARC setup on my mail server (which runs for a couple of domains plus subdomains for me and a couple of friends/family), but have SPF records set appropriately and DKIM configured. We've not noticed any deliverability issues.
Though I'd be interested to work out (or, be told!) how this might affect this vulnerability. I always assumed that most mail servers both check against SPF records and verify DKIM signatures if both are present, rather than it being a this-or-that thing, so DKIM offering some mitigation is not undone by the presence of SPF.
I doubt it. Some servers may reject based on SPF when there is no DMARC policy but there is no way to know that DKIM is enabled unless you see a signature. So a spoofer could just not include a signature and the receiver would have no way of knowing if the message should be signed.
As others have mentioned, this is not how DMARC works.
But I'd like to add to this that this is also not how 'adkim' works. It won't protect you from this particular attack.
adkim=s adds a strict alignment requirement for DKIM, meaning that the DKIM signature is not to be considered aligned unless the domain matches up to the subdomain level. The default 'relaxed' (adkim=r) alignment requirement allows you to use subdomains with a DKIM key placed under the administrative domain (aka 'root' or 'apex' domain) and vise-versa.
Unless you know exactly what you are doing and you have a situation where you do not control subdomains of your own domain, you probably don't want to use adkim=s.
This will still break DKIM (no signing for the fake second message, and even the first message's signature is going to be corrupt?), so a restrictive DMARC policy (p=reject; adkim=s) should mitigate this even if the server software is vulnerable, right?
And if someone tries to force a server to send email for an unauthorized source (e.g. make mail.example.org send a bogus mail for ycombinator.com) - well, this sucks in terms of potentially having to get the vulnerable host out of DNSBLs, but email is still not gonna get through (because of SPF) and I hope RBLs are gonna have a bit relaxed attitude towards this in the next few weeks?
(I don't seriously believe someone's not checking SPF, DKIM or DMARC those days - they're basically three cornerstones of modern mail server auth)