There's a useful corollary to this that helps to understand why "remove" options for spammer mailing lists are set up the way they are, to foil "removal". The victims aren't paying the spammer to "remove" the victims' addresses from the spammer's list. If the victims want to be removed, they need to have it handled more locally to them, and not by the spammer.

Most "remove" options are onerous and many are deliberately broken. They start with multiple hoops to jump through, but the hard-working victim who successfully negotiates those often encounters a vaguely worded error at the end. An example of this is the "suppression" system operated by eds.com for 3com.com.

(The 3com.com spam is particularly egregious. Filing a trouble ticket about a hardware failure on a Tipping Point firewall is enough for 3com.com to slam and spam the victim endlessly. The spam that then arrives is full of threats about it continuing unless the victim properly "removes" themselves. Yet such removal is not possible. As a result of that misbehavior, I'll never buy their crap^Wproducts again...)

Once past the brokenness, for those spammers that let their victims get so far, the "remove" is then typically undone in a few months or a year. The normal excuses given the victims when the company decides to do this are 1) the delivery options changed so of course the victim is signed up again because that's the default, or 2) there was a database error, so of course the victim is signed up again as that's the default. A great example of this is ebay.com's use of both excuses.

Why do spammer companies engage in this kind of abuse? Wasn't the initial slamming and spamming bad enough? In a word, no, at least not for the spammer. The spammers' economic interests which caused them to add the spam victims to their lists in the first place don't go away when a victim jumps through the "remove" hoops.

In particular, if the victim wasn't actively purchasing sufficient amounts of product, the spammer really doesn't have any business to lose by spamming them. "Remove" just isn't going to work in that environment when it's handled by the spammer.

Spam victims should instead pay attention to their own economic needs in this resulting war against their mailboxes. If they want to be "removed" from a spammer's lists, they should rely on someone whom they're paying (or who is otherwise beholden to them) to make it happen.

That's what we do. At the most basic level, we make the remove happen locally, where the spammer can't easily "forget" it. Moving on, we can then make the remove happen for all spamming customers of the spam-for-hire operation hired to send the spam.

When doing this, sometimes blocking outright makes the most sense. Adding to that, providing economic back-pressure against the spammer by notifying upstream providers of the blocking can be fruitful; it's rare, but the provider may actually kick the spammer off their network when the abuse is pointed out to them.

However, the best option for protection occurs when we have a spamtrap/tracking address in the mix. We'll most often use it to monitor the spam stream to detect the spammer (and spammer-for-hire) morphing and dodging around the net. As they move to new nets, we can automatically adjust the protection we provide our regular user addresses by blocking mail from those new sewers. The trapped spam is also great automatic input for shared scoring (like Maia Mailguard) & checksum operations (like DCC), which can protect even more users from the spam, especially at other organizations.

In the end, considering the economic incentives tells us why spammers will contrive to have their "remove" systems fail. More importantly, it shows us where to apply an actual functional remove system (or better, a tracking+remove system); on our own systems under our own economic control.

Richard Johnson