Noel's Muses

I did write about Email best practices many years ago (550 Access Denied), even though that was in 2011, most of it is still applicable today, so I suggest you spare a few minutes later to read that article too, but anyway this is 2023, where we now have other tools that join SPF in deployment, like DKIM and DMARC. I'll be releasing one method a month, giving you plenty of time to watch your install to make sure it's performing as expected, and in case it doesn't, you only have one area at a time to debug.

Anti-Spoofing is not just one thing Mail Administrators implement, but several measures, that all work along side each other to help prevent impersonations. If you get an Email from your Bank, Business partner or Accountant - you want to know it really came from them, and not some questionable vermin from some non extradition country trying to scam or infect you with malware by using headers that present to you as one of the aforementioned.

We'll start off concentrating on SPF, so what is it? SPF is Sender Policy Framework, sounds complex, but it's not, it does require two parts for maximum efficiency, first, protecting you when sending Email, and the second which we'll cover later below, is checking for forgeries on your Mail server when other people send you Mail.

SPF has been around for about 20 years now, and for many years a DNS TXT resource record was used, then around early 2010's the SPF type was introduced, but because certain antique but popular *nix distributions were never updated to use the modern type, it was heavily argued by them to abandon it, unfortunately they won out and the SPF type was removed in favour of using the original method of TXT records (/me scratches head)

OK, without boring you with any more history, lets get on with it, first up, enabling the sender side, all this requires to get started is for you to have access to your domains DNS and know some IP addresses, that's it, you don't need to make any changes to your Mail server (unlike next time when we cover DKIM )

Before you proceed you need to ensure everyone with a your_domain email knows they must from now on send Email only from your Mail Server - even if they are at home on a different ISP connection, they should already be using SMTP Auth with TLS anyway, so they can seamlessly move anywhere and still send Email. Not using it? You can find some guides for Android, iPhone, Thunderbird and Outlook here

In configuring SPF, you need to know basically one thing, the IP address of your outbound (sending) Mail Server(s), and any other servers you want to authorise to send Email using your domain name, eg: your Billing system may send Email from itself and not use your normal Mail Server, in which case their IP's need to be known and if they also have IPv6, you'll need that too.

In our simple example, lets assume mail.example.net is your Mail Server, its IP address is 100.99.99.10, and you have IPv6 address which is fe80:1ced:7ea::10 and your Billing system is 100.99.99.20 and its IPv6 is fe80:1ced:7ea::20

It's time to edit our zone file, or if you use a third party DNS service, they'll likely have an option to add a TXT record, so now we add it, you need to tell it that this is SPF, this is done by starting your TXT record with v=spf1 then we add our addresses, you prefix the address with ip4: or ip6: depending on the type being entered, in our example that's ip4:100.99.99.10 and ip6:fe80:1ced:7ea::10 , finally we put the instruction for what do we do which should always be -all , that's dash all, which says reject the message outright.

There are other options, but I wont mention them because I don't recommend using them, and if you're here reading this, your not ready for advanced configurations, some of those settings are dangerous, diminish your protection, and some should never have been implemented full stop because they are stupid and defeat the entire purpose of creating an SPF record.

The only exception would be the include: statement in rare cases, such as it's possible you might use a third party service like QuickBooks or MYOB to do your invoicing which Emails out as if it was you, in this case, you use the include: statement in your record as well so the verifying Mail Server also checks to see if the senders IP came from them, in which case, it passes, eg: include:spf.mandrillapp.com (you need to obtain that information from the third party services FAQ or support). It's also possible the site you include, itself includes other sites, which might include other sites which might... you get the picture, it does happen, technically, the protocol allows for ten of these multi-hop includes, after which no more redirects will be looked up and you risk Mail failures, in my opinion, there is no excuse for creating such a clusterf##kery mess, so don't!

