Theory
One email, end to end
Time to put the pieces together. When Riya emails Arjun, the message crosses the internet through a clear sequence of hand-offs, and every protocol you just met plays its part. Tracing this journey is a case study that ties the whole subject together.
Three players are involved: the mailer (the email program each person uses), the mail server (which sends, relays, and stores mail), and the mailbox (where received mail waits). Watch how the message moves between them, and which protocol carries it at each step.
Follow along
The journey of an email
- Compose in the mailer Riya writes the email in her mail program (the mailer, or mail user agent) and hits send.
- Mailer to sender's server (SMTP) The mailer uses SMTP to hand the message to Riya's mail server.
- Server relays across the internet (SMTP) Riya's server uses SMTP to relay the message to Arjun's mail server, routed by IP across networks.
- Stored in the mailbox Arjun's mail server places the message into Arjun's mailbox, where it waits.
- Recipient retrieves (POP3/IMAP) When Arjun opens his mailer, it pulls the message from his mailbox using POP3 or IMAP.
Theory
The players and their roles
The mailer (mail user agent) is the program the human uses, to compose, send, and read. Riya's mailer and Arjun's mailer sit at the two ends.
The mail server (mail transfer agent) does the heavy lifting in the middle: it accepts outgoing mail, relays it toward the destination, and receives incoming mail for its users. There is one on each side.
The mailbox is the storage on the recipient's server where messages accumulate until the recipient fetches them. This separation is what lets email work even when Arjun is offline: the message safely waits in his mailbox until he next connects.
Formula
SMTP pushes, POP3/IMAP pull
The whole journey splits neatly by protocol. SMTP handles the sending half, from the mailer to the first server, and from server to server, it pushes the message toward its destination. POP3 or IMAP handles the receiving half: the recipient's mailer pulls the waiting message from the mailbox.
So mail is pushed across the world by SMTP and then pulled down at the end by POP3/IMAP. And all of this rides on the lower layers: transport (TCP) ensures reliable delivery, and network (IP) routes it between the servers. The layers cooperate.
Quiz
In the email journey, Arjun's mail program finally downloads the waiting message from his mailbox. Which protocol does this retrieval step use?
- SMTP, the same protocol that sent it
- POP3 or IMAP, which retrieve mail from the recipient's mailbox
- IP, because it routes the message
- FTP, because it transfers files
Show the answer
POP3 or IMAP, which retrieve mail from the recipient's mailbox
Retrieving received mail from the mailbox is done with POP3 or IMAP, the protocols for pulling messages down to the recipient's mailer. Option A is wrong: SMTP handled the SENDING and relaying (pushing the message toward Arjun's server), but the final download from the mailbox is a retrieval job, which SMTP does not do. Option C names IP, which routes packets at the network layer underneath, it is not the application-layer protocol the mailer uses to fetch mail. Option D, FTP, transfers files generally and is not the email retrieval protocol. Keep the halves straight: SMTP pushes mail out and across; POP3/IMAP pull it down at the end.
Think first
Why does the message sit in a mailbox instead of going straight to the recipient?
Why not deliver the email directly to Arjun's computer, rather than storing it in a mailbox on a server? Then tap.
Show the answer
Because the recipient is often OFFLINE, and the mailbox lets email work reliably regardless of whether the recipient is currently connected. If delivery required sending the message straight to Arjun's personal device, it would fail whenever his laptop was switched off, out of network, or asleep, which is most of the time. Instead, the message is delivered to Arjun's MAIL SERVER, which is always on, and stored in his MAILBOX there. The message waits safely in that mailbox for as long as needed, minutes or weeks, and Arjun retrieves it (via POP3 or IMAP) whenever he next opens his mailer, from any device. This 'store and forward' design is what makes email so robust: the sender's job is done once the message reaches the recipient's server, and the recipient collects it on their own schedule. It also means Arjun can read his mail from his phone, then his laptop, then a library computer, because it lives on the server, not tied to one machine (IMAP especially keeps everything synchronised on the server for exactly this reason). So the mailbox decouples sending from reading: mail can arrive any time and be collected any time, with an always-on server bridging the gap. Store first, collect later, that is why email does not depend on both people being online at once.
Summary
Key takeaways
- An email travels through three players: the mailer (user's program), the mail server (relays and stores), and the mailbox (stores received mail).
- The sender composes in the mailer, which hands the message to the sender's server via SMTP.
- The sender's server relays it via SMTP across the internet (routed by IP) to the recipient's mail server.
- The recipient's server stores the message in the recipient's mailbox until it is fetched.
- The recipient's mailer retrieves it from the mailbox using POP3 or IMAP.
- SMTP pushes mail out and across; POP3/IMAP pull it down; it all rides on transport (TCP) and network (IP).
- Memory hook: compose, SMTP out, relay, mailbox waits, POP3/IMAP down.