Razorfish Inc. has egg on its face over an email fiasco that occurred recently when the Internet consulting firm sent out the first issue of a new newsletter targeted toward clients. Reports indicate that Razorfish didn't ask permission before adding clients to the new newsletter list, prompting a number of them to email back asking to be removed.
That might not have been so bad, but unfortunately the email list was configured as a discussion list rather than a newsletter. If you've participated in email discussion lists, you know what that means. Every message sent by a user back to the list server got broadcast out to the whole group. As members' email boxes started filling up, more and more of them sent back irate protests to the list server, and in turn those protests were broadcast out to all members.
This is an example of a phenomenon I call a Mushrooming Slugfest. Closely related is the equally frantic Dueling Robots phenomenon, in which two computers get caught in a loop, sending automated messages (with copies to users) back and forth to one another. The Slugfest is more fun because of the human element: Users don't understand the problem, they accuse each other of spamming, and their tirades get more and more desperate and profane as messages continue to spew out from the list server and stack up in people's inboxes.
Both types of goof-up emphasize the importance of thinking out your permission policies when building an email newsletter -- and making sure you correctly understand the settings for your list server. I recommend that you not add anyone to a standing email list without permission. Don't assume that it's all right to use all the contact email addresses in your address book as the nucleus of a newsletter list. Not everyone (even your friends) will want to receive your new publication, and not every address is appropriate for sending commercial email.
These points are illustrated by a hybrid Slugfest/Robots incident I got caught up in back around 1996. At the time, I was publishing an email newsletter called NETResults, using a list server provided by Silverquick (http://www.silverquick.net). One of my subscribers, Mr. Butts (later many people came to feel he was aptly named), decided to start a newsletter of his own, focusing on travel. To build an initial list, he gathered all his contact addresses and added them to an email list server.
Unfortunately, one of the addresses he added to his list was my own list server address. Picture two robots striding into the middle of a dusty street in a little town in the old American West, six-guns strapped to their metallic thighs. A robot duel is about to begin.
You see, whenever my list server received a message it didn't understand, it kindly sent back a help message giving instructions about the correct commands for subscribing, unsubscribing, getting help, and so on. So when the proud Mr. Butts fired up his own list server and blasted out the first issue of his travel newsletter, my list server responded with its help message. That wouldn't have been so bad, except for one tragic factor. Unbeknownst to him, Mr. Butts's list server was configured, not as a one-way newsletter, but as (you guessed it) an unmoderated discussion list.
The duel began in earnest. Since robots have no emotions, their duels are conducted according to the purest logic, most scrupulous courtesy, and most meticulous consistency. Nonetheless, the bloodbath is spectacular.
When my list server's help message arrived at Mr. Butts's list server, his server broadcast my help message out to everyone on the list, including (you guessed it again) my server address, which politely sent back a help message, which was again broadcast out to the whole list, and on and on.
Meanwhile, other people on the list (perhaps a hundred or so) began receiving this same deluge of messages. Panic ensued as baffled list members began sending in fruitless "unsubscribe" requests, which in turn were broadcast to the whole group -- including my list server, which dutifully returned its help message, which was then broadcast to everyone. If you've ever been part of a Mushrooming Slugfest or Robot Duel, you can imagine what kinds of rants and profanities were exploding across the Internet that day.
However, in time, cooler and more educated heads prevailed. Mr. Butts himself had no idea how to halt the melee. But I realized quickly what was happening, and I was eager to plug the dike, especially since my email address appeared in the help message and I was being accused of spamming (and more obscene infractions). With the assistance of Mr. Butts's ISP and the intrepid Gordon Burns of Silverquick, we were able to subdue the combatant droids and drag them off to the lockup. Whew!
The lessons for all of us? Once again: Understand your list server settings. Many list server providers make it hard to see the distinction between a one-way newsletter and an unmoderated discussion list and easy to get them mixed up. And when building an email list, consider carefully your policy for adding members -- go the permission route. Especially when robots are involved.
Understanding the request form...
- What are you selling: Most email campaigns are selling a product or service. Name that product and/or service in this field. (for example: security services, accounting software)
- Target Market: Name here who you see as the market or potential buyers of your product/service. (for example: home owners, accountants)
- Size of your mailing: How many emails do you plan to send -- this will affect your potential revenue and cost. (for example: 100,000 to 250,000)
- Your Time Frame: When do you plan to do your mailing? (for example: mailing within one month)
- Campaign Details: Give a more complete description of what you are planning. (for example: I plan to do 3 sequential mailings to homeowners in New Jersey in order to sell a new security system.)