Since the last time I wrote something about e-mail (March), I mentioned Sender Policy Framework (SPF). This standard allows anyone to publish information about which IP addresses are allowed to send mail on that domains’ behalf.
As SPF is quite complicated in some ways, I could not find a tool that would nicely list all IP-addresses which are allowed, so I made one myself! It clearly shows all directives and what it results in. All nodes are IP-addresses and all edges are directional arrows, showing which node led to each IP-address.
Tool is available on https://t.ted.do/spf/.
The colour of each node represents the result it signifies; green is pass, bright yellow is neutral, grimey yellow is softfail and red is a hard fail.
Apart from being useful to check your SPF records, because I used the open-source library visjs, it’s also incredibly fun to play with. Each node has gravity and all edges are springy. Apart from the physics, it’s also fun to map out some domains and see all the different IP-addresses that are included in their SPF record.
Food for thought here: By allowing so many different providers (IP-addresses) in your SPF record, an attacker only has to compromise a single server in all that address space in order to succesfully allow a mailserver to accept his email as being from you.
Mail is hard
Obviously, the biggest reasons for acquiring a domain name are 1) having your own personalized e-mail addresses and 2) showcasing your personal website. For both these reasons, getting the basics working is a piece of cake. Getting things working properly, though, is a completely different story.
Since I acquired my VPS (Virtual Private Server – a virtual server that hides somewhere in the cloud) and had it set up right, with a webserver running in an LXC container, it was time to set up the e-mail part. Following along with tutorials online wasn’t very hard and before I knew it, I had e-mail set up. As I, wrongfully, remembered “reputation” seems to be a thing, I opted to relay all mail through my hosting provider since their reputation would hopefully be better than a fresh SMTP server. After checking whether logging in worked and running some free online tests against the server, I was satisfied that everything was okay.
A couple days later, however, I realized I forgot to set up IPv6 records in the DNS for the webserver and logged into the administration console. The first thing I saw when I logged in was that I had sent 1.007 mails in the last day… I had been hosting an “open relay” for a few days. Checking some popular blacklists (more like gray-lists), it was obvious I had been aiding spammers and my IP-address was blacklisted on a large number of them. Instead of messing with the settings, I opted to just remove the routing to the mailserver to put an end to it immediately. Later, I did some research on how to properly set up a postfix server, but somehow all of the tutorials I found were lacking on one point of the other.
Frustrated with this new development, I decided I would write my own MTA (Mail Transfer Agent). At the time of writing, I’m still working on it, slowly adding more and more features.
This brings me to my point: doing mail properly is hard!
A non-techy person would describe mail as filling in the recipient, writing a subject and writing the mail itself, followed by pressing “Send”.
Simple Mail Transfer Protocol
When I first learned about SMTP, I was having a lot of fun sending all my friends emails from “santa@north.pole” and they would have no idea what was happening. In time, however, there’s been a patchwork of security measures added on top of the 1982 specification, one of which is a completely new specification for SMTP, released in 2001.
In the very basics, sending an e-mail through an SMTP server is the easiest thing you can imagine, all commands are legible and logical, see the next example of me delivering a mail “by hand” to a receiver. As most people think, SMTP is not just the outgoing mail protocol, but the same protocol is used for receiving emails for your domain. In that case, the sender‘s SMTP server connects to the receiver‘s SMTP server to deliver the mail.
First, we need to find out what server to deliver our test e-mail to. This information, like virtually all e-mail meta-information, is stored in a DNS entry for the receivers’ domain. These records are called “MX” (Mail eXchange) records. To find such a record on a Linux machine, we use the dig command;
|
1 2 3 4 5 6 |
$ dig mx gmail.com +short 5 gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. |