Email from 10,000 feet. - Maneesha's Substack

Maneesha's Substack

SubscribeSign in

Email from 10,000 feet.<br>Email Series: Part 1

Maneesha<br>Jun 01, 2026

Share

Email on the outside looks extremely simple. A user composes an email, provides one or more addresses and sends it on its way. The message is delivered to its final destination where the recipient views it on their device. This blog series aims to showcase the protocols involved in this process.<br>This particular article provides a high-level introduction of how email works. The goal is to build a clear mental model before diving into implementation details in later parts of this series.<br>History

If you start reading about the history of email, you’ll definitely come across the term “Internet email”. This term baffled me early on, as I’ve always used email on the internet. My earliest memories of email was my mother borrowing the family computer (against my wishes) to check her Yahoo Mail™️.<br>It might surprise you that Internet email isn’t the only type of email. There are several other types, each of which were created in different eras with different requirements in mind.<br>Email actually predates the Internet by roughly a decade:<br>Early forms of email appeared in the mid to late 1960s on time sharing systems.

Network email i.e. sending messages between different computers emerged on the ARPANET (precursor to the Internet) around early 1970s.

The modern Internet (TCP/IP) was standardized in 1983.

This series is limited to Internet email, so from here on I’ll refer to it as email or mail.<br>Let’s rebuild these ideas from scratch, starting from the simplest possible problem and seeing how the constraints of the real world shape the system into what it is today.

yahoo.com around 2005.

Top down View

Fundamentally email systems allow us to:<br>Send emails.

View emails.

Receive emails.

I’m doing a lot of simplifying here, by focusing purely on the message and the capabilities around it. So let’s focus on building out a bare bones messaging system.<br>I will use a lot of abstraction and intentionally ignore lower-level details at the protocol level so that we can concentrate on the core ideas.<br>Imagine we are programmers in the late 1960s, working in a university lab. There is only one computer, a large shared system where multiple users log in at different times throughout the day on their accounts.<br>Now suppose I want to leave you a message. A naive but effective approach would be to associate each user with a file.<br>So you would get a file with your username, and whenever I feel the need to tell you about the leaded petrol price going up by a cent, I would do so by appending my message to the end of this file.<br>At this point, we already have something that resembles a very primitive form of email. Early systems worked in a similar way, messages were just plaintext stored in user “mailboxes”, often implemented as files on the system.<br>This approach works, but only up to a point. What happens if multiple users try to write to the same file at the same time? How do we separate one message from another? How do you know if a new message has arrived without constantly checking? To handle this, we would introduce some structure: messages would follow a defined format, appending would be handled safely, and users would interact with a clearer mailbox abstraction. At this stage, we’ve moved from a shared file to something that looks more like a mailbox.<br>Now consider what happens when there is more than one computer. Imagine there are two machines in different labs. You are on one machine, and I am on another. Writing to a local file is no longer enough because your mailbox exists on a different system. To send you a message, my machine needs to communicate with yours.<br>Conceptually, the operation is still the same. We have a message, and we want to place it into your mailbox. The only difference is that instead of copying a file locally, we are now copying it over the network. Early networked email systems followed this same basic idea: transfer a text message from one machine to another and store it in the recipient’s mailbox.<br>As soon as messages can move between machines, we need a way to identify both the user and the machine they belong to. A natural solution is to combine the two into an address of the form user@machine. This allows us to specify both who the message is for and where it should be delivered. This is credited to Ray Tomlinson, who invented the email program on the ARPANET, an early version of the Internet.<br>At this point, doing everything manually no longer scales. We need programs that handle specific responsibilities. One program must be responsible for transferring messages between machines. Another must accept incoming messages and place them into the correct mailbox. And there must be a program that allows users to compose and read messages.<br>From these requirements, three roles emerge naturally. A program that transfers messages between...