Backscatter analyses

Last modified: Monday, 24-Jan-2011 00:52:31 EST

Around June 2007, I began receiving lots of backscatter emails on one of my private email accounts. At first, I thought it was a "joe job" attack, since I have reported spam sent to that account, and thought the spammers were retaliating against me. Now, after analyzing the backscatter, I believe it is an automated joe-job-like spamming technique.

Backscatter is caused when a spammer forges an address of a real user in the "From:" field of her spams, and when some of those spams fail to be delivered (for various reasons, such as invalid To: address, etc.), the "bounce" messages come back to the forged From: address.

By November 2007, I was receiving more than 800 per day! So, I began to analyze the SMTP headers of the spam message that provoked the backscatter. I also looked at similar spam messages posted on Usenet in the group, and I realized that I was not the only person receiving backscatter.

Link between forged "From:" and "Received:" lines

Here are the results of an interesting discovery I made. In a great number of backscatter messages I received, the spoofed From: address will be linked to a forged Received: line in the RFC822 headers of the embedded spam that provoked the backscatter. Note, not all backscatter contains the headers of the orginal message, so I searched on to confirm my hypothesis.

Here are the headers of one such spam (which, in this case did not "bounce", but was reported by the recipient of the spam). It was seen on Google groups:

Return-path: <>
Received: from ([])
        by ******** with esmtp (Exim 4.66)
        (envelope-from <>)
        id 1IwLhF-0004FH-T3
        for ***@********; Sun, 25 Nov 2007 11:55:10 -0600
Received: from [] by; Sun, 25 Nov 2007 17:56:20 +0000
Message-ID: <000701c82f8c$07b7154e$61d26f95@ngixk>
From: "Replica Watches" <>
To: "Watches" <***@********>
Subject: Exquisite Replica
Date: Sun, 25 Nov 2007 16:08:57 +0000

The highlighted parts are the forged parts by the spammer. The From: address is obviously forged, as spammers never give their real address. The following Received: line is also forged:

Received: from [] by; Sun, 25 Nov 2007 17:56:20 +0000

We know it is forged because it does not link to the received line that precedes it, whose "from" part ( does not correspond to the "by" part ( of the forged Received line.

Furthermore, the forgery of the "by" host ( is not arbitrary. The spammers have tried to make it look like <> really sent the spam, by creating a Received: line containing a host tied to through its DNS lookup. For example, doing a DNS lookup of yields the following results:


Here's another example from Google groups:

From Mon Nov 26 00:08:28 2007
Received: from ( [])
        by (8.12.10/8.12.10) with ESMTP id
        lAQ58SST093564 for <>; Mon, 26 Nov 2007 00:08:28
        -0500 (EST)
Received: from ([]) by
        (8.11.6/8.11.6) with ESMTP id lAQ58Rs29724 for <>;
        Mon, 26 Nov 2007 00:08:28 -0500
Received: from [] by; Mon, 26 Nov 2007
        05:08:11 +0000
Message-ID: <000701c82fea$052ea66a$5e6137b7@dtnoh>
From: "Replica Watches" <>
To: "Exquisite Replica" <>
Subject: Exquisite Replica
Date: Mon, 26 Nov 2007 03:20:49 +0000

We apply the same algorithm. We look up the MX for, for example, using


Once again, it becomes obvious how the spoofed "Received:" line is generated.

I have tried this algorithm on several of the 20,000+ (!) backscattered spams I have received, and it's always the case that the Received: line matches one of the hostnames of the results of an MX lookup of my email address' domain name.

My suspicion is that some spammer software is programmed to prepare spams in this manner. It is likely picking an address for the "From:" among some list of potential addresses. The idea here is that if the spam doesn't make it to its intended destination (perhaps because the "To:" address is incorrect, etc.), it will "bounce" to a real user. The world may never know exactly how this is working...


C.P. Fuhrman, “Analysis of massive backscatter of email spam,” Proc. Montreal Conference on e-Technologies (MCETECH), Practice and Theory of IT Security (PTITS), Montreal, 2008. (slides of presentation)


If you have anything to share about email backscatter (perhaps you're receiving lots of it, too?), contact me at .

Christopher Fuhrman Christopher Fuhrman