This problem may already have been addressed, and I’ve no doubt that other people have also given it thought – but I’ve not been able to find any information pertaining to it, so if it has the answer hasn’t been widely disseminated. However I think there is an issue with how SPF relates to non-mail servers and non-existent sub-domains.
First a bit of background though – the purpose of SPF is to prevent sender address forgery and correctly configured it does achieve this for domains and subdomains both for those you intend to send e-mail from and those you don’t. To prevent abuse of domains, and presumably sub-domains that you don’t send e-mail from the SPF FAQ advises that you:
“Publish null SPF records for your domains that don’t send mail”
They acknowledge that there is a problem with people spoofing non-email sending domains, however the FAQ doesn’t mention sub-domains explicitly. At least not until you look at the FAQ for the “Demon Problem”:
“So the advice to SPF publishers is this: you should add an SPF record for each subdomain or hostname that has an A or MX record.”
So this rather overlooked bit of advice is actually telling us that for SPF to be effective we actually need an explicit SFP record for every host we have in our DNS. A quick survey or a few well known companies such as Google and Microsoft suggests that most people don’t do this. The subject matter gets touched on again in the best practices document but only for servers that are meant to be sending out-bound e-mail.
This is where I think there is a problem, if I’m spoofing mail to look as if it comes from you do I actually care that much if the address I’m spoofing is meant to send e-mail or not? The targets of my spoofed mail won’t know that “firstname.lastname@example.org“ isn’t meant to be sending e-mail. Following recommended practice it isn’t a subdomain and isn’t meant to be sending email so we won’t have publish a negative SPF record for it.
The recipient of the mail may be savvy enough to check that “ftp.example.com” is a real server, but that won’t tell them it shouldn’t send e-mail; and as it doesn’t have an SPF record it won’t fail the SPF check. From a SPF point of view there is no difference between a server name and a subdomain, so I can quite happily spoof any A record with a high degree of certainty that it won’t have an SPF record and so won’t be caught by SPF checks.
There is a further wrinkle to this in that I don’t even need to spoof mail as coming from an existing server (though that is probably a more successful tactic) I could just as well invent a new mail sending sub-domain “fakepayroll.example.com” for instance. As the subdomain I’ve just invented for my spoofed mail doesn’t exist it won’t have a SPF record to fail, so will go sailing through any SPF check – but to the end user it’s still a mail seemingly coming from “example.com” . How many users will check if the mail domain exists or not, and even if it doesn’t resolve how do they tell that’s not a DNS issue, or an accidentally exposed internal record?
I’ve verified this behaviour against a few commercial e-mail providers, commercial e-mail products and with various spfquery tools. I don’t know if it is actually a problem in the wild – but it seems to me to be at the very least a potential problem that allows SPF to be easily circumvented.
The obvious workarounds to address this problem seem to be that:
1) You should publish negative SPF records for all A records in your DNS that shouldn’t be sending e-mail, or at the very least for the more tempting addresses, e.g. jobs.example.com
2) Despite what RFC 4408 (http://www.openspf.org/RFC_4408#wildcards) says about publishing positive wild card SPF records you probably want to publish a negative wildcard address in all of your domains to prevent people spoofing non-existent subdomains.
e.g: * IN TXT “v=spf1 -all”
It is quite possible that there is something I’ve missed but having talked this over with a number of people it’s not obvious what that something is. Whilst one could reject mail from subdomains that don’t resolve that would I suspect result in a lot of lost e-mail and wouldn’t resolve the issue of mail being sent using the names of A records that do exist.
So what is it that I’ve missed? Is there a better way to address this potential risk? Is this an actual problem in the wild or just a potential and possibly very low risk issue?