It's Summer, So Don't Forget That SPF!
Summer, the slow season for many administrative offices, leaves little to do for the general tech-support employees. Some might argue that we're really working at all. Now, when I say this, I don't mean it as an across the board comment. Of course there are many IT professionals working their asses off as you read this, making sure that everything works smoothly the first time. Though for me personally, summer means waiting for the next user error to pop up in our ticket feed. Exciting, right?
It being so slow I started to really think about what I had done with my professional career and how it could be expanded upon. Trying out the whole system admin thing has been fun, but it's not like I really have much to monitor. With that in mind, I started reading about other admins, which lead to reading about other systems, which lead to reading about Google, which lead to reading about security, which lead to reading about how we don't really have all that much control over what we use on a daily basis. It suddenly clicked why so many corporations use in-house services instead of just pre-setup services like Gmail and Comcast mail.
The thing is, we don't have control over what we use. We don't own our email. If someone acquires your email password and reads your mail, you're not protected under the federal law that says it's a felony to open others mail without express permission. If you house your email in-house and someone hacks in, you can still legally protect yourself because hacking into an unauthorized system is itself illegal. (Disclaimer- I am not a lawyer, take everything I say with three grains of salt)
This whole time I've been using other people's systems. These were free services, such as Gmail and cpanel (which, to be fair, was forced unto me by my old server hoster, which I no longer use (we good!)). I figured, if I encrypted my emails using PGP that that would be enough. What if, though, they got hacked?
Don't get me wrong, there's no one I trust more to keep my data safe than Google. A company that big could not afford to get hacked, because they're seen as the giant in the industry, the biggest. They could make companies disappear overnight if they wanted to, and I'm convinced that the only reason they're not evil is because they're already making so much money. But what if they did? What if Google was compromised and my data leaked and placed out on the web like you see with minecraft accounts every other week? What could I do about that?
Nothing.
I'm not trying to say that free email accounts are insecure and you shouldn't use them. Am I going to stop using my three gmail accounts? No. No I am not. I love my gmail accounts and they are my babies. What I'm saying is, maybe it wouldn't be too bad to have my own mail server. One I set up and have complete control over.
So with the help of a few reference here and there, and a lot of help from my good friend Eric, I set out to do what many have so fervently claimed to be "the worst part." And you know what? It wasn't so bad. Eric explained to me that you can't just set up a server and call it a day. In fact, he got on my ass about my SPF records on my other domains – to which I asked – "SPF, like the sunscreen?"
This is the part of the post where I take a step back and say that without my friends I would be nowhere. Eric has taught me so much about numerous different fields of computers. He got me into researching PGP, secure web development, preventing SQL injection, in-house solutions which lead me to researching more and eventually contributing to FOSS - he really is one intelligent guy and if you have a minute go check out his stuff.
To my understanding, there are four parts of having a secure mail server in terms of not becoming susceptible to spam, and to my surprise they all have to do with DNS. You have your SPF, your DKIM, and your DMARC; all of these are TXT records in your zone file. Then you have your MX record, which just lists the mail server address on the domain. Still with me? Good, let's break it down some more.
MX
If I send an email to "colin@colind.me", my mail server will reach out and look at the DNS records for colind.me. From there it will check the Mail Exchange (MX) record to see where exactly it should be sending the mail. In my case, the MX record was just colind.me. 1800 IN MX 10 mail.colind.me., and was definitely the easiest and fastest part of the setup. Breaking that down further, it's the domain, the TTL is 30 minutes (1800 seconds), and the MX is located at mail.colind.me with the priority of 10.
SPF
The Sender Policy Framework record is there to specify who can send mail from that domain. The best policy if you only have one domain is probably "v=spf1 mx -all". v=spf1 just means it's declaring the TXT record as an SPF record. mx is taking the place of a server – it's saying that only the MX record holders can send out mail. Alternatively, you can declare a server using ipv4:40.50.60.70 replacing the IP with your own server address, of course. ipv6: also works here. The -all just means that no one else can send mail from this domain.
DKIM
DomainKeys Identified Mail are how your recipients know that what you're sending them is legitimate. The DKIM record is there to provide authenticity and verification that the mail being sent out is actually from you. Your outgoing mail is signed using keys that are also placed in your DNS via a TXT record. They look something like mail._domainkey.colind.me 1800 IN TXT "v=DKIM1; k=rsa; p=reallylongkey" in your zone file. It's similar to how PGP works; mail gets signed, dns checks it – if it passes, it says so in the header, if it fails, it says dkim=failed in the header. This is important, but it doesn't really do anything without probably the most important record...
DMARC
Setting up DMARC (Domain Message Authentication Reporting & Conformance) was the part that gave me the most trouble solely because of lack of extensive documentation and full examples. I recommend using a DMARC generator instead of writing one yourself. DMARC tells your mail client what to do with the email if it has failed the previous checks. It absolutely needs SPF and DKIM set in order to work. If you have your DMARC policy (p) set to quarantine (for a total of p=quarantine), then your receiver is going to put that forged message into their Spam folder. I think that dmarc.org explains it easily in their overview flowmap. Using DMARC, you can have reports sent to you, the postmaster, using rua=mailto:. The difference between rua and ruf (both standard switches) is that rua is reporting uri aggregates and ruf is reporting aggregate forensics. What confused me the most about DMARC though is the name. In the end, I ended up getting it to work by setting it to _dmarc.colind.me. IN TXT ... - it's seriously easier and faster to use a generator for this one.
By now I've explained what everything does and how it works as far as setting up the DNS end of the mail server. As far as the software went, I used postfix to host the actual mail server itself, and dovecot is working with it to actually integrate with mail clients such as Thunderbird and Outlook etc. Postfix itself is working with linux's accounts (/etc/passwd) to provide an inbox to every user that hosts an account on that machine - in my case, my server. In addition to this, it uses the machine's aliases (/etc/aliases) to set up "fake" email addresses that will get forwarded to another address. For example, one of the required addresses is "postmaster", which will get forwarded to "root" by default. I don't have a postmaster account on the server, and it's bad practice to use the root email. What you do in this case is forward your root email to you. So at the end of the day your server's aliases might end up looking like mine and having:
postmaster:root
root:colin
Adding aliases is as easy as editing this file and running sudo newaliases. Dovecot on the other hand was a little bit more of a headache for me, which is odd because it's supposedly the other way around. The lesson I learned that way is that sometimes you shouldn't copy the documentation word for word. Every system is different and should be configured to work best with that setup.
After I added in all the proper elements - email was finally working. I could send it, but my test emails still weren't being recieved. Something wasn't right. I was wondering what it was until I finally gave up and asked for help. Glitch (again, see how helpful he is?) said it might have something to do with the fact that I'm not being fully authenticated. Lo-and-behold, I wasn't being marked as an "authenticated" sender. This was patched up with an SSL certificate, which was probably the easiest part to install. All that needed to be done was to change the reference in the dovecot and postfix config files and restart the services with sudo service postfix reload && service dovecot reload. With that, everything was working.
Update 1/29/2019:
I still recommend that everyone at least try to set up a mail server at least once. It's a really informative process that takes a lot of the mystery out of how email works. However, if it's an email address you plan to be using for important contacts, bills, or any other kind of communique that requires consistency, I recommend having either a dedicated server with a failover policy for it, or entrusting the hosting and setup to a third party with a fleshed-out contract and a plan in place for if the worst occurs.