A day in the life of an email

Email is now so ubiquitous, we no longer even consider how it all works. Billions of emails are sent each day (the majority of which are spam, admittedly), and even with the rise of social networking, we haven't abandoned email yet.

Some good, some bad; some work-related, some personal: it's the communications medium of the 21st century. But what exactly is an email? How does it get from me to you? What processes and servers have to be running in order to ensure all this magic works to the point where we don't need to worry about it?

Back in the very early days, messages could only be sent from computer to computer on the same network. For this to happen, both computers had to be running and online (that is, both endpoints had to have users logged in) since the originating computer made a direct connection to the destination computer in order to transfer the message.

This worked in essentially the same way that phone switches work to route a call: the originating and the destination phone must be connected directly for the length of the phone call. For computers on the same network, this method worked pretty well, but it didn't scale at all once we started to link local networks together.

The birth of email

In 1969, the precursor of the internet, ARPANet, was created by a research team at MIT and at DARPA (Defense Advanced Research Projects Agency). It was the first packet-switched network, so named because all data traffic was split up into packets. The packets were numbered sequentially and put into digital envelopes, with destination addresses encoded into the envelopes.

ARPANet was a collection of servers, each able to receive and pass packets onto other servers on the network. This meant that a large message would be split into different packets, and each packet might be routed a different way through the network to the destination. Each node on the network knew only enough to pass on packets that weren't destined for itself, and it was the receiving computer that was responsible for collecting all the packets that made up a message and checking that none were missing.

This methodology meant that packets from many different messages from many sources could be interleaved and sent on a link, without the need to tie up the link to send a single message.

A couple of years later in 1971, Ray Tomlinson implemented the first system that we would recognise as email. His system was based on a program that copied files across a network and allowed users of different networks to send messages (as files) to each other.

To help with the addressing of the email, he came up with a simple solution: separate the username from the remote network domain name by use of the '@' sign - a convention we still use today.

The earliest emails sent were text files, usually seven-bit ASCII. Although emails are no longer physical files, they remain as text.

An email consists of two main parts: the header and the message section, separated by a single null line (that is, a line that that only comprises a carriage return/line feed).

Modern messages

Nowadays, the message section can - and usually does - have a lot more structure associated with it thanks to the MIME (Multipurpose Internet Mail Extensions) standard. This standard extends the original seven-bit ASCII-only messages to incorporate other character sets including Unicode, attachments (usually encoded with something like Uuencode or base64) and multiple parts (where a message is encoded as pure text, HTML and rich text within the same email).

The header section remains resolutely ASCII (although MIME does allow for addressing with other character sets). It consists of various header information about the email, such as the subject, the recipient address(es), who sent it, a unique message ID, where replies should go to, and so on.

Email clients usually suppress most of this information when displaying an email, although there's usually a way to show them. Figure 1 shows an example header section from a recent email from the Association for Computing Machinery (ACM). Reading this you can see who sent it (and where to send the response to if I wanted to reply) and when it was sent.

The message itself is in a multipart MIME format (the line that defines the boundary between the parts is shown) - as it happens, the message is represented in both straight text format and in HTML within parts of the email and it's up to the email client as to which is actually displayed to the user.

Routing for emails

What also generally happens when an email is sent across the internet is that intermediary servers add extra routing information to the header section. For simplicity, this information is prepended to the header section, so the server doesn't have to hunt for the end of the section to add it.

The routing information generally details which email systems looked after and rerouted the email on its way to the inbox. For example, I've set up my personal email so that all messages are rerouted to Gmail, which means I can access my email easily using a browser or my phone.

The routing information included on the example email from Figure 1 shows (reading from the bottom upwards) the originating server name, the receipt by my email server at my personal domain, its sending on of the email to Google, the receipt by Gmail, and the final delivery to my inbox (see Figure 2).

By tracing the times shown on the routing information, I can see that the email appeared in my domain's inbox in a matter of seconds, whereas the automated Gmail fetch process took about 30 minutes. Although legitimate email servers will provide valid information as they prepend routing information, many others won't.

Spam emails especially tend to contain fake routing information, so you can't rely on this header information until the point when it reaches your email server.