Section 3.2. Forged Headers

3.2. Forged Headers

Now consider an example where the headers have been forged to make the message appear to come from another source. The following headers are taken from a message that purported to come from the FBI, telling me that I had been visiting illegal web sites. In fact, the message contained a virus and was sent from an infected computer.

     Return-Path: <[e-mail]>     Received: from nvwyu.gov (i528C1073.versanet.de [82.140.16.115])             by gateway.craic.com (8.11.6/8.11.6)             with SMTP id j1R0aU702669             for <[e-mail]>; Sat, 26 Feb 2005 16:36:30 -0800     From: [e-mail]     To: [e-mail]     Date: Sat, 26 Feb 2005 23:17:43 GMT     Subject: You visit illegal websites     Message-ID: <[e-mail]>     [...]

At face value, this looks like a message from the FBI with the From, Return-Path, and Message-ID headers all referring to the domain fbi.gov. But the single Received header tells a different story. The message was received by gateway and because I control this machine, I trust it to report the correct IP address of the sending MTA. The hostname within the parentheses is the result of a DNS lookup by my server, so I also trust this. This is clearly not an FBI host. The domain is owned by an ISP located in Germany, and the alphanumeric string used as the hostname (i528C1073) has the look of an address assigned to an subscriber's computer, most likely at home. Preceding the parentheses is a fictitious domain, nvwyu.gov, which has been created by the sender.

This illustrates how some email headers are easy to forge whereas certain others, generated by trusted servers, can be relied upon. Being able to distinguish between the two is an important skill.

Because the message was generated by a virus infection somewhere on the Internet, there was no need for the originator to hide the identity of the machine that sent the message. Additionally, only one step was necessary to deliver the message, making it impossible to disguise the path it took. Things are very different in the case of spam, where there is perhaps a single source for the messages and the sender really wants to remain incognito. Here are the headers for a piece of spam that touts a pornographic web site:

     Return-Path: <[e-mail]>     Received: from stender.com ([200.217.130.152])             by gateway.craic.com (8.11.6/8.11.6)             with ESMTP id j1MHOWl20248             for <[e-mail]>;             Tue, 22 Feb 2005 09:24:36 -0800     Received: from inkk.tk (MX-HOST.DOT.tk [195.20.32.78])             by stender.com with esmtp             id 1FAAC78CA3 for <[e-mail]>;             Tue, 22 Feb 2005 09:24:37 -0800     Message-ID: <010001c51903$2b95e38f$[e-mail]>     From: "Aggravation E. Envelops" <[e-mail]>

The message apparently originated at inkk.tk and was delivered to gateway.craic.com, by way of stender.com. But things are not as they appear to be. Look at the first line of the top Received header. This was added by gateway, which I trust. The IP address in this line has to have been correct at the time the message was sent; otherwise, the transfer could not have happened. My server has tried to perform a reverse DNS lookup on 200.217.130.152 and failed. Using whois, I can infer that this server is based in Brazil. There is a hostname on that line (stender.com) but it is outside those parentheses. If I run dig on that, it returns 216.10.106.149 that, in turn, maps to a network based in Massachusetts. Now that is quite a discrepancy, and it indicates that this hostname is forged.

Once I have encountered an MTA that is forging its identity, then I can no longer trust anything about the Received headers that describe earlier steps in the delivery route. Any professional spammer is going to be using a specialized MTA that can forge these headers to look like anything they want. Most likely they have purchased commercial software that is intended to perform precisely this task.