The Sender Policy Framework can’t help prevent spam and phishing if you allow billions of IP addresses to send as your domain
Twenty years ago, Paul Vixie published a Request for Comments on Repudiating MAIL FROM that helped spur the internet community to develop a new way of fighting spam with the Sender Policy Framework (SPF). The issue then, as now, was that the Simple Mail Transfer Protocol (SMTP), which is used to send email on the internet, provides no way of detecting forged sender domains.
However, when using SPF, domain owners can publish domain name system (DNS) records that define the IP addresses authorized to use their domain name for sending email. On the receiving end, an email server can query the SPF records of the apparent sender domain to check whether the sender’s IP address is authorized to send email on behalf of that domain.
SMTP email and SPF overview
Readers familiar with SMTP message sending mechanisms and how SPF interacts with them might prefer to skip this section, although it is mercifully short.
Imagine that Alice at example.com wishes to send an email message to Bob at example.org. Without SPF, Alice and Bob’s email servers would engage in an SMTP conversation something like the following, which is simplified using HELO rather than EHLO, but not in ways that significantly alter the basic constructs:
This is how sending and receiving internet (SMTP) email has occurred since the early 1980s, but it has – at least by the standards of today’s internet – a major problem. In the diagram above, Chad at example.net could just as easily connect to the example.org SMTP server, engage in exactly the same SMTP conversation and have an email message apparently from Alice at example.com delivered to Bob at example.org. Worse still, there would be nothing indicating the deception to Bob, except perhaps IP addresses recorded alongside host names in diagnostic message headers (not shown here), but these are not easy for non-experts to check and, depending on your email client application, are often difficult to even access.
Although not abused in the very early days of email spam, as mass spamming became an established, albeit deservingly despised, business model, such email forgery techniques were widely adopted to improve the chances of spam messages being read and even acted upon.
Back to the hypothetical Chad at example.net sending that message “from” Alice… That would involve two levels of impersonation (or forgery) where many folks now feel that automated, technical checks can or should be made to detect and block such faked email messages. The first is at the SMTP envelope level and the second at the message header level. SPF provides checks at the SMTP envelope level, and later anti-forgery and message authentication protocols DKIM and DMARC provide checks at the message header level.
Does SPF work?
According to one study published in 2022, around 32% of the 1.5 billion domains investigated had SPF records. Out of these, 7.7% had invalid syntax and 1% were using the deprecated PTR record, which points IP addresses to domain names. Uptake of SPF has been slow and flawed indeed, which might lead to another question: how many domains have overly permissive SPF records?
Recent research found that 264 organizations in Australia alone had exploitable IP addresses in their SPF records and so might unwittingly set the stage for large-scale spam and phishing campaigns. While not related to what that research found, I recently had my own brush with potentially dangerous emails that took advantage of misconfigured SPF records.
Spoofed email in my inbox
Recently, I received an email that claimed to be from French insurance company Prudence Créole, but had all the hallmarks of spam and spoofing:
While I know that forging the From: address message header of an email is trivial, my curiosity was aroused when I inspected the full email headers and found that the domain in the SMTP envelope MAIL FROM: address reply@prudencecreole.com had passed the SPF check:
So I looked up the SPF record of the domain prudencecreole.com:
That’s a huge block of IPv4 addresses! 178.33.104.0/2 contains 25% of the IPv4 address space, ranging from 128.0.0.0 to 191.255.255.255. Over a billion IP addresses are approved senders for Prudence Creole’s domain name – a spammer’s paradise.
Just to make sure I wasn’t kidding myself, I set up an email server at home, was assigned a random, but eligible, IP address by my internet service provider, and sent myself an email spoofing prudencecreole.com:
Success!
To top it all off, I checked the SPF record of a domain from another spam email in my inbox that was spoofing wildvoyager.com:
Lo and behold, the 0.0.0.0/0 block allows the entire IPv4 address space, consisting of over four billion addresses, to pass the SPF check while posing as Wild Voyager.
After this experiment, I notified Prudence Créole and Wild Voyager about their misconfigured SPF records. Prudence Créole updated their SPF records before the publication of this article.
Reflections and lessons learned
Creating an SPF record for your domain is no death stroke against spammers’ spoofing efforts. However, if securely configured, the use of SPF can frustrate many attempts like those arriving in my inbox. Perhaps the most significant hurdle standing in the way of immediate, wider use and stricter application of SPF is email deliverability. It takes two to play the SPF game because both senders and recipients need to harmonize their email security policies in case emails fail to be delivered due to overly rigorous rules employed by either side.
However, considering the potential risks and damage from spammers spoofing your domain, the following advice can be applied as appropriate:
Create an SPF record for all your HELO/EHLO identities in case any SPF verifiers are following the recommendation in RFC 7208 to check these
It is better to use the all mechanism with the “–” or “~” qualifiers rather than the “?” qualifier, as the latter effectively allows anyone to spoof your domain
Set up a “drop everything” rule (v=spf1 -all) for each domain and subdomain you own that should never generate (internet-routed) email or appear in the domain name part of the HELO/EHLO or MAIL FROM: commands
As a guideline, make sure your SPF records are small, up to 512 bytes preferably, to prevent them from being silently ignored by some SPF verifiers
Make sure you authorize only a limited and trusted set of IP addresses in your SPF records
The widespread use of SMTP to send email has created an IT culture focused on transferring emails reliably and efficiently, rather than securely and with privacy. Readjusting to a security-focused culture may be a slow process, but one that should be undertaken in view of earning clear dividends against one of the blights of the internet – spam.
Comments