1988: SMTP, POP3, and IMAP: The Three Protocols That Run Email

The internet is littered with the corpses of abandoned protocols. Gopher, NNTP, FTP for casual file sharing — technologies that once seemed permanent but were eventually superseded by the web. Email’s core protocols, however, have proved stubbornly immortal. The three standards that make email work — SMTP, POP3, and IMAP — were designed in the 1980s and remain in daily use by billions of people, essentially unchanged in their fundamentals. That longevity is either a testament to excellent design or an indictment of our inability to agree on something better. Possibly both.

SMTP: The Postal Service of the Internet

Simple Mail Transfer Protocol is email’s delivery system. When you hit “send,” your email client hands the message to an SMTP server, which figures out where the recipient’s mail server is (using DNS MX records) and transmits the message. It’s the digital equivalent of the postal service: it handles transport from sender to recipient.

SMTP was formally defined in 1982 by Jon Postel in RFC 821, though its roots go back to earlier ARPANET mail protocols. The specification is refreshingly readable — Postel was known for writing clear, concise standards — and the protocol is refreshingly simple. A basic SMTP transaction involves just a handful of commands: HELO (hello, I’m connecting), MAIL FROM (here’s the sender), RCPT TO (here’s the recipient), DATA (here’s the message), QUIT (goodbye).

That simplicity was both its strength and its Achilles’ heel. SMTP was designed for a small, trusted network where everybody knew everybody. It has no built-in authentication — it doesn’t verify that the sender is who they claim to be. It has no built-in encryption — messages travel in plain text. It doesn’t even confirm that the sender has permission to use the “From” address they specify. You can literally tell an SMTP server you’re president@whitehouse.gov and it will dutifully try to deliver your message.

These design choices, entirely reasonable for a 1982 research network, became catastrophic vulnerabilities when email went mainstream. The entire history of email spam, phishing, and spoofing is essentially the story of malicious actors exploiting SMTP’s naive trust model. The industry has spent decades bolting on fixes — SPF, DKIM, DMARC, STARTTLS — but the underlying protocol remains fundamentally trusting.

POP3: Download and Delete

Post Office Protocol version 3, finalized in 1988 (RFC 1081, later updated in RFC 1939), solved a simple problem: how does a user retrieve email from a server? POP3’s approach was straightforward — connect to the server, download your messages, disconnect. The default behavior was to delete messages from the server after downloading, on the assumption that you’d read and store email on your local machine.

This made perfect sense in 1988, when disk space on servers was expensive and users typically had one computer. You sat down at your desk, opened your email client, downloaded your messages, and worked with them locally. The server was just a temporary holding area.

POP3 is still around, but its download-and-delete model aged poorly. When people started checking email on laptops, then phones, then tablets, POP3’s architecture became a problem. Download your email on your laptop, and it’s gone from the server — so your phone shows an empty inbox. POP3 configurations can be set to leave messages on the server, but the protocol wasn’t really designed for the multi-device world. That’s where IMAP came in.

IMAP: Keep It on the Server

Internet Message Access Protocol, originally defined by Mark Crispin in 1986 and formalized as IMAP4 in 1994 (RFC 1730, later RFC 3501), took a fundamentally different approach. Instead of downloading messages to your local machine, IMAP keeps them on the server and lets your email client view and manage them remotely. Read a message on your phone? It shows as read on your laptop too. Create a folder on your desktop? It appears everywhere.

IMAP was ahead of its time. In the late 1980s, most people had one computer, server storage was expensive, and always-on internet connections were rare. POP3’s “download and delete” model matched the reality of the era. IMAP’s “keep everything on the server and sync everywhere” model didn’t become truly practical until broadband internet and affordable server storage converged in the 2000s.

Today, IMAP is the dominant protocol for email retrieval. Gmail, Outlook, Yahoo Mail, and virtually every other major email provider use IMAP (or proprietary equivalents like Microsoft’s Exchange ActiveSync) to keep email synchronized across devices. The shift from POP3 to IMAP tracks perfectly with the shift from single-computer to multi-device computing.

Why They Endure

The durability of these protocols is remarkable. In technology, 40 years is multiple geological ages. Programming languages rise and fall. Entire computing paradigms come and go. But SMTP, POP3, and IMAP endure.

Several factors explain their longevity:

Simplicity. The protocols do one thing each, and they do it in a straightforward way. SMTP moves messages between servers. POP3 downloads them. IMAP syncs them. This clean separation of concerns makes them easy to implement, debug, and extend.

Interoperability. Because the protocols are open standards maintained by the IETF (Internet Engineering Task Force), any email server can talk to any other email server. Gmail can send to Outlook can send to a self-hosted Postfix server can send to Yahoo. This universality is email’s superpower — and it’s entirely because the protocols are open.

Backward compatibility. When security features were needed, they were added as extensions rather than replacements. STARTTLS added encryption to SMTP without breaking the underlying protocol. SMTP AUTH added authentication. IMAP IDLE added push notifications. The original protocols kept working while gaining new capabilities.

Network effects. With billions of email addresses and millions of servers all speaking the same protocols, replacing them would require a coordinated global migration — a logistical impossibility. It’s easier to extend than replace.

The Trade-Offs

The downside of 40-year-old protocols is that certain limitations are baked in. SMTP’s lack of native authentication enabled decades of spam and phishing. Email’s text-based format makes rich interactivity difficult — every attempt to add interactive features to email (most recently Google’s AMP for Email) has struggled against the constraints of the format. Encryption remains optional and inconsistent, meaning most email is still transmitted in plain text at some point in its journey.

These are real problems, and they’re the reason that modern email infrastructure includes layers of additional technology — authentication protocols, spam filters, encryption wrappers, reputation systems — all sitting on top of the original three protocols like floors added to a building whose foundation wasn’t designed for the weight.

Yet the foundation holds. More than 350 billion emails per day travel across SMTP connections. Billions of devices sync their inboxes over IMAP. The protocols designed for a few hundred researchers on ARPANET now serve half the planet, and they show no signs of retirement.

Infographic

Share this visual summary. Right-click to save.

Frequently Asked Questions

What is SMTP and what does it do?

SMTP (Simple Mail Transfer Protocol) is the protocol used to send emails between servers. Defined in RFC 821 in 1982, it handles the transmission of messages from sender to recipient's mail server. SMTP operates on port 25 (or 587 for submission).

What is the difference between POP3 and IMAP?

POP3 downloads emails to your device and typically deletes them from the server. IMAP keeps emails on the server and syncs across all your devices. IMAP is preferred today because most people check email on multiple devices.

Why haven't email protocols been replaced?

SMTP, POP3, and IMAP have endured because they're simple, interoperable, and decentralized. No single company controls them. While they've been extended with security features (TLS, authentication), the core protocols still work essentially as designed in the 1980s.