Anyway, I digress... where were we... ahhh yes, If your entering this information into a zone file manually, remember to prefix everything with TXT and encase your SPF data inside double quotes as exampled below.

Putting our example together we end up with...

v=spf1 ip4:100.99.99.10 ip6:fe80:1ced:7ea::10 ip4:100.99.99.20 ip6:fe80:1ced:7ea::20 -all

If you manually added this into a Bind zone file, it will look like this

TXT     "v=spf1 ip4:100.99.99.10 ip6:fe80:1ced:7ea::10 ip4:100.99.99.20 ip6:fe80:1ced:7ea::20 -all"

Another example allowing MYOB and Salesforce to send Email using your domain...

TXT     "v=spf1 ip4:100.99.99.10 ip6:fe80:1ced:7ea::10 include:spf.mandrillapp.com include:_spf.salesforce.com -all"

Make sure your entries are all on one line! Now reload your DNS and you're done enabling SPF for your Email, you may need to wait for DNS propagation, but yes, it's really that simple

Now when an Email is sent, lets say, bad guy pretends to be john.citizen@example.net using his Mail Server at 104.168.34.166 sends mail to agent@accountant.ex, accountant.ex's Mail Server will do usual lookups and provided it's configured to do SPF checking it will get your TXT record's SPF information and compare it to the connection, it will see that 104.168.34.166 is not authorised to send Email for example.net and reject the message, your accountant wont transfer that 10K to Mr Spoofer because your accountant did not get the message.

What about Other Peoples Mail
Remember earlier when I said setting up SPF is two part, well you've done the first, now to complete the second part by setting up SPF checking on your inbound Mail, so you know that message your accountant just sent you, or the Invoice one of your suppliers sent you for $5000, really came from them. SPF (like DKIM) is not configured out of the box with most Mail Servers, as a result, not all servers will check or enforce SPF, but now days it's used extensively, especially by financial institutions, Governments, Enterprises, even eBay, Paypal, and smaller businesses along with all others who care about not being spoofed.

This part is usually as easy as enabling a milter or policy daemon, for example in Postfix, we use policyd-spf, a perl script, it's super fast and light, you wont even know it's there! There exists other milters for other MTA's.

Configuring your MTA...

Postfix

First, we need to install some perl modules (don't be surprised if they already are installed though)

cpan - i  NetAddr::IP Mail::SPF Sys::Syslog

Then grab the policyd-spf file, its parent server is currently down, but you can get a copy here and install it into /usr/libexec/postfix and chmod it 755, then I suggest running it manually right away, to correct any perl errors - usually a missing perl module, just use cpan -i to resolve that.

In /etc/postfix/master.cf add -

spfpolicy   unix  -   n     n    -    0    spawn
     user=nobody argv=/usr/bin/perl /usr/libexec/postfix/policyd-spf.pl

Then in /etc/postfix/main.cf set an option

spfpolicy_time_limit = 3600 

and at the end of the smtpd_recipient_restrictions options, add the line

check_policy_service unix:private/spfpolicy

reload postfix and check for errors that need addressing, there shouldn't be, but best to find out now eh

Congrats! You're all set with SPF, just keep a casual eye on your logs over the following day to make sure everything still looks good.



Sendmail

To have sendmail check SPF on inbound Mail, you'll need to download and install spfmilter

To enable it in sendmail, edit sendmail.mc and add

INPUT_MAIL_FILTER(`spfmilter',`S=unix:/var/run/spfmilter.sock')

Then rebuild and install your new sendmail.cf Next you'll need to add the following startup line into your rc.sendmail or whatever file starts it on your OS.

/path/to/spfmilter  unix:/var/run/spfmilter.sock

finally, restart sendmail



Exim

According to Exims website...
SPF verification support is built into Exim if SUPPORT_SPF=yes is set in Local/Makefile. The support uses the libspf2 library
We don't use Exim, so you'll need to verify this is still the case.


...Next time, we'll take a look at implementing DKIM.