When a mail server receives a mail message it adds a received header at the top showing the ip address that sent the message to it, and what the mail server claimed it's name was etc. All mail headers below the top one are received in the message body from the previous mail server, so can be fiddled with by a malicious mail program.
So if a message
goes through 3 systems, from the users system 'user', through their mail
server 'source.com' to destination 'destination.com'
source.com-->destination.com
Then the received headers will look like this:
Received: from source.com by destination.com
However, if a spammer sends a message, lets say his machine is called spam.com, then it will look like this:
Received: from spam.com by destination.com
Now, to make the message look more real, the spammer simply adds a 'fake' header to the top of his mail message, then the received message will look like this:
Received: from spam.com by destination.com
(forged) Received: from source.com by spam.com
Now it looks right, but only at a casual glance, a close inspection reveals that these headers are not very likely to be true, to spot this type of forgery do the following:
1) Do all receiving servers listed in the headers accept connections on port 25, if not then they could not have actually received the message as indicated.
telnet destination.com 25 (yep works)
telnet spam.com 25 (nope fails)
telnet source.com 25 (yep works)
2) Does
each step in the chain make sense, would a mail server send the message
to the specified destination.
If a mail server is sending to 'destination.com' what ip address should
it send to, is 'spam.com' the correct address ? (no)
Received: from 137-34-50.adsl.terra.cl (200.50.34.137) by aristo.pacific.net.sg with
SMTP; 29 Jun 2004 17:44:02 -0000
Received: from reservoirdroids.com (in2.another.com [216.65.64.233])
by 137-34-50.adsl.terra.cl (Postfix) with ESMTP id FF84EDEE6B for <@pacific.net.sg>;
Tue, 29 Jun 2004 10:18:13 -0700 Message-ID: 100101c45dfd$d82c4613$bba7b27b@reservoirdroids.com>
From: "Ordeals S. Confers" <antisemite@reservoirdroids.com>
To: Subject: =?iso-8859-1?B?UmVwbHkuLg==?=
Date: Tue, 29 Jun 2004 10:18:13 -0700
Ok this message below was received by aristo.pacific.net.sg, and it was received from 137-34-50.adsl.terra.cl
All headers
below that point are written by the sending server 137-34-50.adsl.terra.cl,
so for example
that server 137-34-50.adsl.terra.cl could make up anything it likes, so
unless you know for a fact that
that server is not a spam robot, then you can't trust anything after the
initial received header.
So lets check each server mentioned:
# telnet
aristo.pacific.net.sg 25
Trying 203.120.90.216...
Connected to aristo.pacific.net.sg.
Escape character is '^]'.
220 aristo.pacific.net.sg ESMTP
So, we trust the top header:
Now we examine the next one "137-34-50.adsl.terra.cl", this one looks like the dodgy one, it's clearly from a dial up adsl pool, it's not related to the destination domain, so shouldn't be anywhere in the delivery path, and sure enough, it doesn't respond.
# telnet
137-34-50.adsl.terra.cl25
Trying 200.50.34.137...
telnet: connect to address 200.50.34.137: Connection timed out
So, 137-34-50.adsl.terra.cl
is the source of the spam message. That server wrote this
text:
> Received:
from reservoirdroids.com (in2.another.com [216.65.64.233])
> by 137-34-50.adsl.terra.cl (Postfix) with ESMTP id FF84EDEE6B
> for <@pacific.net.sg>; Tue, 29 Jun 2004 10:18:13 -0700
Which is the bit where it claims to be sending a message from the real server for 'reservoirdroids.com', it does this because having the right received headers in the message can fool some spam filters.
So let me review the points that make it clear this is a forgery.
1) The headers can only be trusted from the top down, until you hit an untrusted server, any below that were written by the untrusted server and so could say anything at all.
2) The first machine in the received list that isn't obviously local to the receiving domain is un reachable, so a mail server could not send spam through it.
3) The first machine in the received list that isn't obviously local is from an ADSL modem pool as shown by the reverse dns of the ip address, a very likely source of spamm.
4) If in2.another.com was delivering a message to the specified destination @pacific.net.sg, then it would send to a server that is in the mx records for pacific.net.sg, and yet the received headers are suggesting in2.another.com sent the message to "137-34-50.adsl.terra.cl [200.50.34.137]" which as you can see is not listed as one of the mx hosts for pacific.net.sg (see below)
pacific.net.sg
mail exchanger = 15 argus.pacific.net.sg.
pacific.net.sg mail exchanger = 15 maxis11.pacific.net.sg.
pacific.net.sg mail exchanger = 7 aristo.pacific.net.sg.
pacific.net.sg mail exchanger = 7 maxis12.pacific.net.sg.
pacific.net.sg mail exchanger = 7 maxis13.pacific.net.sg.
aristo.pacific.net.sg internet address = 203.120.90.216
maxis12.pacific.net.sg internet address = 203.120.90.227
maxis13.pacific.net.sg internet address = 203.120.90.228
argus.pacific.net.sg internet address = 203.120.90.217
maxis11.pacific.net.sg internet address = 203.120.90.226
ns1.pacific.net.sg internet address = 192.169.33.3
ns3.pacific.net.sg internet address = 203.120.90.43
ns4.pacific.net.sg internet address = 203.120.90.44
Implement SPF protection on your mail server see spf.htm