Updates
Home The Book Training Events Tools Stats
Spam Wars Updates
Spam Wars: Content Updates
The Apparent End of OpenRBL

Appendix B, "An Introduction to Spam Sleuthing," relies considerably on the powers of the Web site openrbl.org. The site was a tremendous resource for a variety of spam research activities. Unfortunately, it disappeared in June, 2005. There was little explanation about its end, but despite having weathered a variety of network attacks over the years, this time it's a voluntary surrender by its mysterious owner.

There are other online resources to fill the gap, but in my opinion, they aren't as user-friendly as openrbl, even though some of them offer additional services that are quite helpful to those wishing to dig into spam machinations.

The site that I'm using more than ever now is DNSstuff.com. This advertising-supported (Google ads) site provides a ton of lookups for things like domain names, IP addresses, and others. Among the most useful entry fields for me are: WHOIS Lookup, Domain Info, IP WHOIS Lookup, and Tracert. This last one, which traces the route through the Internet between the DNSstuff.com server and whatever host or IP address you enter, is one of the best at quickly reaching its destination server.

Although DNSstuff.com offers a spam database lookup, the Mother of All Spam Database Lookups is drbcheck, run by a fellow named Dr. Jørgen Mash from Denmark. The page might be a bit daunting at first, and because this lookup site searches so many blocklists, it can take many seconds to get a return. Be patient. Not all the lists are important, but if you see an IP address from a spam message header appearing on many lists, then you know the IP address is a problem source. I continue to hold the Spamhaus list in high regard, although I would never run a spam block routine based only on one blocklist.

One more resource I'll share is network-tools.com. I tend to use just one of the services of this site: E-mail Validation. I use this to test whether a suspicious email address (like one appearing in the From: field or unsubscribe link of a snarky spam message) is a real address. By entering the address in the network-tools.com field, clicking the E-mail Validation radio button, and clicking the Submit button, you instruct the network-tools server to attempt to make a connection with the address' email server (without actually sending a message—you can see the actual exchange between servers). While some email servers automatically accept every message regardless of address (and then stupidly send a bounce message to the sender if the To: address is not valid), a great many servers will reject attempts to send to invalid addresses. You can learn in an instant whether the supposed email address is a good one (as required by the U.S. CAN-SPAM law) or complete B.S. Of course, if the message forges the From: address by entering a valid address harvested from somewhere, the address will be a "good" one, but not the address of the real sender.

OpenRBL will be missed by this author, but at least we're not left completely in the lurch.

Correction to Page 37

I wish to correct one part of the technical description about how email works in Chapter 4. The first paragraph of page 37 incorrectly states that your email program downloads mail from the server in one swoop. While it may appear to be the case to the user, in truth, the most common email system described in this section (POP) transfers email messages to the email software on your PC one at a time, as the result of a "conversation" between your PC and the POP server. After the server authenticates your email program's connection request as being legit (e.g., through password verification), the typical "conversation" goes like this (translated into English for your enjoyment):

  • Your Email Software (Client): Got any mail for me?
  • Server Software (Server): Yes, 2 messages.
  • Client: Send me the first message.
  • Server: OK. Here's how big it is, and here comes the message (followed by entire message content and an end marker).
  • Client: Delete the first message on the server.
  • Server: First message is marked for deletion.
  • Client: Send me the second message.
  • Server: OK. Here's how big it is, and here comes the message (followed by entire message content and an end marker).
  • Client: Delete the second message on the server.
  • Server: Second message is marked for deleteion.
  • Client: I'm done. See ya!
  • Server: Over and out.

With the successful close of the transaction between client and server, the server deletes from its email file those messages marked for deletion. The system is designed to prevent deletion of email on the server in the event of disruption during transfer of individual messages.