| Downloads |
|---|
| 39501.zip |
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.
Figure 1 shows the message that the user sees in Outlook when Exchange delivers the drop file that Listing 2 shows. I used a known sender in the From field to make sure recipients open the message. The embedded beacon URL (which you can see at callout D in Listing 2) creates a connection to an IIS server, activating the spdemo.asp script, which Listing 3, page 4, shows.
Spdemo.asp reads the user's email address information from parameters embedded in the URL, generates an email message, then makes an SMTP connection to an Exchange server to deliver 10 copies of this message to the user's mailbox, as Web Figure 2 shows.
The messages contain a timestamp specifying when the recipient opened the original spam demo, as well as an explanation of the demo. The timestamp helps reinforce to users that the 10 messages were generated as a direct response to their actions—perhaps helping them understand the consequences of opening real spam.
Setting Up Your Own Beacon Demo
Creating a similar demo for your users is simple. You first need to write a script that the beacon will trigger, then place the script on a Web server. You can use the script that Listing 3 shows, with only slight modification. This script uses Windows 2000's Collaboration Data Objects (CDO) functions to send an HTML message. (For more information about using CDO to generate email messages, refer to "How to Send Rich Email Messages," March 2003, http://www.exchangeadmin.com, InstantDoc ID 37538.)
Edit the code at callout A in Listing 3 by replacing server.domain.com with the name of the SMTP server that supports your users' mailboxes. After you've edited the script, create a directory named "demo" below \InetPub\wwwroot on an IIS 5.0 or later Web server. Using Internet Services Manager (ISM), set the permissions on the demo directory to allow script execution. To do so, open ISM, right-click the demo directory, and select Properties. On the Directory tab, click the Execute Permissions drop-down list, select Scripts only, then click OK.
Next, you need to generate a drop file for each user to whom you want to send the demo. You can use the drop file that Listing 2 shows as a template. To personalize the drop file, you need to modify the seven items that Table 1 lists. (Table 1 references the code at callouts A, B, C, and D in Listing 2.) If you have many users, you can create a script to make the modifications.
Is That Spam?
The focus of the spam demo is to impress upon users that opening spam isn't a good idea. But identifying spam isn't always easy. Most spam messages have subject lines such as "The last flashlight you'll ever buy!" or "I'm spending $93 800 00 to get YOU a $$$$$ CHECK." But some subject lines offer few clues about whether a message is spam. For example, I recently received the messages that Figure 2 shows. I couldn't definitively discern from the senders and subject lines whether these messages were spam.
Fortunately, Outlook provides a way to see where the message originated without opening the message. By right-clicking the message and selecting Options from the context menu, you can view the message's SMTP header. The header contains the sender's SMTP address and information about the originating SMTP system. Figure 3 shows the headers for the "GET IT: News you can use for April" message; you can see that the message was sent from an @hp.com address. However, the sender's address can be forged easily, so you need to examine other information in the header, such as the originating server, to completely validate a message's origin. Although the senders and subject lines read like other spam I've received, it turns out these messages are all legitimate business communications sent from internal Hewlett-Packard (HP) addresses and systems. If I had deleted them as spam, I would have missed important information. So too, users need to take the extra step to validate questionable messages before opening them to avoid activating a spam beacon.
Stopping Spam
Perhaps in the future, the world's legal systems will devise solutions to stop spam so that we don't waste valuable time wading through unwanted junk mail. Technology (such as Outlook 2003's Junk Mail feature) can only slow down spam, not stop it; spammers quickly find ways around what technology blocks. Each email recipient must be part of the solution by knowing how to identify and delete spam before opening it.
