SMTP: How we've been sending digital letters since 1982

If there’s one thing that terribly fascinates me about computer science, it is not the latest JavaScript framework born last night and already obsolete this morning. No. It is persistence. It is the ability of certain technologies to remain immobile while the world around them swirls madly.

Today we talk about one of these monoliths. We talk about SMTP (Simple Mail Transfer Protocol).

While we worry about graphical interfaces, generative AI, and voice assistants, down there, in the dark foundations of the Internet, there is a protocol written in the 80s that continues undeterred to sort billions of messages a day. It is the tireless postman of the web and, surprisingly, it works exactly as it did forty years ago.

In this article, I want to take apart the toy. We won't limit ourselves to saying "press send and it goes". We'll go and see what happens when a data packet leaves your computer upon sending an email, how it navigates the network, and why, despite everything, email remains the only true decentralized protocol we still possess.

The architecture of the postal service

Before getting our hands dirty with commands, we must understand who the actors on stage are. When you send an email, you aren't throwing a stone directly into the recipient's window. You are entrusting a letter to a well-defined assembly line, where each actor performs a single task but in synergy with all the others.

We can divide the process into three fundamental actors: MUA, MTA, and MDA. Once you understand these, you've understood the entire global email system.

1) Mail User Agent (MUA)

This is your email software. Outlook, Thunderbird, Apple Mail, or the Gmail web interface. The MUA is what allows you to write the text of the email and press send. Its job ends almost immediately: formatting the message and passing it to the next level.

2) Mail Transfer Agent (MTA)

Here we enter the realm of servers. The MTA is the real SMTP engine (software like Postfix, Exim, Sendmail, or Microsoft Exchange). When your MUA passes the mail to your MTA, it takes charge of finding the way to the recipient and delivering the mail. If the recipient is on the same server, delivery is local and immediate. If they are elsewhere (like a @gmail.com address while you are on @hotmail.com), the MTA must go out onto the Internet and look for the recipient's server.

3) Mail Delivery Agent (MDA)

This is the last mile. Once the mail has arrived at the destination server, the MTA passes it to the MDA (software like Dovecot) which has the task of taking that mail and inserting it into the recipient's mailbox, waiting for them to come and read it.

A textual protocol

The beauty of SMTP is that it is a textual protocol. There are no incomprehensible binary codes nor obscure cryptographic handshakes (at least not in the basic version of the protocol).

If you were to observe the commands exchanged between the actors involved, you could almost literally read the server messages in English.

To see this dialogue with your own eyes, we can use an "ancient" tool called Telnet. Telnet is a network protocol that allows establishing a command-line connection with a remote server. To put it very simply, it opens a direct channel where you can write pure text commands and see the server's responses, without any graphical interface in between.

Let's imagine we want to send an email to mario@example.com starting from our server. In the following examples S is the message the recipient's server sends us, while C is our server. Here is what happens, line by line, in a simulated session:

Our server knocks on Mario's server door.

S: 220 mail.example.com ESMTP Postfix

Mario's server replies: "Hey there, I'm ready. I am the Postfix program". That code, 220, is the green light. "Service ready".

Our server must introduce itself, and it does so by sending the HELO command followed by the mail server name.

C: EHLO mail.foo.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 8BITMIME

EHLO, written like that, is not a mistake but is the "Extended" version of the old HELO command. By saying EHLO, the remote server replies with a list of features it supports: "I accept attachments up to size X", "I speak encrypted (STARTTLS)", etc. The code 250 always means "Everything OK".

Now we declare the sender of the envelope using the MAIL FROM command. Attention: this is what is written on the envelope, not in the letter. They are two different things (and we will see later why this causes spam problems).

C: MAIL FROM:<riccardo@foo.com>
S: 250 2.1.0 Ok

The remote server notes: "Good, this message comes from riccardo@foo.com".

Who is the envelope intended for? With the RCPT TO command, we specify the recipient.

C: RCPT TO:<mario@example.com>
S: 250 2.1.5 Ok

Here the server does a first check on the validity of the destination address. Does the user Mario exist? Is his mailbox full? If Mario didn't exist, we would receive a 550 User unknown and the conversation would end here. Instead, we receive another 250 OK, so we proceed.

Now comes the fun part. We tell the server that we are about to dictate the content of the email using the DATA command.

C: DATA
S: 354 End data with <CR><LF>.<CR><LF>

