A different shape from the Web
For the last few guides you have lived inside HTTP, where the rhythm is always the same: a client pulls. Your browser asks for a page and the server hands it back; nothing arrives until you ask. Electronic mail, which is older than the Web, is built on the opposite instinct. A sender pushes: you write a message and your software shoves it out toward the recipient without anyone on the far end having asked for it. Holding these two shapes side by side — pull for the Web, push for mail — is the fastest way to understand why email looks the way it does.
But push raises a problem the Web never has to face. When your browser fetches a page, the server is up right now, listening, ready to answer. When you send mail, the recipient might be asleep, offline, or on a phone in a tunnel. You cannot demand they be online at the exact moment you hit send. So the mail system is built around stores that hold a message and wait. This is why email is not one conversation but a relay: your message hops from your machine to a server, perhaps through more servers, and finally rests in a mailbox until the recipient comes to collect it. The unsung hero of the whole arrangement is patience.
SMTP: the relay that pushes mail
The protocol that carries a message from sender toward recipient is SMTP, the Simple Mail Transfer Protocol. Like HTTP it is a text-based protocol you could almost type by hand: the client opens a TCP connection and exchanges short, readable commands with the server — HELO to introduce itself, MAIL FROM to name the sender, RCPT TO to name each recipient, DATA to begin the body, and a lone dot on its own line to mark the end. The server answers each command with a numeric reply code, just as HTTP servers answer with status codes. If you have read mail headers, you have seen SMTP's fingerprints.
But how does your message find the recipient's server in the first place? Suppose you send to [email protected]. Your sending server splits the address at the @ sign: the part after it, example.com, is a domain name, so the server asks the DNS not for a web address but for a special record called an MX (Mail eXchange) record, which names the host that accepts mail for that domain. This is the same phone book you traced from root to authoritative servers, simply asked a different question. With the answer in hand, your server opens an SMTP connection to that mail host and begins the conversation. SMTP is fundamentally a relay between mail servers, not a way for you to talk to a stranger's inbox directly.
- Your mail client hands the message to your outgoing mail server using SMTP (this leg is usually authenticated and encrypted so only you can send as you).
- That server reads the recipient domain after the @, asks DNS for the domain's MX record, and learns which host accepts that domain's mail.
- Your server opens an SMTP connection to that host and relays the message with MAIL FROM, RCPT TO, and DATA. The receiving server accepts it with a 250 OK reply.
- The receiving server drops the message into Alice's mailbox, where it simply waits. SMTP's job is now finished; it never had to wake Alice up.
MIME: teaching plain text to carry anything
There is a wrinkle in that tidy story. SMTP was born to carry plain English text — the simplest possible stream of readable characters. Yet your inbox is full of photos, PDFs, video clips, accented letters, and Chinese characters. How does a protocol built for plain ASCII text carry a binary image? The answer is MIME, Multipurpose Internet Mail Extensions, and it is a beautiful piece of backward-compatible cleverness. MIME does not change SMTP at all. Instead it defines a way to describe and encode rich content inside the very same plain-text body that SMTP already knows how to relay.
MIME works in two moves. First, headers describe what the content is: a Content-Type header announces text/plain, image/jpeg, application/pdf, and so on — the same media-type vocabulary you met in HTTP, because they share this idea. Second, when the content is binary, an encoding such as Base64 rewrites those raw bytes as ordinary printable letters, so a JPEG becomes a long, dull-looking block of text that survives any text-only channel intact; the receiver decodes it back to the original bytes. A single message can even hold several parts at once — a text version, an HTML version, and two attachments — each labelled with its own type. That is how one humble text stream quietly carries the whole modern internet.
IMAP and POP3: reaching into your mailbox
SMTP got the message into Alice's mailbox, but that mailbox lives on her mail server, not on her phone. To actually read it she needs a second, separate protocol — a pull protocol that lets her client reach into that remote mailbox and fetch what is there. The modern choice is IMAP, the Internet Message Access Protocol. The older alternative is POP3, the Post Office Protocol. They solve the same problem with two very different philosophies, and the difference is worth understanding because it shaped how email feels today.
POP3's instinct is download-and-delete: it pulls messages onto one device and traditionally removes them from the server, treating the server as a temporary drop box. That was fine when you read mail on a single desktop. IMAP's instinct is the opposite: the server is the master copy and your devices are synchronized windows onto it. With IMAP your folders, your read/unread flags, and your messages live on the server, so your phone, laptop, and tablet all see the same mailbox in the same state. Mark something read on your phone and it shows read on your laptop a moment later. This is why IMAP won the multi-device world: it keeps the truth in one shared place that every client mirrors.
FTP: the file mover and its odd two channels
The last classic protocol in this rung is FTP, the File Transfer Protocol, and it predates almost everything else here. Its job is simple to state: move files between a client and a server, and let you browse, rename, and delete them remotely. What makes FTP worth studying is one unusual design decision that quietly teaches a real lesson. Where SMTP and HTTP do everything over a single connection, FTP splits its work across two separate TCP connections: a control connection that stays open for the whole session and carries your commands (list this directory, get that file), and a data connection opened freshly for each actual file transfer.
Why bother with two channels? Separating control from data means commands and replies keep flowing on the control line even while a huge file streams down the data line — you can abort a transfer mid-stream because the control connection is never clogged by the file itself. It is a clean idea. But it has an awkward consequence that became famous: in the original 'active' mode, the server opens the data connection back toward the client, and once firewalls and NAT became common, a server trying to reach back into a home network usually got blocked. The fix was 'passive' mode, where the client opens both connections outward. This is a vivid lesson that a protocol's design lives or dies by the network reality around it, not just its own elegance.
Like SMTP and plain HTTP, classic FTP sends everything — including your password and your files — in the clear, with no encryption at all. For that reason it has largely been retired in favour of secured replacements: FTPS wraps FTP in TLS, while SFTP (despite the similar name) is an entirely different file transfer that rides inside an SSH session. Plain FTP survives mostly in legacy corners. Its real value to you now is conceptual: it shows that even a protocol whose only job is moving files makes deep choices about connections, channels, and trust — the same kinds of choices every protocol in this rung had to make.
The thread through every application protocol
Step back and look at what this whole rung has shown you. Every protocol you met — HTTP, SMTP, IMAP, FTP — is just an agreement, layered on top of the application layer, about what bytes two programs send through a socket and in what order. Once you see them as conversations rather than magic, their family resemblance jumps out: most are readable text with commands and numeric reply codes; most open a TCP connection because they need every byte to arrive; and each one made deliberate choices about state, channels, encoding, and how it finds its peer.
And those choices are not arbitrary trivia — they are the heart of the craft. Pull or push? HTTP pulls, SMTP pushes. Stateless or stateful? HTTP forgets, IMAP remembers. One connection or two? FTP famously split them. Plain text or binary, and how do you carry rich content over a text channel? MIME answered that for mail and HTTP reuses the very same media types. When you design or debug a networked application, these are precisely the dials you will reach for, because they are the questions every protocol on the Internet has already had to answer in its own way.
You now stand at the top of the stack with a working map of how applications actually talk: who initiates, where state lives, how rich data is encoded, and how each protocol finds its partner through DNS. Below you sit the layers that make any of it possible — reliable transport, global routing, framed links, raw bits — and you have climbed every one. From here the ladder turns to the cross-cutting concerns that wrap all of these protocols at once: the security that none of them have by default, and the naming, caching, and delivery systems that make the whole thing fast and findable.