Hide full article
Nearly two years ago, I wrote an article in TidBITS-347 called "Those Bulk Email Blues," which outlined issues surrounding unsolicited commercial email ("spam"), and how to respond to those messages.
<http://db.tidbits.com/article/00863>
Although much of that article remains relevant, times have changed. Spam continues to increase: since 01-Jun-98, I've received nearly 800 spams, an average of more than 11 per day. Further, spammers frequently probe my network looking for mail servers to exploit - my servers are locked down, but occasionally I run a dummy server that reports attempted spamming back to the originating network (and laughs gleefully when it does so). I'm also a party in the TidBITS lawsuit to test Washington's anti-spam legislation.
<http://www.tidbits.com/anti-spam/>
Don't Be Complacent -- During the last two years, I've become convinced that failing to report spam responsibly contributes to the wider spam problem. By failing to report spam, Internet users send an implied message to network providers, and hence to spammers: "This message didn't bother me enough to report; therefore, it is acceptable." If Internet users want spamming to stop, they must send a consistent, explicit message: spamming is unacceptable. Users can send that message by working toward effective legislative and technological solutions, and by reporting spamming incidents.
The problem is how to report spam. Most spammers try to cover their tracks: they use bogus return addresses, insert false headers, and relay messages through unsecured mail servers. Nonetheless, it is possible to figure out where you should report most incidents. Doing so requires time and some knowledge - but, as with all things, the more you do it, the easier it gets.
Identifying the Server -- To report a spamming incident, you must determine what Internet server sent the spam message to you, which means looking through the message's Received headers. Ignore return addresses or From lines: they're easily forged. Received headers are typically grouped near the top of a raw email message and appear in a particular order: the topmost header is the most recent, and (in theory) the bottommost indicates the message's origin. Email messages always have at least one Received header.
The bottommost Received header may not always identify the originating system. Spammers often forge one or more Received headers to throw you off the trail, but they can't forge them all. Forged Received headers appear beneath any legitimate Received headers and are often obviously different.
The only guaranteed way to figure things out is to start from the topmost Received header and work down. Look for the first Received header that claims to have sent the message to the domain where you receive email. If you have an account with EarthLink, for example, look for the first header that mentions an EarthLink system. Here's a fictional header that points to a location on my network:
Received: from Fred (pointless.quibble.com [204.57.207.56])
by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700
You can see the system smtp100.earthlink.net received a message from a machine calling itself "Fred," a name probably supplied by the spammer. However, EarthLink's mail server didn't blindly accept Fred's statement of identity and performed a DNS lookup, discovering that Fred's canonical name is pointless.quibble.com. (All Internet machines have at least one unique IP number; machines don't require any assigned name, but can have many names, only one of which is canonical.) EarthLink's mail server inserted pointless.quibble.com in the Received header along with the machine's IP number to make it easier to track the origin of the message. This is good - these days, mail servers at many responsible Internet providers tag messages in this manner. Now you know the message came to EarthLink from quibble.com, and that's probably where you want to send your spam report. Let's look at a more complex example:
Received: from pointless.quibble.com (pointless.quibble.com
[204.57.207.56]) by smtp100.earthlink.net (8.8.8/8.8.8)
with SMTP id MAA17789 for <your_name@earthlink.net>;
Sun, 9 Aug 1998 12:55:13 -0700
Received: from Fred by pointless.quibble.com id QQfbjb05104
Sun, 9 Aug 1998 12:54:34 -0700 (PDT)
Here we can see that a machine calling itself Fred connected to a machine calling itself pointless.quibble.com, which didn't do any checking on Fred. Then, pointless.quibble.com connected to EarthLink, which confirmed the machine's name and delivered the message to you.
This second instance is probably a case of "relaying," where a spammer found an exploitable mail server in the quibble.com domain. This particular server would be a spammer's dream because it doesn't identify the machine that sent the message in the first place. The administrators of quibble.com may not be involved with the spammer and may not even be aware their system was used to distribute spam. You still want to report the incident to quibble.com and strongly encourage them to disable relaying on their mail server. Unfortunately, there isn't enough information to track the spammer further; hopefully, quibble.com's mail server keeps logs that would enable its administrators to determine the spam's origin.
If any of your mail is forwarded to you from another address, you may need to ignore one or more topmost Received headers. For instance, all mail to <geoff@tidbits.com> is forwarded to me at quibble.com. The topmost Received line in spam to <geoff@tidbits.com> always says that quibble.com received the message from tidbits.com. But the TidBITS server didn't originate the spam; I need to look at subsequent Received headers to see what machine sent the message to the TidBITS server.
IP Numbers & Ranges -- Sometimes even a well-configured email server won't be able to look up a canonical name for the machine giving it an email message. A Received header might look like this:
Received: from 204.57.207.56 ([204.57.207.56])
by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700
To report this incident, you need to figure out who's responsible for the IP number 204.57.207.56. First, try a DNS lookup yourself to see if the number has an assigned name. Many utilities will perform a DNS lookup. For the Mac, I recommend Peter Lewis's $10 Mac TCP Watcher or Peter Sichel's $20 IPNetMonitor, both of which also include traceroute tools.
<http://www.stairways.com/mtcpw/>
<http://www.sustworks.com/~psichel/products/ product_ipnm.html>
Looking up 204.57.207.56 should reveal pointless.quibble.com, which indicates that you should report the incident to quibble.com. But let's say no name turned up. Your next best bet is to use a Whois server to determine who's responsible for that IP number. The Whois protocol enables you to ask a network authority for information about domains, systems, and points of contact for Internet sites. Unfortunately, there is no central network authority for the entire Internet. The American Registry for Internet Numbers (ARIN) maintains a good Whois database for domains registered in the U.S.; I always try ARIN first. Other network authorities include the InterNIC, RIPE (for European domains), and APNIC (Asia Pacific). Services like Allwhois.com try to be comprehensive but are more useful for determining if a particular domain is available, rather than figuring out IP number assignments.
<http://whois.arin.net/whois/arinwhois.html>
<http://rs.internic.net/tools/whois.html>
<http://www.ripe.net/db/whois.html>
<http://www.apnic.net/reg.html>
<http://www.allwhois.com/>
You may have to check with several authorities before you find who's responsible for an IP number. You may also have better luck searching for a range of IP numbers using an asterisk ("204.57.207.*") than looking for a single IP number, although you'll need to be careful interpreting the results. Multiple searches are awkward via the Web; you can also use a dedicated Whois client to query the databases directly. On the Mac, try IPNetMonitor or Peter Lewis's $10 Finger, which can query Whois servers.
<http://www.stairways.com/finger/>
If you look up 204.57.207.56 or 204.57.207.* via appropriate Whois servers, you find Northwest Nexus, which is my upstream ISP. If you were to report a spam incident from my domain to Northwest Nexus, I'd be taken to task quickly. Not all providers are that responsible, however; if spamming persists from a domain or an IP number after you've reported a few incidents, you can use a Whois server to figure out who's upstream from the responsible party - usually AT&T, Sprint, UUNET, or another large network provider. Most high-level network providers have a low tolerance for spam, but may only be able to forward complaints to their customers, such as regional ISPs. In my experience, reporting spam to upper-level network providers is only moderately effective.
If you can't use Whois to figure out who controls an IP number, your last option is a traceroute utility. Traceroute essentially figures out the path that packets are taking between two Internet machines. This path should show you what sites are "closest" to the IP number that sent the spam. You could send spam reports to the domain indicated as "closest" to the IP number that sent the spam message. However, be aware that Internet routing is dynamic: although the specific path between two machines usually doesn't change from moment to moment, it can change at any moment. Machines near your target IP number may have nothing to do with the spammer or the organization responsible for the IP number. If you report a spam incident using data obtained from traceroute, do so politely.
How to Report Spam -- When reporting a spam incident, include the complete text and headers of the message you received: administrators need this information to verify the incident. A courteous, professional message is always more effective than a vitriolic rant. I begin my reports with this boilerplate text:
I received the following unsolicited commercial email ("spam") that was either sent directly by one of your users, relayed through a mail server on your site or network, or sent from a dialup pool or downstream network administered by your organization. I've enclosed the complete message below with full headers; please ensure this doesn't happen again.
Since I live in Washington State, my messages also point to information about Washington's anti-spam legislation and mention the per-incident damages Washington residents can try to collect.
Send spam reports to the username "postmaster" and, optionally, "abuse" at the domain you've determined is responsible for the spam. The postmaster address is almost universally valid for a domain; the abuse address is less common but is often set up as a reporting address for spamming incidents.
For best results, always report spam to an address at a domain, not to a specific machine. In the examples above, you would use <postmaster@quibble.com> rather than <postmaster@pointless.quibble.com>. If the spam originated from a site using a two-letter country code (such as .us) rather than a three-letter top-level domain (such as .com or .edu), the domain will contain at least three parts (reno.nv.us) rather than two (quibble.com).
Removal Services -- What about removal services listed in spam messages, or sites purporting to be "global remove" lists? Two years ago, I recommended these removal services, figuring that responsible bulk mailers (there are a few) will remove your name from their lists and irresponsible ones have your address anyway, so there's no harm in trying.
Today, I can't recommend any removal services. Although a few are legitimate, far too many are either non-existent or simply address-collection clearing houses. One instance I chased down turned out to be a sophisticated operation used by several spammers: they collected the removal requests, then sold the senders' addresses to other spammers as "fresh addresses."
Don't Just Take My Word for It -- The issues surrounding spam are often the subject of debate. Although this article contains technical information and tips, in the end it's just my opinion. If you're interested in learning more - including other opinions about responding to spam or current legislative and technology initiatives - some of the links Adam has collected regarding TidBITS's anti-spam lawsuit are a good place to start.
<http://www.tidbits.com/anti-spam/spam-info.html>
Will the techniques outlined here stop the flow of spam into your mailbox? No. Is reporting spam simple? No. But at least reporting spam appropriately is an alternative to complacency, and you'll have the satisfaction of hearing from providers who have shut down spammers thanks to your reports. For that alone, many people will thank you.
