Order of the Bath

What we saw in part 1 is the simple case with just a sending and receiving mail server, but quite often a number of intermediate hops are required to reach the ultimate destination. Using the “Received: ” headers in reverse order you can see what route a mail item took to get to you.

When email was invented, the networks weren’t as richly interconnected as they are now and consisted of small islands connected by narrow, unreliable pipes. So the technique to deliver a message was to forward it to another server which was a bit closer to the final destination. There was even a way you could suggest the route you wanted your mail to take. A system evolved where servers would discover the best routes by learned experience. This meant that servers became accustomed to accept any mail and forward it on as required.

In more recent times this custom was exploited as the servers didn’t care where the mail came from. Spammers arranged to send mail to random servers and specify obscure routes knowing that they would dutifully forward them on and their tracks would be hard to detect. This is called the “Open Relay Exploit.” To avoid this, servers began to be more selective and mostly they now only accept mail from their own clients or, alternatively, mail destined for places that they know about and are responsible for. They will no longer accept mail from anywhere to anywhere. In practice you will see from the headers that most mail gets moved around internally at the source end, makes a big leap to the destination, and then moves around a bit there before being stored.

An organisation called ORDB (Open Relay Database) tracks down the few remaining open relays and system managers can use this list to ban them from contact as their transmissions will be unreliable.

Consider an email that you send. It starts when you type it into a client program such as Thunderbird, Outlook Express or Hotmail. It then makes it way to your ISP. From there it goes to the recipients mail server where it is stored until they read it. Simple isn’t it. All except the last stage is controlled by SMTP; Simple Mail Transfer Protocol. Simple in this context is as in “Village Idiot” as we will see later.

An email is a plain text file consisting of some headers (consider this as the envelope) followed by the body which contains the letter. In theory no headers are required at all because you tell the courier who it is for but a destination line starting “To: ” followed by an email address is good. It would also be courteous if it had a “From: ” line and a “Subject: ” but they are not essential to the system. After the headers there is supposed to be a blank line before the body starts. At the end of the mail there will be a line containing a single “.” but you may not be able to see that when it arrives.

The email starts its journey going to your ISP mail server. It knows where that is because it is in your email client configuration. The conversation between the client and the server looks like this—the four letter codes are from the client, the server replies begin with a number.

220 mail.server.com Sendmail 8.6 ready at Mon, 10 Jul 2006 19:21:01
helo
250 mail.server.com Hello goodclient [64.223.17.221], pleased to meet you
        [yes, it really is this chatty—goodclient and the address are your client]
mail From: me@server.com
250 me@server.com ... Sender ok [note, it hasn't checked it really]
rcpt To: you@recipient.com
250 you@recipient.com ... Recipient ok
        [this gets minimum checking but it is important to get it right]
data
354 Enter mail, end with "." on a line by itself
From: me@server.com
To: you@recipient.com
Subject: greetings          [none of these are checked]

How are you today?
.
250 Jhub756hQ Message accepted for delivery [The random characters are an internal id]
        [now you can start again with a new "mail" or exit]
quit
221 mail.server.com closing connection

For a bit of fun you don’t even need an email client, just connect to the mail server on port 25 using telnet and type the commands in by hand. It is rather tedious though and there is little room for error.

The first thing the mail server does is add a new header to the front “Received: from … by …” and perhaps a time stamp, recording where it came from; think of this as a postmark. It then uses the destination (from the “rcpt” command not the “To: ” header) to decide where the email should go next. It will look at the domain part of the address (after the “@”) and ask DNS (Domain Name Service) what the address of the mail server is—this is obtained from DNS “MX” (mail exchange) records. It then goes through the same chatter with the destination mail server.

When the email arrives, after adding its own “Received: ” header to the front, the destination mail server will check that it really does belong here and store it in the file, sometimes called the mail box corresponding to the user (the bit before the “@”) It will wait there for them to fetch it, usually using a different system called POP3 (Post Office Protocol v3). The POP3 server uses a similar set of 4 letter commands to list mail, retrieve it, delete it etc.

Apart from a bit of queuing to cope with delays, that is all a mail server does.

Note that during all this, almost all the headers are ignored. “From: ” is never used for instance and can say absolutely anything! “To: ” may sometimes be used if the message has to be queued but not otherwise. “Cc: ” (Carbon copy) headers are checked and processed as new destination addresses using the same process as above. “Bcc: ” (Blind copy) is stripped out very early before being processed like “Cc: ” so it remains invisible to everyone else.