Hi students, welcome back to class. We started the school year pretty early so we’re already in the swing of things.
Let’s jump into the next lesson.
We’re moving on from the more basic concepts of email, like best practices, how to get to the inbox by protecting your reputation, and so on…so buckle up for Email 102. We’re talking about how email actually WORKS.
Since there’s no way I can explain this or even wrap my mind around what happens after I hit “send” and then immediately have a panic attack, I asked SocketLabs’ CTO and co-founder Bill Volz to explain the first method of sending email. So…
Bill, Teach Me Email: What is SMTP?
[Get ready for a moment of zen; Bill has a very soothing voice.]
Timestamps
0:15 – What is SMTP?
0:45 – The systems within SMTP
1:25 – The responsibilities of each system and how they work
3:41 – How to configure SMTP
4:12 – Benefits of using SMTP
5:09 – Downsides to using SMTP
5:27 – Potential ways to resolve latency
Your Acronym Cheat Sheet
Having a list of the most important systems in an email’s journey is super helpful. Here’s a handy guide to all the acronyms Bill mentioned to get you up to snuff ASAP, OK? I added a little bit of context to each to make it even more robust.
- SMTP: simple mail transfer protocol
SMTP is a protocol that was designed to allow mail systems to communicate with each other.
- MUA: mail user agent
The MUA is responsible for generating the email content, specifying the from and recipient addresses, building the email, and sending it off to be delivered.
- MSA: message submission agent
The MSA is responsible for listening for new connections on the network using TCP IP port 587 and authenticating the client.
- MX: mail exchange
The MX (via port 25) also listens for network connections, and the difference between MX and MSA is authentication.
- MDA: message delivery agent
This delivers the message to the end user’s mailbox, which is usually local storage.
- MTA: mail transfer agent
Unless MSA, MTA often does not require authentication for mail going to local users. There are two options here:- When sending to the final destination, it will use the email address domain of the recipient to look up the MX record in the DNS, find the host accepting mail for the domain, and forward for delivery.
- If not sending to the final destination, the MTA stores it then forwards on to the next destination.
Woah! That feels like a lot, but as you can see, they all work together.
How These SMTP Systems Flow Together
Bill showed us a graphic illustrating exactly how all these systems work in tandem to initiate and complete an email’s journey. You can click on it below to download a PDF version to keep.
Final Takeaways About SMTP
Personally, this makes more sense now. I get how SMTP works and all the things needed to actually to send and deliver mail. Beyond the nuts and bolts, there are a couple big takeaways from Bill’s expert analysis.
- SMTP is great for its compatibility and simplicity. It’s very common and doesn’t require a lot of other technical knowledge or information to send email.
- SMTP can be too latent for some senders. There are folks who want to send things today and get them delivered…well, yesterday, let’s say. This can be resolved using one effective method:
Install a local MTA. Most are multithreaded by design, so once you locally submit the messages (speedy without latency) it can open multiple connections to the destination and deliver them in parallel.
I hope this walkthrough of a technical concept was as helpful to you as it was to me. I better understand how SMTP can send and deliver email, and when I may or may not want to use it.
To learn more about SMTP and how SocketLabs can help you use it effectively and reliably, click the button below.
Transcript:
Hi.
My name is Bill Volz. I’m the CTO of SocketLabs and today we’re going to talk about the simple mail transfer protocol, otherwise known as SMTP.
SMTP is a protocol that was designed to allow mail systems to communicate with each other.
Its specification was documented in RFC 788 in early 1980s. Since then, it has been the primary protocol that messages systems use to discover and communicate with each other when sending email over the internet.
I think it would help to understand SMTP if we quickly review the responsibilities of these systems that are communicating with each other. The configuration of these systems is very versatile.
Today I’m going to focus on the primary scenario that most mail uses when it traverses the internet.
When it comes to SMTP and the internet email architecture, there are four main systems.
There’s the mail user agent (MUA).
The message submission agent (MSA).
Mail transfer agent or mail gateway (MTA).
And then the message delivery agent (MDA).
Let me just briefly go into each one and describe it in more detail.
Let’s start with the mail user agent or MUA. This is responsible for generating the email content, specifying the from and recipient address, building the email, and sending it off to be delivered. You could think of this as the mail client.
Now, the following systems are often packaged together and labeled as the MTA, but it’s still important to understand the responsibilities of each component.
So, the message submission agent, the MSA, is responsible for listening for new connections on the network using TCP IP port 587. It is responsible for authenticating the client. Now, this can be a username and password or a token or even the IP address of the system that initiated the communication. Once the MSA authenticates (authorizes) and accepts the message, it hands it off to the MTA.
Now, the mail transfer agent, or MTA, also listens for network connections, but uses port 25. The difference between this and the MSA is authentication. The MTA often does not require authentication for mail going to local users.
So, when the MTA gets a message and it detects a message is going to a local user, it then hands it off to the MDA, the message delivery agent. This is responsible for delivering the message to the end user’s mailbox. It’s usually some type of local storage.
If the message is not destined for a local address, it’s responsible for storing it and forwarding it on to the next destination.
Now, this destination could be another pre configured MTA, sometimes referred to as a relay, or it could be the final destination. When it’s sending to the final destination, it will use the email address domain of the recipient to look up the mail exchange in DNS, otherwise known as the MX record. It does this to find a host of the email accepting mail for that domain, and it will forward it on to it.
So, what does this mean for you as a sender?
Well, the biggest takeaway is whenever possible, you should configure your SMTP system to use submission port 587. This port is important because port 587 is used for client-to-server communication and is normally open on most firewalls, where port 25, which is used for server-to-server communication, is often blocked, most residential internet service providers will block port 25 without exception.
Now, what are benefits? Why would you use it instead of other methods?
Well, there’s a couple of reasons.
The biggest benefit is compatibility. I’d bet that every computer or server that you have used recently has some form of SMTP support built into it. SMTP is built into most development environments, which makes supporting it in applications very easy.
Any SMTP client will be able to communicate with any SMTP server using this protocol.
The other is simplicity. All you need is the username, password, host and port number to get it working. The protocol is simple, open, and widely used. If you change relays, all you need to do is change the configuration and you’re set. There’s no need to change code, plugins, or anything else.
Are there any downsides to using SMTP?
Well, the biggest complaint is latency.
The SMTP protocol requires several network round trips as it sends commands and receives responses. This will cause delays based on the response time of the remote host that you’re sending to.
One way to overcome this is to have multiple threads sending at the same time. But many applications won’t support this because it can make the code more complicated.
Another way I have seen senders overcome this is by installing a local MTA as a relay. This adds both performance and resiliency to your system while still being able to use your existing provider.
The great part is most systems make it really easy to install a local MTA. The two benefits you get from this is one, if your hosting provider ever has any outages, the store-and-forward concept of the MTA will retry the message automatically when your connection is restored.
Running a local relay will also improve your sending performance. Since most MTAs are multithreaded by design, once you locally submit the messages, which is fast without latency, it can open multiple connections to the destination and deliver them in parallel.
So, without adding any complex code, your mail is going out faster.
Using SMTP is a great option if you want to keep things simple and have things work right out the box.
Well, that’s all I have for today. Stay tuned for future episodes.
