Email contains specific key elements that enable it to communicate and route to the correct places. The design of the email system is what makes email one of the most efficient forms of communication today. Ironically, the email system's infrastructure is similar to that of the traditional post office in that it requires you to have "routable" addresses enabling mail to be delivered. The mail server is similar to your human mail carrier, and the mail client is you physically walking to your mailbox.
To begin, let's dive into understanding how the user goes about creating, sending, and receiving email. We'll finish with a discussion of how to forge email.
The process of sending and receiving email involves two types of systems: the mail client (that's you) and the mail server (similar to the post office). To understand email headers, one must understand that email doesn't simply go from points A to B and suddenly "You have mail!" In many cases, an email message routes through four computers before it reaches its destination. Technically speaking, the total number of systems involved in the full process of email delivery is about twice that, but it's transparent and performed efficiently.
For examples in our email demonstrations, we will use an email message that I want to send to my readers. The email addresses we will use are:
My mail server will be mail.sendingemail.com, the receiver will be mail.receivingemail.com. The sending workstation will be called Sender, and the receiving workstation will be called Receiver. Now let's look at the internal operations of an area most of you reading this book should be familiar with: the client user experience of opening an email client to enter the To, Subject, and Body fields in the new email message.
Figure 1 shows an example of a common screen for creating an email message:
Figure 1 Standard EMail Process: Creating a Message
As you can see, there is an optional CC field, enabling you to add email addresses to send this message to (a perk you don't get at the standard post office with a single stamp and envelope). Then I click Send and off my message goes to be received by firstname.lastname@example.org.
It appears that this comes off without a hitch, but the internal workings are what keep the message going. The mail protocol has headers that mark the emails with information on where it originated, its destination address, and the route it took to get there. Yes, that's right, email tells a story of its delivery, similar to a tracking number when you ship something via a carrier like Federal Express. The development of the email header's progress on its way to the destination address are typically marked by three different systems that are handling the mail delivery. I sent mail to email@example.com and the minute I clicked Send, the message was handed off to my mail server (mail.sendingemail.com). At that point, my mail client sent the mail server the following email headers to process:
From:firstname.lastname@example.org (Lance James) To: email@example.com Date: Tue, April 04, 2005 23:01:12 PST X-Mailer: Microsoft Outlook, Build 10.0.2616 Subject: This is your subject field
As you can see, the fields I referred to are actually headers. Email is technically constructed of headers with the field: value set. A blank line separates sections within the headers, so the actual body has a blank line with a content type before it, usually plaintext, which is indicated by the following:
Content-Type: text\plain; charset=ISO-8859-1: format=flowed
This text is usually found below the headers we displayed previously (different mailers have different header ordering) and indicates the type of content found within the email. The content-type field is determined by the mail client since it knows what it is sending. When we send plaintext, the content-type field is optional, but the majority of mail clients use it to stay within the specifications found in requests for comment (RFCs; see www.imc.org/rfcs.html).
As we continue, our mail client has sent the email to our mail server (mail.sendingemail.com). The mail server will read the header information that our mail client sent it, and will add some additional header information before sending it off to the receiver's mail server (mail.receivingemail.com). Here is what the headers look like:
Received: from sender (xx.7.239.24) by mail.sendingemail.com (Postfix) id 125A56; Tue, April 04, 2005 23:01:16 -0800 (PST) From: firstname.lastname@example.org (Lance James) To: email@example.com Date: Tue, April 04, 2005 23:01:12 PST Message-ID: firstname.lastname@example.org X-Mailer: Microsoft Outlook, Build 10.0.2616 Subject: This is your subject field
There are a few extra additions marked on there, mainly stating from where the message was received (the mail client, when it identified itself to the mail server) and the time it was received, along with a message ID. The message ID has no human-based significance, but from an administrative standpoint, a mail administrator can use it to look up emails. The email message ID is similar to a FedEx or UPS Tracking number, and although it's a completely random number, can be very useful.
Let's view the final header additions marked on the receiving mail server endpoint:
Received: from mail.sendingemail.com (mail.sendinge-mail.com [xx.7.239.25]) by mail.receivinge-mail.com (Postfix) with ESMTP id T12FG932 for <email@example.com>; Tue, 04 April 2005 23:01:22 -0800 (PST) Received: from sender (xx.7.239.24) by mail.sendingemail.com (Postfix) id 125A56; Tue, April 04, 2005 23:01:16 -0800 (PST) From: firstname.lastname@example.org (Lance James) To: email@example.com Date: Tue, April 04, 2005 23:01:12 PST Message-ID: firstname.lastname@example.org X-Mailer: Microsoft Outlook, Build 10.0.2616 Subject: This is your subject field
When the receiving client user sits down at the receiver workstation, he will be able to view these email headers within the email (depending on the email client software, he might have to select the appropriate view headers field). When you receive an email, it can be very important to understand headers so you can trace the historical logs of an email. Let's look at the last set of headers we received and review each line item added to the Received headers.
Received from: mail.sendingemail.com (mail.sendingemail.com [xx.7.239.25]) by mail.receivingemail.com (Postfix) with ESMTP id T12FG932 for email@example.com; Tue, 04 April 2005 23:01:22 -0800 (PST)
This first header tells us that this message was received by a server dubbed mail.sendingemail.com. The parentheses show the verification of identity, stating that a DNS reverse lookup revealed that the IP matches this identification and that xx.7.239.25 is the IP address the message came in from. The mail server that received the email is mail.receivingemail.com, which is running Postfix ESMTP with an arbitrary id of T12FG932. The ID is arbitrary and constructed by the receiving mail server for administrative purposes. The email address this message is intended for is firstname.lastname@example.org, with a receive date of Tuesday, April 4, 2005, at 11:01 P.M. and 22 seconds, Pacific Standard Time.
This entry header:
Received: from sender (xx.7.239.24) by mail.sendingemail.com (Postfix) id 125A56; Tue, April 04, 2005 23:01:16 -0800 (PST)
documents the mail transfer between the Sender workstation and the sender's mail server. It is identified by the IP address in parentheses, and we know that mail.sendingemail.com is a Postfix server and has labeled this message with an arbitrary message ID. The date of mail transfer was Tuesday, April 4, 2005, at 11:01 P.M. and 16 seconds, Pacific Standard Time.
The headers derived in this e-mail are legitimate headers. Anytime a system assists in routing an email, an extra Received header will be added on. Notice that the order of Received headers is destination endpoint first, and the bottom header is the starting point (see Figure 2).
Figure 2 Standard E-Mail Process: Multiple Hops Required to Reach Receiver
Phishing exposed -- 10 tips in 10 minutes
Tip 1: Phishing and email basics
Tip 2: Phishing and the mail delivery process
Tip 3: Anonymous email and phishing
Tip 4: Forging headers and phishing
Tip 5: Open relays, proxy servers and phishing
Tip 6: Proxy chaining, onion routing, mixnets and phishing
Tip 7: Harvesting email addresses and phishing
Tip 8: Phishers, hackers and insiders
Tip 9: Sending spam and phishing
Tip 10: Fighting phishing with spam filters
This chapter excerpt from Phishing Exposed, Lance James, is printed with permission from Syngress Publishing, Copyright 2005. Click here for the chapter download.