|Academic Computing and Communications Center|
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.
|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,
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.
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:
There is lots of information here. This header was added to the top of my message by postbox.myisp.com, 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 myisp.com, 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 postbox.myisp.com 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.
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 "dialup35.atl.bigisp.net" 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 in figure 2 shows a simple trip from myisp.com to daedalus.cc.uic.edu, a mail server at UIC that handles incoming email addresses to uic.edu aliases. Postbox.myisp.com looked up the "uic.edu" domain and found mail to this domain should be passed to daedalus.cc.uic.edu. 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 firstname.lastname@example.org 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.)
Daedalus did a reverse-DNS lookup on the IP address of the sending machine, 126.96.36.199, and got the result in the parentheses. The names don't match, but that isn't a problem because postbox.myisp.com is an alias (an alternate name) for smtp.myisp.com; both names refer to the same IP address, 188.8.131.52. 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:
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 bigisp.net 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.
More altered domain names and IP addresses, but a quick nslookup on the real names confirmed that the domain names qrd32565.qrd.es and spanishisp.com 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.
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.)
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.
Not much help here, either.
Comments are welcome; please send them
|The A3C Connection, Oct/Nov/Dec 2000||Previous: Fig 3: Spam Email Headers||Next: nslookup|