A Received: header is similar to a paper mail message's postal cancellation. It is attached to the mail message by a `post office' to record the time at which a mail message passed through. Paper mail usually has only one `cancellation' but with email there are usually several, recording the sites that the email message passed through to get to you. It is of the form:
Received: from x.com (dd13-058.compuserve.com [199.174.155.58])
by m1.sprynet.com (8.6.12/8.6.1) with ESMTP id IAA22660; Mon,
24 Feb 1997 08:20:46 -0800
One Received: header is always prepended by each host in the delivery chain as it receives the email message. Normally no other headers are added or modified by the intermediate hosts however if the message is missing a Message-id:, Date:, From: or To: header (ie. forged) it will often be generated and prepended automatically, occasionally special X-? and Resent-? headers are prepended to log unusual operations that have occurred and the final recipient site might prepend a Status:, From (Note, no `:'), Return-path: or Delivered-To: header. Thus if a Received: header is after any header except these headers it is probably forged and it and the headers after it can not be trusted.
Key point: At some stage the spammer had to pass their forged email message on to a responsible host; that host's Received: header is the one you should be using to determine the identity of the sender of a forged email message.
The from x.com is usually forged by most spammers. The (dd13-058.compuserve.com [199.174.155.58]) is the verification data (where it was really received from) that the receiving site (in this case m1.sprynet.com) added to the Received: header. This should be reliable unless the spammer has forged the entire header, in which case you need to look at Received: headers further up the list (later timewise).
The by m1.sprynet.com is the host that added this Received: header. The (8.6.12/8.6.1) with ESMTP gives the version number and name of the email transport software (a `Mail Transfer Agent'/MTA or `Mail Server'; in this case it's sendmail v8.6.12 with configuration file `sendmail.cf' v8.6.1). The id IAA22660 assigns a unique id to the email message for that host, as distinct from the Message-id: header which should be unique to the whole net. The Mon, 24 Feb 1997 08:20:46 -0800 is the timestamp of the Received: header and -0800 is the time zone, -8 hours and 0 minutes in this case.
You can often tell when forged Received: headers have been added because the data they provide is inconsistent; in particular if there is a big gap in the timestamp (or even a timewarp!) between successive Received: headers then the later-in-the-list headers are likely to be forged. Another thing to watch for are formatting errors like multi-line headers having the second or subsequent lines unindented.
If the (dd13-058.compuserve.com [199.174.155.58]) is missing it means that that site is probably not verifying ie. it's either negligent or the originator of the forged message. If you're very lucky then they are verifying, simply not placing it in the Received: header. You need to send email to the postmaster at the site and depending on their policy they may or may not tell you who the sender was.
Sometimes only an IP address and not a host name is given between the first ()'s and you need to do a Domain Name System (DNS) reverse lookup (ie. DIG ipaddress->hostname) to determine the corresponding host name. Occasionally a username (x@y) is also given but the method used to determine the username (x) is easily fooled so you shouldn't trust it too much.
This Received: header pattern is standard. Sometimes extra elements are added (eg. via x and for x@y). See rfc821 & rfc822 for more details. Some unusual sites add Received: headers that do not conform to this standard. Fortunately these are rare and such non-standard Received: headers are very likely to be forged.
To learn more about forged email you should try forging email to yourself. To do this you will need access to a telnet program that can access a TCP/IP `port' other than the default telnet port 23 (most do). Look at your telnet documentation to see how. Under Unix it's specified as a number separated by a space or colon from the hostname (what you type is red and the computer response is green). eg.
telnet kryten.eng.monash.edu.au 13
Try it! Press Enter at the end of the line. If your web browser supports it the equivalent URL is telnet://kryten.eng.monash.edu.au:13/. You should get something like this back:
Trying 130.194.140.2... Connected to kryten. Escape character is '^]'. Mon Mar 10 16:55:42 1997 Connection closed by foreign host.
Some telnet implementations may be configured to exit before you have a chance to see this message; see if there is a `hold on exit' option. Port 13 is the time port; the host you connect to displays the local time and closes the connection. The email (SMTP - Simple Mail Transfer Protocol) port is 25, the web (HTTP - HyperText Transfer Protocol) port is 80 and the news (NNTP - Network News Transfer Protocol) port is 119.
Now, replacing target@email.address with your own email address and relay.host with a host that relays third party email messages, eg. one you just got a spam through, and terminating each line with Enter do this:
telnet relay.host 25 Trying 1.2.3.4... Connected to relay.host. Escape character is '^]'. 220 relay.host ESMTP Sendmail 8.7.3/8.6.4 ready at Mon, 10 Mar 1997 17:06:44 +1100 helo my.funny.host 250 relay.host Hello xyz@kryten.eng.monash.edu.au [130.194.140.2], pleased to meet you mail from:<a@b.c> 250 <a@b.c>... Sender ok rcpt to:<target@email.address> 250 Recipient ok data 354 Enter mail, end with "." on a line by itself From: kilroy@was.here To: who@knows.where Subject: Testing - please ignore Hello world! . 250 RAA23002 Message accepted for delivery quit 221 relay.host closing connection Connection closed by foreign host.In a few minutes you should receive a forged email message like this:
From a@b.c Mon Mar 10 06:08:51 1997
Return-Path: <a@b.c>
Delivered-To: target@email.address
Received: (qmail 21305 invoked from network); 10 Mar 1997 06:08:45 -0000
Received: from relay.host (1.2.3.4)
by email.address with SMTP; 10 Mar 1997 06:08:45 -0000
Received: from my.funny.host (xyz@kryten.eng.monash.edu.au [130.194.140.2])
by relay.host (8.7.3/8.6.4) with SMTP id RAA23002
for <target@email.address>; Mon, 10 Mar 1997 17:07:19 +1100
Date: Mon, 10 Mar 1997 17:07:19 +1100
Message-Id: <199703100607.RAA23002@relay.host>
From: kilroy@was.here
To: who@knows.where
Subject: Testing - please ignore
Hello world!
Points to note:
Try experimenting and see how the message you receive reflects the commands that you used to forge the message. For more details on SMTP and email format see rfc821 & rfc822.
To verify spammer email addresses without sending email to them try doing this, replacing spammer.mail.server.host with the name of a spammer's mail server and root with the username you want to verify:
telnet spammer.mail.server.host 25 Trying 1.2.3.4... Connected to spammer.mail.server.host. Escape character is '^]'. 220 spammer.mail.server.host ESMTP Sendmail 8.7.3/8.6.4 ready at Tue, 11 Mar 1997 10:56:27 +1100 vrfy root 250 <root@spammer.mail.server.host> expn root 250 <system@some.other.spammer.host> quit 221 spammer.mail.server.host closing connection Connection closed by foreign host.
The vrfy (verify) and expn (expansion) commands tell you if the address you specify exists on the mail server you are talking to and, if it exists and is forwarding email, where email is being forwarded to. Many mail servers don't support them but if they exist they can be useful for getting past aliases.
If these commands aren't available you can use a rcpt to: without following up with data (ie. an incomplete SMTP transaction) to determine whether a recipient address is valid. Similarly, mail from: without following data can also be used to see what sender addresses they are blocking `up front'. Note however that this tells you nothing about what processing they do with an email message once it's been taken. Use the rset (reset) command to restart after each incomplete SMTP transaction.
Julian.Byrne@eng.monash.edu.au (NO JUNK EMAIL) / Last modified: Wed Sep 10 13:23:28 AEST 1997
Copyright © 1997 Julian Byrne [Monash University Disclaimer]