Examples of Forged Email Headers

Let's get back to those four essential questions:

1. Who sent me the mail?
   
2. Which address was it sent to?
   
3. When was it sent?
   
4. What is it about? (we'll skip this question for this email)
   

1. Who sent this mail?
As we learned from the last example, we have to look first at the bottom Received: header. This header claims that the domain rt3252.com sent this mail. We can check with the Internic's whois directory which lists all registered domains ending in .com, .org, .net, or .edu, like so:

% whois rt3252.com
No match for "RT3252.COM".

(Note: In order to do this, you need to go to a Unix shell prompt. Ask your ISP how to access one. If you only have web access, you can perform this same search at the Internic website.)

Big surprise -- this is a fake domain. After all, during the SMTP transaction, it's easy enough to stick any old domain name into that field. The Message Id is equally unreliable, as we can see. But what isn't so easy is forging what comes in the parenthesis following the domain name.

What does (trt-on1-18.netcom.ca [207.181.81.82]) mean? As we learned from the first example, the long number at the end is an IP address. That is the numerical address of the computer that sent out this email. How did they send the email? They used a dial-up account at netcom.ca.

Any domain has the following setup: domainname.domaintype. For example, Pobox has the domain pobox.com. Pobox is the domain name, and .com (commercial entity) is the type of organization we are. There are four types of domains in the US: .com, .org (non-profit or undefined organization), .net (Internet Service Provider), and .edu (educational institution). Of those groups, only "edu" has strict requirements for obtaining the edu categorization. Each country has it's own top-level domain, as well, so you can also see domains that end in .uk, .au, .to, etc...

Before the domain name and type is the machine or method responsible for transporting the mail. Our mail exchangers each have a name that is tacked onto the domain name. For example, one of our mail exchangers is mate.pobox.com.

In the forged entry above, trt-on1-18.netcom.ca, netcom is the domain name. They are from Canada(.ca). The sender did not send mail through a mail exchanger (which has a simple name like "mate") but used an individual account. How do I know this? To begin with, trt-on1-18 doesn't look like the name of anything. But the real clue is the mess of hyphens. They tend to signify a "dynamic IP" connection, such as a dial-up modem, DSL or Cable modem.

So, even though there is no From: field here, we know that someone using a dynamic connection to netcom.ca sent this email. From netcom.ca, the email went to our mail exchanger mate here at pobox.com. Mate transferred the email to the recipient at weck.brokersys.com.

2. Which address was it sent to?
Normally we'd look at a To: field to figure this out. But as you can see, there isn't one.

When you send email through your email software, you are prompted with a To: field which you fill in to send mail. But if you are sending mail through an SMTP transaction, there is no such prompt. Instead, there is a prompt for the sender to enter a recipient (rcpt to:). The rcpt to: field doesn't show up in headers, but is used by the mail server as the email address to which the message should be delivered. Of course, the sender can choose to add a To: field, but it's optional, and the message would be delivered without it.

So, as you can see, we can't tell what the recipient list is of this email. It could be one person, it could be 100,000. But what about the Return-Path: ? We would expect that to tell us something. Normally it does, but here the spammer entered <>, the universal symbol for a local mailer daemon (they are called angle brackets). A mailer-daemon is the identity in a server that sends you error and delivery messages. So when the recipient's server looked up the sender of the email, it saw the <> and assumed that the email had originated with itself. Obviously, no server will reject mail that seems to have come from itself.

3. When was this mail sent?
According to the Date: line, the mail was sent on Mon, 08 Aug 2000 at 09:16:56 -0400 (EDT). But look up at the first Received:line: the date and time entry there is Mon, 24 Aug 2000 09:15:20 -0400. Since a spammer can't access our machines to make them forge entries, we know that the Date: line is fake. This email was sent just before 09:15:20 -0400 on 24 August 2000.

Almost finished! Click here to move to the last page