Tyler's Site

Abstract

Learning to run and maintain an email system can be a daunting task, especially for a young IT professional that potentially did not use email before starting their career (me). That are a lot of prerequisite skills that are required to get the service to run at all, then there are more pieces of knowledge that must be sprinkled in to make the service actually useful (by getting mail delivered and blocking spam). I did a write-up on getting email setup on a previous blog post, however, that post did not really explain any of the logic that went into setting up an email server. This article intends to provide that basic overview of how the various pieces of email fit together to make a working system. It is also worth noting that this post will not go in-depth on configurations for anything as this is supposed to be a general overview; many of the configuration items that are required can be found online for the platform you are using. Additionally, I will have more resources that go more in-depth on email at the end of this post.

Prerequisite Skills

As eluded to in the intro paragraph, email is built on various other skills that are critical to being able to run a successful mail service. These skills are:

Basic Requirements for Email Server

In earlier days of the Internet, the list of requirements for running an email server was pretty short. You basically just needed a server, a domain name, and some software to send and receive email (SMTP and POP3/IMAP server). Once that is setup, then you can be on your way sending all the email that you want. Technically that is still the case; however in practice, the requirements are a bit higher today for emails to actually be received by major providers such as Gmail, Yahoo, and Outlook/Hotmail.

Hard Requirements

This list is a minimal list of requirements to have the technical capability to send and receive email.

Soft Requirements

While these items are not technically required to have mail sent to another email server, for the mail to actually be accepted and received by other email servers on the Internet, these requirements must be met.

Checking your records

Once you think your records are setup for your email domain, it is then time to check it using online tools. This Email health tool from MX Toolbox is a very solid one that will show a lot of information about your email domain and point out issues that should be addressed. Example output from my mail server:

MX Toolbox Health Check for Foxide.xyz

It is highly recommend to make sure the checks on this health check tool pass before changing SPF to hard-fail and DMARC to reject or quarantine as improper configuration of DNS records can affect mail deliverability. If something is not setup correctly on the DNS records, MX Toolbox will very helpfully offer some additionally info to clear up what the problem might be.

Handling Spam

Most people hate email spam; and the reasons for this are two fold. The obvious reason is because you have to deal with the spam in your email box. However, the second reason is that email spam has been a huge driving force to make email the headache that it is today. The idea was that by having email providers declare where email will come from and showing some validation that it was really sent from their email server (SPF and DKIM) it would cut down on spoofing and spam. The ironic thing, is that spammers tend to have the best SPF, DKIM, and DMARC records, and will generally allow anyone to send email on their behalf, and will actively tell other email server to ignore DKIM.

Spam filters

Since SPF, DKIM, and DMARC do little to prevent spam, the option is an email spam filter. While this isn’t required per se, in reality this is something you will likely want sooner or later, especially if your email domain is associated with a business. Spam filters come in software form or a hardware appliance; each of the different options for a spam filter will work slightly differently, however, in general spam filters will analyze incoming email and give it a spam score. This score will determine whether the email will be considered spam by the filter; in addition to this, actions can be setup on a tier system, so an email with a lower score could be handled differently than an email with a higher score.

To determine the spam score of the incoming emails, various parts of the email will be analyzed including:

The last point is the one that can be really difficult to get around if you run your own mail server. Specifically, entire IP ranges can get blocked because too much spam was being sent; this will affect the entire IP block’s ability to send email. Microsoft did this to Linode, and was not very helpful in resolving the issue until much, much later. And, even when they did fix it, it was only silently.

Dissecting Email Headers

Many spam filters look at email headers for information about the emails to attempt to determine whether they are spam or not. Unfortunately, email headers are roughly as readable as compiler output and can look like a wall of information if you haven’t worked with them before. Here is an example email header that we will be working with:

Again, massive wall of barely parsable (by a human) text. So, let’s look for our basic information and go from there.

There is still a lot of information there, but it should look a bit less intimidating and some of the fields may even look obvious. For example, Delivered-To, is the email address that the email was delivered too. The subject, is the subject of the email, etc. Some of the things that might look slightly less straightforward are going to be things like the Received-SPF and DKIM-Signature. In the case of the Received-SPF:

We can tell that the message passed SPF because of the pass toward the beginning of the line. That is auto echoed in the section for Authentication-Results. That section also shows that DKIM was passed as well, Then at the bottom of the Authentication-Results we see the line dmarc=pass then some more information on what the email is supposed to do if DMARC is not passed. This means that this email has passed the three main email authentication requirements. Past that, we also get a specific time stamp the email was received, along with a Message-ID to better track down the email if we need to look for it.

Great, but what was the other stuff that got removed? Some of it was junk that doesn’t really affect anything. That is pretty much any line that starts with X-. Those headers are not standardized, and thus can kind of be made up by the email composer. The other interesting section is the ARC-Authentication-Results. Authenticated Received Chain (ARC) is a method of validating email that could be changed by a spam filter. Some spam filters will modify an email’s headers, and this modification can cause the email to fail DKIM when it gets through to the user. ARC fixes this by allowing intermediate servers to sign off on the original validation results. This helps prevent authentication issues, and increases deliverability.

Resources

Email is a topic that has a lot happening all at once, and is not really something for people just getting started with IT. It has a lot of concepts that you really should know before jumping in, and there are a lot of things that must be done correctly for it to actually work. Unfortunately, it is also a moving target. What works today, may not work tomorrow if the big mail providers change their mind on something. This blog post is not intended to be an in-depth tutorial on anything, rather, just a primer to get familiar with some of the different aspects of email and a general idea of how they fit together. If you are interested in running your own mail server, I have included some resources that I highly recommend checking out before doing so: