This content is no longer maintained. Please visit our new website.

ACCC Home Page Academic Computing and Communications Center  
Accounts / Passwords Email Labs / Classrooms Telecom Network Security Software Computing and Network Services Education / Teaching Getting Help
The A3C Connection, Oct/Nov/Dec 2000 The A3C Connection
Oct/Nov/Dec Contents Slamming Spamming Fig 2: Legit Email Headers Fig 3: Spam Email Headers Reading Email Headers
nslookup More Info on Headers and Spam Designing Accessible Web Pages Web Accessiblity Contest About the A3C Connection

Reading Email Headers


There is lots more to be said about email headers than there was room in the printed copy of this article. So I've added more information to this article online. I also added a short description of each header in the legitimate email message; see the second part of Figure 2, the headers of a legitimate email message. I also added a page of related Web sites; see More Info on Headers and Spam.

Tech Tips
WWW Experts
Displaying Email Headers

Email headers are the lines at the top of an email message that are used by servers on the Internet as they deliver the message. Your email program normally shows you only the standard To:, From:, Subject:, and Date: headers, but there are more. The most important header when you want to complain about spam is Received:, which tells you the route the message took when it was sent to you.

You can instruct most email programs to display the full headers of any message that you receive. While viewing the message,

  • In Eudora: Click the Blah Blah Blah button.

  • In Netscape: Select: View->Headers->All

  • In Outlook: Select: View->Options

  • In Pine: Type H. (Requires the enable-full-header-cmd feature.)

  • In WebMail: Click View Full Headers.

Figure 2 and Figure 3 are the full headers of a normal email message and an actual, and typical, spam message. Comparing the two will give you an idea of how email travels and how spam differs from normal email messages. Except for the UIC-related items, the domain names, IP addresses, and email addresses in the headers have been altered.

The domain names and IP addresses in Received: headers are those of the actual machine that performed the service. These headers can be faked, but it's harder to do than faking From: addresses.

Received: Headers

The Received: headers of any email message will tell you where the message originated and what route it took to get to you. That's what you need to know to complain about spam.

You read Received: headers in reverse order. The sequence from the last Received: header in the message's headers -- that is, the one furthest down in the headers, which is in fact the first Received: header that was added to the message -- to the top Received: header should take you from the email server where the message originated, to a local incoming email server, and finally, to your inbox.

-- The Last Received: Header:

The last -- bottom -- Received: header(s) in any message is actually the first one put on it. It should identify (1) the first email server that handled the message and (2) its intended recipient.

For example, consider line 3 in figure 2:

Received: from ( [])
by (8.10.2/8.10.2) with ESMTP id B70X2E26999
for <>; Wed, 6 Dec 2000 18:33:02 -0600 (CST)

There is lots of information here. This header was added to the top of my message by, the outgoing mail (SMTP) server at my ISP, the one that my email program gave my message to when I sent it. The message is "from" the domain, and from my computer, which at the time had been assigned the domain name and IP address in the parentheses. (As is the case with most commercial ISPs, I get a different machine name and IP address each time I connect.) My message has a proper To: header, so postbox included that in as the "for" address this Received: header.

The second line tells us that is using version (8.10.2/8.10.2) of Sendmail. (Whenever the actual program name is left out, as it is here, Sendmail is assumed.) The "ESMTP id B70X2E26999" is an internal ID number it assigned to the message. This ID number is only of use to my ISP's mail service; it could be used to look up the message in their log files.

This transaction occurred on Wednesday, December 6, 2000, at 18:33:02 CST, Central Standard Time. CST is 6 hours behind Greenwich Mean Time, GMT, the time zone in Greenwich in England. That explains the -0600. 18:34 is 6:34 PM; for obvious reasons, email headers and servers use 24-hour times, rather that AM and PM.

Compare the above with the equivalent line in the spam message, line 3 in figure 3.

Received: from
by with ESMPT; Sun, 19 Nov 2000 03:39:01 -0400

The spam's header gives us very little information about where it originated and doesn't say anything about whom it's to go to. This is common in spam. I altered the "" domain name; in real life it was a dialin line that I believe is in Atlanta, Georgia. It belongs to a really big ISP.

The lack of a "from" address in the spam's Received: header most likely means that the spammer used SMTP services on their own machine to send the message; most spam-generating software comes with basic sending mail services built-in. The spammer certainly wouldn't want to identify his machine if he didn't have to.

According to this header, this transaction occurred on Sunday, November 19, 2000, at 3:39:01 AM in a time zone that is 4 hours behind GMT. In November, that would be Atlantic Standard Time. The only problem with this is there isn't much land in AST; none of the US is in it, nor, for that matter, England or Spain. Just a bit of eastern Canada and Brazil. So that's probably not correct. Either the spammer's machine doesn't have its date set correctly or he's playing games with it.

Line 2 is the next Received: header in both messages.

Line 2 in figure 2 shows a simple trip from to, a mail server at UIC that handles incoming email addresses to aliases. looked up the "" domain and found mail to this domain should be passed to So it gave the message to daedalus, which added the message's second Received: header when it handed the message off to the machine my inbox is on. (The message didn't go directly to the machine that my UIC email account on because it is addressed to my email alias, which had to be resolved into my real email address before it could be delivered to me. That's where daedalus comes in.)

Received: from ( [])
by (8.9.3/8.9.3) with ESMTP id SAA01839
for <>; Wed, 6 DEC 2000 18:38:48 -0600 (CST)

Daedalus did a reverse-DNS lookup on the IP address of the sending machine,, and got the result in the parentheses. The names don't match, but that isn't a problem because is an alias (an alternate name) for; both names refer to the same IP address, I've altered these names and the IP address, but I did look up both the actual names and the actual IP address in nslookup and confirmed that they are all the same machine.

Daedalus is also running Sendmail, version (8.9.3/8.9.3) this time, and it gave the message the ESMTP ID number SAA01839.

Line 2 in the spam message is more interesting:

Received: from
by with SMTP; 19 Nov 2000 08:50:54 -0000

The qrd32565.qrd is altered, but the .es isn't; .es is the upper level domain for sites in Spain. This says that our spammer choose to send the message first to a machine in Spain. This is the header that the machine in Spain added when our spammer's machine on passed the message on to it.

"HELO" is the SMTP command that the sending machine uses to identify itself to the receiving machine. I'm not sure why the Spanish machine included the HELO command in its header. I altered the dialup's name and IP address, but I did look the originals up and they matched each other. It might be because the Spanish machine is using different SMTP server program; Sendmail almost always includes version info, which is missing from this header.

The top Received: header, line 1 in both messages, describes the final delivery of the message. The spam's top Received: header has additional information about the route it took:

Received: from ( [])
by (8.10.2/8.10.2) with SMTP id eA03121
for <>; Sun, 19 Nov 2000 18:14:14 -0600 (CST)

More altered domain names and IP addresses, but a quick nslookup on the real names confirmed that the domain names and are associated with the same IP address, so they point to the same machine. In real life, that machine belongs to company in Spain. All the information about it in the spam message's Received: headers checks out. Probably, its only involvement in the spamming process was that it was running an open relay.

About the Top Received: Header

Whether spam or legitimate email, the first (the one at the top, which is actually the last one added) Received: header in any email message will always involve a local machine. Messages delivered to addresses will have a first Received: header like the one in figure 2, line 1:

Received: from ( [])
by ...
for <>...

The mention of a local machine in the top Received: header is correct and does not mean that that machine (daedalus, eeyore, or winnie, for example) is participating in sending spam. Itís just delivering your incoming email to your account like itís supposed to do.

So, the Received: headers, line 3, line 2, and line 1 in each message, give us the route that the message took. The spam message's route is quite suspect: from a dialup, perhaps in Atlanta, through a machine in Spain, and then to Chicago. And that's for a message whose stated sender is in the United Kingdom. (See the From: header below.)

Other Headers

From: headers in spam messages are usually fake, and generally aren't much use. The spam's From: header, line 6:


makes it seem that the message came from a fly fishing site in the United Kingdom. It is probably faked.

The Message-ID: header should tell you where the message originated; its value is an id number, followed by "@", followed by a machine name. Consider line 4 in figure 2.

Message-ID: <>

The spam's Message-ID: header leaves out the machine name:

Message-ID: <00000ee45f1f$00003dcf$00004947@>

Not much help here, either.

Comments are welcome; please send them
to Judith Grobe Sachs,
The A3C Connection, Oct/Nov/Dec 2000 Previous:  Fig 3: Spam Email Headers Next:  nslookup

UIC Home Page Search UIC Pages Contact UIC