Spam seems to be flooding email systems at an ever-increasing rate. Between April 2 and April 16, I received more than 700 pieces of spam. If you aren't on someone's spam mailing list, you're one of a lucky few. One of the causes of the flood is the covert gathering of marketing information from spam recipients. Most spam messages not only attempt to deliver some type of advertising but also try to gather information about the recipient. If you educate users about this practice and about how to identify spam before opening a message, you can help curb the spread of spam in your organization.
Gathering Information
In my experience, most spam arrives as an HTML message. Many of these messages contain an embedded "beacon." A Web beacon is typically a transparent .gif image embedded in a Web page or email message's HTML code. Because these images are so small and transparent, users rarely notice them. Web page authors embed a beacon in a page so that they can search Web server logs for the beacon and count how many times the page has been requested. Spammers, however, embed beacons in email messages, then use the beacon's <IMG> tag to reference a script on the spammer's Web server, as Listing 1, page 2, shows. When the recipient opens the message, Outlook (or whichever HTML-capable email client the recipient is using) processes the URL, opens an HTTP connection to the Web server, and passes a parameter that identifies the message recipient to the script. This parameter specifies the user's email address or even a database key that links to personal or profile data. (Note that Outlook 2003 and Exchange Server 2003's version of Outlook Web Access—OWA—don't download pictures in messages unless you instruct the client to do so.)
After processing the message, the client expects to receive an image to display. If the server returns an image, it's usually a transparent .gif image that blends in with the background color of the message—hiding the fact that anything extra is happening. In my experience, the server usually doesn't return an image and the client reacts as if it can't retrieve an image. When a Web server doesn't return an image, most Web browsers display the Image not found icon (Microsoft Internet Explorer—IE—shows a small square with a red X in the center). But spammers don't want the user to know that anything covert is happening, so they need to prevent the client from signaling that it can't retrieve the image. An <IMG> statement that includes height=1, width=1, and border=0 definitions results in an essentially invisible 1-pixel image.
When I examined the spam messages I received in the first half of April, I found that 82 percent used some type of beacon. Spammers use these beacons to track the number of "hits" their messages generate, then use that figure to bill their clients. At a minimum, the beacon tells the spammer whether you opened the advertisement. A spammer might send you messages for a variety of products or services; the beacons in the messages you open also can let the spammer know the types of products in which you might be interested. For example, if a spammer sent you separate messages advertising vacations, divorce lawyers, digital cameras, and mortgage refinancing, and you opened the digital-camera message, you'll likely start receiving spam related to photo-processing services (from this spammer or others to whom the spammer sells your email address and marketing preferences).
Although good antispam programs can help block spam, they won't prevent all these messages from arriving. A customer site performed a study to determine the effectiveness of spam filters. The statistics showed that filtering software typically blocks 80 to 90 percent of spam and 2 to 5 percent of legitimate email. Considering that many organizations receive thousands of email messages a day, an antispam program can potentially block a large quantity of legitimate mail. For example, if an organization receives 7000 messages, its antispam program could incorrectly block between 140 and 350 of them. In an organization that deals with medical terms, which might include body parts or a drug named Viagra, the number of blocked legitimate email messages could be much higher. Reviewing the quarantined messages and releasing the legitimate ones would be a full-time job.
When spam does arrive in your Inbox, the best action is to press Delete before opening the message. Deleting the message prevents the beacon from being triggered and prevents the sender from gathering any data. Unfortunately, determining whether an email message is legitimate is often difficult without opening it, so many people will open an unknown message believing that the action is harmless if they don't click Reply or a URL.
Building a Beacon Demo
To help users understand the effects of opening spam, I created an email message that references a beacon script when a user opens the message. The script then sends the user 10 more messages.
Web Figure 1 (http://www.exchangeadmin.com, InstantDoc ID 39501) shows the process and systems I used to create the demo. (I've tested this process on Exchange Server 5.5 and later, Outlook XP, Outlook 2000, and Microsoft Internet Information Services—IIS—5.0 and later; all version combinations worked.) Exchange hosts the mailbox and provides the SMTP transport. IIS provides the Web server engine that runs the Active Server Pages (ASP) script. Outlook 2003 includes new features to help stop beacons, so you'll need to test that version to see which configurations will let the demo function. The starting point is the pickup directory on the Exchange server.
The pickup folder provides a way to place an Internet Engineering Task Force (IETF) Request for Comments (RFC) 821—formatted drop file directly on the file system and have Exchange deliver it through SMTP. The Microsoft articles "XFOR: How to Test Outbound Mail Flow With a File in the Pickup Folder" (http://support.microsoft.com/?kbid=297700) and "XFOR: Exchange Internet Mail Pickup Directory Usage" (http://support.microsoft.com/?kbid=201314) describe in detail how to use the pickup directory in Exchange 2000 Server and Exchange 5.5 environments, respectively. You can use a script to create personalized, RFC 821—formatted messages for each user and write those messages to an Exchange SMTP virtual server's pickup directory, from which the messages are delivered to users' mailboxes. Listing 2 shows the drop file that I used for this demo.