The server tells us: "Write away. When you are finished, put a single period on a new line". Now we insert the Headers (the actual letter header) and the Body of the message, followed by a single period.

C: Subject: Greetings
C: To: Mario <mario@example.com>
C: From: Riccardo <riccardo@foo.com>
C: Date: Tue, 03 Jan 2026 10:00:00 +0100
C:
C: Hi Mario,
C: This is a message for you!
C: .

The remote server processes the received message, saves it to disk, and gives us the receipt.

S: 250 2.0.0 Ok: queued as 832A912F
C: QUIT
S: 221 2.0.0 Bye

Done. The mail has departed. No magic. Just ASCII text traveling over a network connection.

DNS and MX records

But let's take a step back. How did my server know which IP address to knock on to find Mario? I only wrote mario@example.com.

This is where DNS (Domain Name System) comes into play. usually, we think of DNS as the phone book of the Internet which translates easy-to-remember names (like google.com) into numeric IP addresses (A Record) necessary for computers to communicate or make requests. But for emails, we don't look for the generic web server address, we look for the specific address of the post office competent for that domain, that is, the MX record (Mail eXchanger).

Basically, when I send an email my server queries the DNS: "Hey, who handles mail for example.com?". The DNS responds with a priority list:

10 mail.example.com
20 backup.example.com

The number indicates priority. My server will try to contact the first one. If it doesn't respond (timeout, server down, zombie apocalypse), it will try with the second. This intrinsic redundancy is one of the reasons why emails are so resilient. If the main server falls, the mail is not lost: either it is delivered to the backup server, or it remains in my server's "queue" which will retry delivering it at regular intervals for several days.

Spam and Spoofing

If you have read this article carefully up to here, you will have surely noticed a GIGANTIC flaw.

In the MAIL FROM command, I can write whatever I want! I could connect to the recipient's server and say MAIL FROM:<president@whitehouse.gov> entirely legitimately.

In 1982, this was not a problem. The Internet was a club of gentlemen and academics. Today instead it is the Wild West and this vulnerability is the basis of Spoofing and Phishing.

To put a patch on a protocol born too naive we haven't modified the SMTP protocol, but over the years we have built security superstructures. Today methods exist that significantly reduce the possibility of mail tampering:

SPF (Sender Policy Framework): It is a DNS record that says: "The only IPs authorized to send mail on behalf of whitehouse.gov are these: 1.2.3.4". If the mail arrives from a different IP, it is a fake. It is like a bouncer with the guest list.
DKIM (DomainKeys Identified Mail): Here we use cryptography to sign the message. The sender's server affixes a digital signature to the email header, writing the public key in the DNS. The recipient's server, receiving the mail, retrieves the public key from the DNS and with that verifies the message signature. If the mail was tampered with during the journey, the signature breaks.
DMARC: It is the boss of the other two. It tells the recipient's server what to do if SPF or DKIM fail. "If the signature is invalid, throw everything away", or "Put it in spam and send me a daily report".

Without these three security systems, your email today wouldn't even arrive in Gmail's Spam folder. It would be rejected at the door.

Why not host a mail server yourself?

We arrive at the sore point. The theory is beautiful. Installing Postfix on a Linux VPS takes 10 minutes and configuring Dovecot another 10. In half an hour you have a working mail server.

But working does not mean reliable.

The real problem today is not sending the mail but convincing other servers to accept it because the big players (Google, Microsoft, Yahoo) have raised very high walls to protect their users from spam.

If your IP is new and has no "reputation", your emails will be rejected or will end up directly in spam, and building a reputation is a slow and painful process.

That is why, while loving autonomy, I often recommend using professional external relays (like SendGrid or AWS SES) for sending emails, perhaps maintaining mailbox management locally. This might be the right compromise between data sovereignty and operational pragmatism.

Survivor

In conclusion, we can safely affirm that SMTP is a survivor. It was born in an era where bandwidth was precious and trust was implicit. Over the years it has been abused, patched, extended, and armored. Yet, it is still there.

Every time you hear the notification sound on your phone, remember that behind it there was that ballet of "HELO", "MAIL FROM", "RCPT TO" that has been happening tirelessly for more than forty years.

In a technological world that suffers from planned obsolescence, studying SMTP is almost digital archaeology, but it is living archaeology. It reminds us that simple things (or rather, standard things) are the ones that last. And perhaps, in this, there is a lesson also for how we should build the software of tomorrow.