Why certified/authenticated email cannot solve spam

February 2, 2008

There are a number of schemes for dealing with spam that boil down to 'people will get SSL certificates, you only accept email with a valid certificate, and if people still spam the certificate authority will revoke their certificate'. There is a simple, core problem with these schemes:

Certificate revocation never works.

Certificate authorities are paid by the people who they issue certificates to, not by the people accepting those certificates. The people who provide the money do not want their certificates revoked, and so it is not in the economic interests of the CAs to revoke certificates. So they don't. Oh, they always have reasons, and sometimes they are pushed to revoke a certificate or two to keep their business rolling in, but that's it.

(The other problem is that revoking certificates does not make the CA any money; it is a cost center, not a profit center. And any organization spends as little on cost centers as they can get away with, which means that cost centers inevitably work badly.)

The same is true of schemes for email authentication. In practice, pretty much the only time that a certificate is going to get revoked is if it was issued to the wrong organization. If it was merely 'misused' inside the organization, that's an internal matter for the organization, not something that the CA will get involved in.

(This entirely ignores all of the practical problems with certificate revocation, which are highly non-trivial.)


Comments on this page:

From 206.168.172.26 at 2008-02-03 20:22:36:

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

Written on 02 February 2008.
« Isolating network interfaces on Linux
A note to would-be photo editing applications »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 2 23:14:20 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.