Email Protocols

Email and DNS

Here's an example of an email address: example at technosurge.com. What it knows is that this is a user that it's trying to access, and this is the domain that that user is supposedly a part of. What it needs to know is what server out there will be answering, or will be receiving, mail for technosurge.com.

So it has to do a DNS lookup and ask for an MX record — it needs to know the MX record for technosurge.com. It will go through the domain name system, through that process of looking up who belongs to technosurge.com, and ask for the MX record. It will receive that MX record, and now it knows where I need to send this email off to. Then when it gets to the other side, that mailbox server is going to look at that user and determine what user it needs to go to.

Mail delivery at a high level

Let's take a high level look at how this mail gets transferred. We have two users here, and this user wants to send mail to this user right here. Both of these are the mail user agent, or the MUA. We're going to be sending from this MUA to this MUA.

What it needs to do is, this MUA has a connection to, or knows of, the mail submission agent it needs to send mail to. A mail submission agent is where you submit mail into, so this MSA, or mail submission agent, accepts mail.

From there it's going to transfer it to a mail transfer agent. The mail transfer agent is designed to get it to its destination, where it needs to go. This is the machine that actually does the lookup and tries to figure out what the MX record is for the domain that you're sending it to. So it looks it up, determines what the server is that it needs to go to, and then relays that email to it.

This is what's called a mail exchanger. The mail exchanger is what accepts mail on behalf of a domain. So in this case, this mail exchanger is accepting mail on behalf of the domain that this user is a part of. It accepts that and then transfers it to a mail delivery agent, where it's going to reside until this mail user agent gets on and pulls that email down — does a retrieval process and pulls that information down. So that is the flow that happens throughout here.

Some of this can be combined into one server. What I mean by that is this mail submission agent and the mail transmission agent could be one server, or it could be multiple servers. Sometimes it depends on the size of the organization, and that depends on how much they split these individual roles out and get them separated out. But essentially those are the components that are needed to get mail from one location to another.

SMTP

How do we move this mail around? One way is through SMTP, or simple mail transfer protocol. Simple mail transfer protocol operates on TCP port 25.

SMTP is a way for one device to transfer mail to another device, so think of it more as a push. It's a push of mail from one device to the next. In this diagram, when we were looking at it, we said that the mail user agent pushed that email to the mail submission agent, which pushed it to the mail transfer agent, which pushed it to the mail exchanger, which pushed it to the mail delivery agent. All of those use SMTP or SMTPS for transferring that data. We usually like to use SMTPS, but there are still some servers out there that use SMTP, and a lot of servers will still accept mail through SMTP. That is where SMTP is used: to push that mail along from device to device until it gets to the mail delivery agent.

POP3 and IMAP

So then we're asked the question: how do we get it to the end user? How do we get it to the mail user agent? To do that, it's more of a poll or a sync, depending on what protocol you're talking about.

POP version 3 is a way for this user agent to reach out to the server and say, "Do you have an email for me?" and then it pulls it down to the client. Think of it as the client actively going and grabbing the information and pulling it down. Because of that, we don't have a copy now on the mail delivery agent. There is a way to say, "Hey, leave a copy on the agent." But where I'm going with this is that POP version 3 is a great way to retrieve mail, but it has definite limitations. That's where we're going to get into our next protocol.

IMAP is more of a sync between the mail delivery agent and the mail user agent. It syncs back and forth. What I mean by this is that the mail user agent establishes a connection to the mail delivery agent, and they're constantly contacting back and forth seeing if there are any updates. If I'm sending data, then it will make that connection and send the data; or if I'm receiving data, it will make that connection and receive the data. Think of it as a much more dynamic, open connection between the two.

The advantages of this are things like: I can create folders and move data around from folder to folder. If I were to do that when I was using POP version 3, I would move it into a folder, but it wouldn't appear that way on the mail delivery agent — it would just keep it where it was, in the same inbox. Versus if I do that on the mail user agent that uses IMAP, then it will sync the two up, so that it moves the mail on the mail delivery agent as well, into a folder. So it's a way to create a more dynamic connection.

Webmail

One reason why we would want the mail delivery agent to always be updated is because we also access webmail. If the user is accessing, or has a client, and is making that connection, and all of that information is getting updated on the server, then if I go to my mobile device, or if I go to a web browser, or other devices that are connecting in, everything is going to be updated, and so everything is going to have the most updated information.

Webmail is one of those examples. I could get onto my mailbox and be able to see my inbox and see the folders within it, accessed through webmail. So webmail is another way of accessing those resources, and webmail is accessed through HTTPS. I can use it through a web browser and access the mail. That is what webmail is.

SPF records

The SPF record is to make sure that whatever mail transfer agent is sending the mail is supposed to be sending that mail. Let me give you an example. Let's say this mail transfer agent is sending to the mailbox exchanger, and it's sending mail that's something atample.com — so it's sending mail on behalf of example.com. This mailbox exchanger really doesn't know the validity of this server right here. So what it will do is go and look up the SPF record that exists in the example.com domain. We'll do the DNS lookup, look at example.com, look at the SPF record and say, what are your servers that should be sending mail? Then it will take a look and see if the IP address, or if the name, of this server should be sending that mail or not. If it is acceptable, if it is on the SPF record, it's more likely to accept that mail and less likely to label it as junk mail.

There are a couple of things that we can actually do when it gets that information, when it realizes this came from a server that's in or not in the SPF record. It can handle it many different ways, and we can actually specify how it handles it. For instance, if it receives mail from a server that's not supposed to send mail for that domain, then what it could do is put that in the junk folder, or label it as possible spam, or it can treat that message differently. A lot of times we don't just automatically assume that it's wrong, because there's a lot of mail that's being sent from a lot of different servers out there. So a lot of times we don't automatically assume that that is bad mail, but it labels it as more likely that it is bad mail.

That's what an SPF record does essentially. An SPF record is a check to see whether whatever server is sending the mail is the server that should be sending the mail from that domain — is it representing that domain?