UNIX System Administration Handbook - Evi Nemeth [358]
1: From jimdelno@apexmail.com Thu Nov 11 10:31:41 1999
2: Received: from saturn.globalcon.com (saturn.globalcon.com [209.5.99.8]) by
xor.com (8.9.3/8.9.3) with ESMTP id KAA15479; Thu, 11 Nov 1999
10:31:30 -0700 (MST)
3: Received: from hamilton ([168.191.61.20]) by saturn.globalcon.com
(Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-35881U1500L100S0)
with SMTP id AAA148; Thu, 11 Nov 1999 12:33:24 -0500
4: Date: Thu, 11 Nov 1999 02:39:57 +0000
5: Subject: Free Information On "Debt Reduction!"
6: Message-Id: 7: From: F.Pepper@pmail.net 8: To: benfranklin@onehundred.net Line 2 is a valid Received header. Line 3 is also valid, but traceroutes from xor.com, the destination, to hamilton (168.191.61.20) and saturn.globalcon.com (209.5.99.8) show that those two sites have nothing to do with each other. 168.191.61.20 is on Sprint’s dial-up network, and judging from the time zone indication, it might be in Europe. 209.5.99.8 is a company in Ontario, Canada. saturn.globalcon.com is probably an open relay. They are not running sendmail, but rather version 3.1.2 of the Post.Office mail transport agent from software.com. On line 4, the date added by the sender’s user agent is about 2:00 a.m. in Europe, 2 hours before it was received on the machine saturn.globalcon.com. Perhaps the recipient list was very long and took 2 hours to process. Or perhaps the message was composed off-line on the spammer’s PC and then submitted to the Internet at a later time. The time zone indication (if it isn’t forged) is 5 hours different—the same as the difference between Europe and the East coast of the United States. On line 6, the host portion of the Message-Id should be a fully qualified domain name, not just the local part “hamilton”. The host hamilton is probably misconfigured, because the unqualified name also appears on line 3. The portion of the Message-Id to the left of the @ sign typically consists of numbers. In this case it contains random letters, which indicates that the line might be forged. Line 8 is clearly forged. The actual recipients’ addresses were only on the envelope of the message and do not appear anywhere in the headers. This message might actually be from F.Pepper@pmail.net. The hostname pmail.net resolves to a valid IP address, and whois says pmail.net is a British telecom company. Among the twenty or so spam messages we examined for this section, this one alone might have contained enough information to make up a reasonable complaint (to the hostmaster indicated in DNS for the IP address in line 3 of the header). Never complain directly to the spammer or the spammer’s domain. SpamCop is a software package that parses mail headers and identifies which lines are real, which are probably forged, and which are totally bogus. It provides users who submit spam messages via email or the web (spamcop.net) with a blow-by-blow description of the headers and tells which pieces check out and which don’t. This site also makes it easy to submit a spam complaint. The complaint includes all the relevant information that you gleaned from parsing your headers. SpamCop was implemented by Julian Haight. We ran SpamCop on our first spam example above, which tried to sell us a CD full of address lists. It determined that the gaia.es Received line was OK, but that the domain wgukas.com was fake. It then determined that gaia.es did not have the IP address the mail said it did and that the real culprit was probably at a site called ttd.net. Clearly, SpamCop’s analysis was much better than ours, and it only took a few seconds. Here’s a small snippet of a SpamCop analysis for some fresher spam: Received: from sun1.cskwam.mil.pl (cskwam.mil.pl) [148.81.119.2] by mail1.es.net with smtp (Exim 1.81 #2) id 12oBHL-000494-00; Sat, 6 May 2000 13:34:23 -0700 Possible spammer: 148.81.119.2 "nslookup cskwam.mil.pl" (checking ip) [show] ip not found; cskwam.mil.pl discarded as fake. "dig cskwam.mil.pl