A day in the life of an email

Having touched on routing for emails, we should take a look at what goes on when you hit 'Send' on an email message until the point when the recipient reads it in their email client.

The vast majority of email uses two types of server to send an email from A to B: the outgoing mail server and the incoming mail server. The outgoing email server is almost certainly an SMTP server (Simple Mail Transfer Protocol), while the incoming server can be a POP3 (Post Office Protocol) or IMAP server (Internet Mail Access Protocol).

When you set up your email client (let's say this is Microsoft Outlook, since that's what I use), you specify for it the address of your SMTP server. You also define to it the user ID and password that has been assigned to you to use the server's facilities (without a properly protected SMTP server, your email could be hijacked for spam broadcast purposes).

You write an email in Outlook, specify the recipient and press 'Send'. Outlook formats the message according the email standards (since 2008 this is defined in the RFC5322 document, which superseded RFC2822 from 2001, which in turn superseded RFC822 from 1982). It then connects to the SMTP server on port 25, passing the user id and password for authentication, and sends the email.

Once the SMTP server gets the email (and adds its routing information), it looks for the address to send it to within the header section. It strips off the username and the @ sign, leaving the domain name that the email must be sent to. The SMTP server queries the Domain Name System (DNS) for the MX (Mail eXchange) records for that domain name.

The DNS entry for a domain name consists of a set of records defining the addresses of servers that process various types of connection (there are A records, AAAA records, CNAME records, and so on), and the MX record defines the server that can receive emails for the domain. For example, with my personal domain, the A record currently points to 97.74.144.79. This is the IP address of the server that hosts my domain and my website.

My highest priority MX record (you can have several MX records and they are ordered according their priority, the order in which SMTP servers try to connect with them) is pointing to smtp. secureserver.net, the GoDaddy server that deals with my email. And, yes, your SMTP server then has to resolve secureserver.net to an IP address in order to continue.

You've got mail

Your SMTP server then sends your email to the recipient's MTP server using the Simple Mail Transfer Protocol. Of course, it may be that, due to unforeseen circumstances, my SMTP server is offline or down.

In this case, your SMTP server will put your email in a queue and try to send it again later. If the server finds that after several tries it can't send the email at all, it wraps the email in a 'cannot deliver' message and posts that to your email inbox. But let's assume that all goes well and my SMTP server receives your email (and adds its routing information). It in turn reads the recipient email address, works out the user name, and puts the email in my inbox.

By 'inbox', I don't mean the inbox in Outlook or whatever email client you use. I mean the inbox on the email server for my email address. In the old days, the inbox was very simple: it was a set of text files, one per email, in a folder named after my email address (or maybe a single text file and new emails were appended).

These days it's more integrated - the inbox is in a database, with the usual failsafe guarantees that provides. Incoming mail servers We now come to the opposite end of the email trail: the incoming mail server. Ignoring the heavy duty corporate email systems such as Microsoft Exchange, Lotus Notes or Blackberry Server, there are two main ones in use today: the POP3 server and the IMAP server.

POP3 is the older and less sophisticated of the two, but they both have roughly the same features. The main difference between them is what happens to the emails. With POP3, although you can leave emails on the server, there's no provision for marking any as read/ unread - the assumption is that emails are downloaded to your client and deleted from the server.

Of course, this presents a problem if you want to use a variety of clients to access your email, because you may find that a particular email that you want to read is on a different PC to the one you're currently using.

With IMAP, the assumption is the opposite: emails are left on the server and can be marked as read/unread. This means that you can access your emails through a variety of email clients (desktop, phone, web) and all clients will agree on the current state of the emails.

With IMAP you can also do things like set up an inbox folder tree on the server or move emails around the tree, and again the clients will all agree on the current state of the inbox.

Let's assume that I'm using POP3. Again, I will have configured Outlook so that my incoming server is at such and such address and has a particular user ID and password (I can't have all and sundry reading my emails after all).

When I ask Outlook to retrieve all my emails, it will log in to the POP3 server with the credentials I gave, ask for a list of emails, and then download and delete them one by one. It will read the header information from each email in order to ascertain how the message is structured, how the constituent parts are encoded, from whom the email came, the delivery date/time, and so on.

Outlook will then decode and display the emails for me to peruse and read, and with that we come to the end of the journey for that email, from your PC to mine.