How I Learned to Stop Worrying and Love the RFCs, Part II

By Dan Horne, Software Engineer
Revelry

In our first post in this two-part series, we explored RFCs, specifically those that laid the foundation for our modern, online existence. We also looked closely at DNS, the king of internet naming.

In today’s post — aka Part II — we’ll dig into SMTP, the court jester of email delivery, and how DNS and SMTP became an indomitable cybercrime-fighting team through innovations like SPF, DKIM, and DMARC. And, yes, RFCs will continue to be a part of our story.

The Birth of SMTP

In the ancient days of the internet, also known as the 1970s, email messages were forced to travel across networks via multiple archaic, incongruent, and poorly documented protocols. It was email anarchy!

But then, the Internet Engineering Task Force declared in RFC 821: “We shall create a standardized approach to email to unite all the protocols!” And thus, Simple Mail Transfer Protocol (SMTP) was born.

How SMTP Works

SMTP is like a cyber postal service, making sure your emails get delivered from Point A to Point B. Here’s how this digital mail magic happens:

First, there’s the Mail Transfer Agent (MTA) — Think of this as the bovine email carrier lugging your message from the sender’s mail server to the recipient’s mail server across the dusty internet trail. Unless you’re sending to someone else on the same domain, there will usually be at least two MTAs involved in any email exchange, the sender and the recipient MTAs; often there are more. The sender may connect to an edge relay server that does the actual sending, and that edge relay server may connect to yet another edge relay server on the recipient network that does the job of accepting incoming mail. That server may then send the email to a filtering server before it is finally passed on to the server that hosts the actual mailbox.

Generally, a sending mail server will connect to a recipient mail server on a well-known port like port 25, and they will have a conversation that goes something like this:

Sender: “HELO (or EHLO: senderdomain.com)” Hey, I’m from senderdomain.com!
Recipient: “250 Ok” yo, what’s up?
Sender: “MAIL FROM: theKidFromRed@example.com” I’ve got an email from this guy.
Recipient: “250 Ok” Alright, dude, who’s it for?
Sender: “RCPT TO: quickdrawMcGraw@gmail.com” It’s for that guy.
Recipient: “250 Ok” Yeah, ok, I might know who that is…
Sender: “DATA” Are you ready for the message?
Recipient: “354” Hang on, lemme grab a pen. Ok, shoot!
Sender: Ok, the message says “let’s grab a beer”
Recipient: “250 Ok” Got it. Is that all?
Sender: “QUIT” Yep, talk to you later!
Recipient: “221 Ok” Sure thing. Hang loose!

Once the recipient mail server has accepted the mail, it will perform the next step in the email chain, whether that’s checking to see if it is spam, sending it to the next server down the line, or delivering it to the recipient’s mailbox.

Of course, the receiving mail server isn’t always nice. Sometimes it has to respond using the ancient SMTP error codes like:

550 — “Nah, I’m not takin’ that spam from you!”
500 — “Something’s not right. I think I broke something!”
And others defined by (you guessed it) RFC 5321.

SMTP Security Upgrades

As email escalated from a casual hobby to a modern day communication necessity, the SMTP protocol had to be fortified with some cyber-age security.

SMTP is a plain-text protocol. This means you can technically use any old telnet client; connect to an email server on port 25; and type in the SMTP commands to send an email. This is not very secure, so STARTTLS and SMTPS were created to encrypt the whole email pipeline. Other extensions were created to verify senders, scan for malware, and kick out anyone trying to spam our inboxes.

So let’s raise a glass to SMTP! The crusty, but trusty internet protocol that’s been wrangling our digital mail for more than 40 years!

DNS + SMTP = One Dynamic Duo!

Buckle up! It’s time to take a look at how DNS and SMTP work together in the most wonderful of ways. Imagine them as the dynamic duo of the internet, like Batman and Robin (but without capes and with protocols).

How SMTP Relies on DNS

SMTP relies on DNS because when you hit that send button on your email, your trusty email client needs to figure out where to deliver your message. So, it turns to DNS for help. DNS has these little gems called Mail Exchange (MX) records, which tell your email client which servers are responsible for handling incoming emails for a particular domain. (RFC 5321)

Improving Email Security and Verification

We all know the internet is filled with spammers. While spam wasn’t a problem in the early days, over time it’s become a big problem. This is where SPF, DKIM, and DMARC come in and save the day!

