We saw in part 2 of this series that when a receiving email server gets the message, it inserts a Received: header into the mail headers of the message. Let's go back to our previous example and see what happens if the message is routed through a couple of more servers.
Suppose that on its way from mailhost.tzink-is-awesome.com, mail sent from tzink.net had to go through a couple of forwarding relays.
From email@example.comReceived: from mailhost.tzink-is-awesome.com (mailhost.tzink-is-awesome.com [218.104.22.168]) by mail.tzink.net (8.8.5) for firstname.lastname@example.org with EMSTP id 123456789-0AH for <email@example.com>Received: from tdk4127.com (example_mailers_competitors.com [222.214.171.124]) by an_email_program (1.0) with SMTP id 71718149989; Thu, June 21, 2007 23:06 -0800Received: from example_mailers.com (example_mailers.com [2126.96.36.199]) by another_email_program (7.3) with SMTP id 9899481717; Thu, June 21, 2007 23:01 -0800From: firstname.lastname@example.orgTo: email@example.comDate: Fri, Jun 18, 2007 20:20:20 PSTMessage-ID: <firstname.lastname@example.org>Subject: How's it going?
I've highlighted the received headers in different colors. In general, you read received headers from bottom to top, with the most recent one getting stamped at the top and being the most reliable one. In the above example, the message started from the IP 2188.8.131.52 at a mail host called example_mailers.com. It got routed through their competitors example_mailers_competitors.com (IP = 2184.108.40.206), went through mailhost.tzink-is-awesome.com before finally arriving at its end destination at mail.tzink.net. It's a complicated process but from the above, we can see that the message originated at 2220.127.116.11, the first IP address.
In real life, it doesn't quite work that way. Spammers will often insert fake routine information into the headers. Here is a real life example of a spam message that I just received in my own email account (with some of the identifying information removed):
Received: from 200-122-3-37.dsl.prima.net.ar (200-122-3-37.dsl.prima.net.ar [18.104.22.168]) by mail25-blu.bigfish.com (Postfix) with ESMTP id 78128787654; Thu, 21 Jun 2007 22:46:40 +0000 (UTC)Received: from 22.214.171.124 (HELO positivenews.net) by frontbridge.com with esmtp (1/9B/+4-) LD*H)id (<C/(,-Q>,0(B-E< for email@example.com; Thu, 21 Jun 2007 22:46:50 +0300
From the above, we can see that the message originated at 126.96.36.199 from a machine calling itself positivenews.net, passed itself to a machine in a DSL pool in Argentina before finally arriving at my inbox. Or did it?
Look at the blue received header, it looks suspicious. That first received header is wrong. For one thing, it says Received: from <IP address> rather than Received: from mail host. Then, typically we would expect to see IP address in parentheses rather than only the name of the host. Of course, some mail servers are configured differently and this could be a configuration issue, but it is suspicious. Generally, as a spam analyst I would use this information alone to call it a forgery.
Moving onwards, look at the SMTP id. A bunch of characters including forward slashes, + and - signs and the asterisk. That, too, is suspicious and more than enough to confirm this received header as a forgery and is not authentic. Thus, we look at the line above and see that this mail originated from 188.8.131.52.
Spammers can insert more than one extra received header. Sometimes they are easy to spot, sometimes they are not. The times when they don't look like regular received headers gives them away; they will have syntax errors and extra X-headers that don't make any sense. Other times, spammers will be quite subtle in that they will mimic actual received headers. That makes things harder to pick out.
The last (ie, first in the header list) received header is correct because it contains the latest hop that the message went through and your machine stamped it. It doesn't mean that the mail originated at that IP but at least you have some information about where the mail recently came from.
PingBack from http://joshmaher.wordpress.com/2007/10/11/sender-authentication-explained/