2001 marked the year that spam passed the 50 percent threshold in my inbox. Worse yet, half of this spam is the same spam. Spam used to be bad enough. But now, half the solicitations I get for things like .BIZ domain registration, finding out anything about anybody, teenage porn, and soon are duplicate solicitations coming from different sources. Another reason that 2001 numbers "bested" all previous years is that I've expanded the definition of what I consider spam. It is no longer only the emails I never wanted in the first place. Spam is also the emails that I wanted at one time, but no longer do, and have no way of stopping.
"But David," you say, "surely you're mistaken. The 105th US Congress passed the all-important bill S.1618. Title lll, Section 301 Paragraph (a)(2)(C) of this bill says that spam isn't spam if it includes a removal mechanism." Sorry folks. The law never passed.
Even so, most mail coming from a domestic source (don't get me started about how this law would have been useless when it comes to international spam) appears to have a removal mechanism. The problem is that about 99 percent of these removal mechanisms don't work.
Here's why...
The most common method these emails offer for unsubscribing is a link that says, "click here to unsubscribe" or something like that. About half of these links, I've found, are simply broken. Nothing makes my blood boil like a broken unsubscribe link. But for the ones that aren't broken, what happens next varies widely from one spam to the next.
Removal mechanisms
Not surprisingly, most unsubscribe processes need to know what email address to take off the list. But, for a large majority of the working unsubscribe links that I try to use, it is nearly impossible to communicate this information to those processes. In those cases where the link creates an email containing the word "remove" (or some variant) in the subject line, the process on the other end is relying on the fact that the "FROM:" address in your email will contain the email address that needs unsubscribing.
Unfortunately, many of us have inboxes that receive mail from multiple email addresses. My inbox is attached to no fewer than six addresses. Three of these addresses are the result of changes made to our corporate email system. Regardless of which of the six addresses the spam came to, the unsubscribe process invariably sees david.berlind@cnet.com in the FROM: line. If the spam was sent to dberlind@zd.com (an old email address that still works), I suppose I could go to the trouble of reprogramming my mail client to fix the FROM: address for that one email. Of course, I'd have to fix it right back. But even if I was to actually try this incredibly painful technique, I would still need to know to which email address the spam was sent in the first place.
Have you seen the TO: address in most spams? It's usually a distribution list that offers no clues as to which of your addresses was the one that first received the spam.
Likewise, many of the unsubscribe links take you to a Web site where you must enter the email address that you want to unsubscribe. These are most often the types of links that are broken. Unfortunately, even if the link works, it's useless if the recipient has no idea what address was used in the first place.
The law needs to be more specific
The devil is in the details. And the removal mechanisms' specifics need to be addressed in a law that, in its current form, serves no purpose at all. The law needs to be amended--and merchants who want to earn their customers' respect must adhere to these amendments--as follows:
First, the recipient's email address--the actual address to which the email is delivered--should appear somewhere in the email. It should appear either in the TO: address or somewhere in the body, preferably with text that says something like "This email was sent to david.berlind@cnet.com".
Second, all unsubscribe processes, whether email-based or Web-based, must provide the user with a place to enter that information. With Web-based mechanisms, that "place" is obvious: It's a field on a form with an unsubscribe button. With email based mechanisms, that place can be the subject line or the body of the email. The most recent and shining example of a good unsubscribe implementation came to me today from Comptuers4Sure.com (a subsidiary of Office Depot). At the bottom of the newsletter is a link that says "You are registered at Computers4SURE as david.berlind@cnet.com. Please visit our subscription centre to update your account information." Sure enough, I went to the subscription centre and unsubscribed. I have nothing against Computers4Sure (especially since the process actually works), and I therefore don't consider this to be spam. It was honest email from a company where I have made online purchases.
But the perfect bad example also arrived in my inbox today from a company that, in the spirit of the holidays, I'll spare from identifying. The email they used is actually in the TO: address, and even in the body with this note: "You are currently subscribed to XYZ-text as: David_Berlind@zd.com To unsubscribe send a blank email to leave-XYZ-text-3330726B@list5.XYZ.com." Great. It's a process that will depend on seeing David_Berlind@zd.com in the FROM: address when it receives my request to unsubscribe via email. Unfortunately, I have no easy way of sending an email from David_Berlind@zd.com. I guess that's one email I'll be getting forever (or until I quit). Many people I've talked with have suggested various solutions to this problem. Bottom line: Most people shouldn't have to sneak around corporate standards (ditching Outlook), program rules into their email client (which invariably don't work very well), or download more software just to eliminate a problem we shouldn't have in the first place.
Back to the unpassed law. If it ever gets passed, it needs to be tightened up first with the aforementioned specifics and then it needs to go further into the area of functionality. In other words, whatever mechanisms are provided actually have to work. No broken links. No returned emails announcing that the mailbox to which you sent your unsubscribe request doesn't exist or is full. And fed-up users should have a way to reach a human being. A little good will goes a long way toward helping your credibility.
I'm no hypocrite, either. Over the past year, I've received my share of email from people having difficulty unsubscribing from ZDNet Tech Update's newsletters. Thanks to your feedback, we've taken measures to make sure that every newsletter we send from ZDNet Tech Update includes: the address it was sent to in the body, a link to our subscription centre where you can change your preferences, and an address for customer care in case something goes wrong.
Of course, it's my hope that you'll never feel the need to unsubscribe.