Sender Policy Framework (SPF) is like a VIP list for email servers. By using DNS TXT records, it tells the world which servers are allowed to send emails on behalf of a domain. So, when an email is sent, the receiving server checks to see if the sending server is on the approved SPF list. If it’s not, it’s like showing up to a party uninvited — no entry for you! It’s a simple yet effective way to weed out those pesky imposters trying to crash the email party. (RFC 7208)

DomainKeys Identified Mail (DKIM) is like the digital equivalent of sealing your letter with a wax stamp, except it’s way cooler and much more secure (RFC 6376). Here’s how it works:

1. When you send an email, your mail server slaps on a digital signature using a private key. It’s like signing your name at the bottom of a letter, but with cryptographic magic. This signature is stored in the email’s header and contains a unique identifier for your domain.
2. When the email reaches its destination, the receiving server retrieves your domain’s public key from (you guessed it) DNS. It’s like the recipient unlocking your digital wax seal using the key you provided.
3. Once unlocked, the receiving server compares the signature with the email’s content. If everything matches up, it’s like receiving a letter with the seal intact — you can trust that it hasn’t been tampered with on its journey through cyberspace.

Domain-based Message Authentication, Reporting & Conformance (DMARC) is like the wise old sage of email security, defining policies for how receiving servers should handle emails claiming to be from your domain (RFC 7489). Here’s how it works:

1. You publish a DMARC record in your DNS that tells the world what to do if an email fails SPF or DKIM checks. So, when an email arrives at its destination, the receiving server checks for your DMARC record. If the email passes SPF and DKIM checks, it’s smooth sailing to the recipient’s inbox. But if it fails, your DMARC policy kicks into action. You can instruct the receiving server to reject the email outright, quarantine it for further inspection, or just let it through with a warning flag attached.
2. DMARC is also a master of reporting. It collects data on how your email domain is being used and sends regular reports on who’s sending emails on your behalf. It’s like having a network of spies reporting back to you on any suspicious / imposter activity.

How It All Works Together

Picture this: You hit send on your email, and it’s on its merry way through the interwebs. First stop, SPF checking. The receiving server checks if the sending server is on the approved list. If it passes, we move on to DKIM, where the email’s integrity gets a digital thumbs-up. And finally, DMARC steps in to enforce the recipient’s policy, ensuring only the most trustworthy emails make it into their inbox. It’s like a relay race where each runner passes the baton smoothly, ensuring the message reaches its destination safe and sound. (RFC 7208, RFC 6376, RFC 7489)

Benefits of DNS/SMTP Integration

With DNS and SMTP holding hands like long-lost pals, we get improved email security, fewer spammy surprises in our inbox, and significantly fewer impersonation shenanigans.

Embracing the RFCs: The Cool Side of Email Protocols

Now that we’ve journeyed through the wondrous world of DNS and SMTP, let’s take a moment to appreciate the unsung heroes behind it all: RFCs. Yes, those seemingly mundane documents hold the keys to the kingdom of internet communication, shaping the very protocols that keep our emails flowing and our inboxes safe from harm.

Think of RFCs as the blueprint for the internet, written by brilliant minds who dared to dream of a world where emails could soar through cyberspace with ease. From the early days of SMTP (RFC 5321) to the innovative advancements in email security like SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489), these documents truly are the backbone of our digital age.

But Why Should You Looooooove RFCs?

First off, RFCs are the ultimate nerd treasure trove, filled with fascinating insights into the inner workings of the internet. They’re like a peek behind the curtain of the digital realm, revealing the secrets of protocols and standards that keep our online world spinning.

Secondly, RFCs are the product of collaboration and community, with experts from around the globe coming together to share their knowledge and push the boundaries of what’s possible. It’s like a worldwide brainstorming session where the best ideas rise to the top, shaping the future of technology one document at a time.

And let’s not forget the sheer cool factor of RFCs. These documents have quirky titles, like “There’s No Place Like 127.0.0.1” (RFC 5735), and are filled with witty banter and inside jokes that only true internet aficionados can appreciate. They’re like Easter eggs hidden in the digital landscape and waiting to be discovered.

So, go on! Embrace the RFCs, my friends, for they are the true champions of the internet age.

Want to chat about this — or any tech topic? Let’s connect. We love this stuff!

This blog post first published on May 29, 2024 at https://revelry.co/insights/rev-twil/how-i-learned-to-stop-worrying-and-love-the-rfcs-part-ii/