Open letter to e-mail vendors: Your spam fix doesn't work. Time for a complete redo?
The makers of anti-spam solutions (be they stand-alone or ones that are built-in to existing e-mail solutions) would have you believe that their solutions are worthy of battling spam and merit your attention if ridding your inbox (or inboxes) of spam is important to you. They're full of it. The proof? We're worse off today than we were five years ago when they were selling us the same rotten bill of goods. The percentage of overall e-mail that's junk continues to rise unabated. The effort to which most of us must go to deal with the problem costs untold sums of wasted time and money (and somehow, some people think this state of affairs is OK). Where many organizations like banks might use e-mail to regularly communicate with their customers, they don't bother.
It's going on five years since I first organized JamSpam -- a meetup of the major e-mail solution providers that spanned two single-day events at CNET's headquarters in San Francisco. I was tired of writing about spam and decided instead to try to do something about it. Now that 10-20 e-mails per day that actually belong in my inbox are somehow getting automatically shuffled into the junk mail folder, I'm feel like it's time to give this another try.
There are many dimensions to the SPAM problem. But at the end of the day, it really boils down to three issues. First and most importantly, one man's junk is another man's treasure. What is spam to me may not be spam to you. This has major implications on the two remaining issues: With near 100 percent accuracy, (2) keeping the unwanted e-mail out of our inboxes and (3) making sure the wanted e-mail gets in. What this means for the final solution, if we're ever going to get one, is that the knobs and levers for adjusting what stays and what goes have to be available to every recipient of Internet e-mail on an individual basis.
Vendors who make money providing anti-spam solutions would like you believe that their solution is that final solution. However, to the extent that some customers or people buy one solution and others buy another and those solutions don't talk to each other, the result is a non-standard approach to a global problem that simply doesn't work. If you're one of those solution providers thinking you've got to set me straight on this, don't bother. Don't even send e-mail. I promise to delete it. For more than five years, you've been lying to us, telling us that your solutions are the end-all be-all solution to the spam problem. Yet the problem keeps getting worse.
Today, I get more spam than I ever did and despite having two supposedly good anti-spam solutions in place -- one at the enterprise level and another at the desktop level -- the real problem isn't how much spam I get but rather the time I'm spending looking through my junk mail. Once you have to start scanning your junk mail folders for legitimate mail (what, in the spam world is referred to as a false positive), the entire point of your anti-spam solution has been defeated. In fact, it's worse than defeated because now you have take more steps to process your legitimate mail than you'd normally take if all your mail, including the unwanted mail, just came straight into your inbox.
At this point, some anti-spam solution providers are chomping at the bit to tell me that I've simply got the wrong solutions in place and that I need their solutions instead. What they fail to understand is that their solutions are tactical at best. They may actually do a decent job solving the problem for their customers at some point in time, but ultimately, these are selfish approaches. The idea isn't to do a better job than the next guy at blocking the bad e-mail while letting the good e-mail in. Sure, some solutions may work to the satisfaction of some number of customers . But what about the rest of the Internet users? To make all of us more productive, save money, and for e-mail to become a reliable means of communication that we and our constituents can trust, the idea is to make spamming a complete waste of time and money.
Back in the days of JamSpam, the answer to the SPAM problem was, as it is today, for everyone with a stake in the Internet's e-mail system to get together and agree on some new standard technologies and rules for how different e-mail solutions talk to each other about e-mail security. This was the point of JamSpam. To get everyone talking.
From an attendance point of view, JamSpam was a huge success. Should some new standards have emerged from the effort, just about everyone who would have been impacted by those standards was there. For example, the major e-mail service providers at the time (AOL, Microsoft, Earthlink and Yahoo -- collectively referred to as "AMEY") were there. So too were the behind-the-firewall e-mail solution providers like IBM, Novell, and Microsoft (a different Microsoft group than the first). Most of the third party e-mail security solution providers were there too -- companies whose reason for being was the Swiss cheese like nature of e-mail security and to whom any industry agreements were probably threatening. Then, there were the e-mail marketers and e-mail marketing solution providers. They were clearly worried. So long as no industry standards for securing e-mail from spam existed, they had so-called run of the mill (and still do, no thanks to the lobbyist-watered-down anti-spam legislation).
Today, there's more discussion between the stakeholders than there was before. Some of it an outgrowth of JamSpam. But the truth is that most of them have returned to their cubbyholes and nothing is being done at an industry level to move the needle. Meanwhile, the spammers are winning the cat n' mouse game. Working with e-mail is more unproductive than it's ever been. There's more spam than there's ever been. More legitimate mail is getting trapped than has ever been trapped before. And finally, fewer people are seeing e-mail as a reliable form of communication. For example, e-mail as a means for banks to get in touch with their customers is pretty much useless since most customers have learned that the safest way to avoid phishers (a type of spammer) is to avoid any e-mail that looks like it comes from their bank.
Perhaps just as important is the fact that e-mail has a bunch of other weaknesses, that in the course of developing standard approaches to the spam problem, could be addressed simultaneously with the same solutions. For example, I think Bloor Research's Nigel Stanley did a good job of communicating The importance of 'whole journey' e-mail encryption, particularly when he mentioned:
A more suitable encryption option would be to put in place a security technology that requires all messages to be encrypted at the time they are sent from a client - any client. That way there would never be insecure email traffic, as we would have whole journey encryption for each and every email being sent.
A problem with this approach is how to make the email encryption seamless to the user. Asking users to manually encrypt emails each time they are sent is a surefire recipe for wasted investment in security technology.
Although he doesn't state it outright, he implies that encrypting an e-mail from the very beginning to the very end of its journey is not a task that's seamlessly integrated into our existing e-mail clients and servers in a way that it just works. Especially when that e-mail must endure a transfer through the Internet to a recipient's e-mail system that is dissimilar to the sender's. Fixing the problem not only requires standard approaches to encrypting and decrypting e-mail, but also the baking of those approaches into all e-mail technologies in such a way that users don' t have to do much more than press the SEND button on the e-mail they just drafted to make it work. Today, solutions exist. But they've proven so cumbersome to use that almost no one uses them.
As it turns out, from a redesign perspective, seamlessly baking such encryption capabilities into the Internet's e-mail infrastructure is enough of a kissing cousin to solving the spam problem that two can be addressed with a common approach. Many spammers for example, rely on anonymity to do what they do (often pretending to be someone they're not). But, if as an e-mail recipient, I demand that all e-mail sent to me be encrypted e-mail, the technical requirements involve an additional barrier to anonymity than what exists today. I'm not saying that it's an insurmountable barrier to spammers. But the more of these standard approaches that we take to solving multiple e-mail security problems at one time and the more that these approaches are interoperably layered together, the more of a layered defense that the Internet's e-mail system has around it, and the harder it becomes to for spammers to do what they do, anonymously.
While the aforementioned encryption scenario is but one example, it is also a case that would probably involve additional expense to the sender. For example, for me to accept an encrypted e-mail, the keys to open that mail might have to resolve to a Certificate Authority that I trust. Doing business with reputable CA's that I and the majority of other e-mail recipients trust could very well turn into an economic disincentive to the senders of spam.
Many people today, including some solution providers, believe such economic disincentives are key to the abatement of spam. Some people think that a universal charge for each piece of e-mail is the key and there are a variety of schemes and solutions that cater to this belief. These schemes and solutions are meritless. Not necessarily because they're bad ideas. But because the Internet community is far too irreconcilably divided over the issue of charging a toll for the usage of standard Internet protocols (The Simple Mail Transfer Protocol is the long-time standard and freely accessible protocol for transferring e-mail across the Internet). These divisions range from the philosophical to the geographical to the political (at the industry and international government levels). The result is that we have a bunch of chargeback and e-mail bonding solutions, most of whose usage results in a profit to someone (part of the problem) and none of which ever have a snowball's chance in hell of being baked into the Internet's e-mail infrastructure as a standard.
At best, to the extent that some of these solutions arrive seamlessly into our e-mail solutions, they will only work on a subset of our e-mail (as is the case with most solutions today).
What are some examples of the standards I have in mind? The one I most like to talk about is a signaling system between e-mail clients and servers that communicates anti-spam rules from the former to the latter. For example, if I use an e-mail client like Outlook to collect my mail from a GMail-based inbox, I can tell Outlook to add certain senders to the blocked sender list (this is mostly a placebo, but let's assume that the e-mail system also has built into it a means for authenticating that a sender is who s/he said s/he is or is really sending e-mail from the domain s/he purports to be sending an e-mail from).
One reason you might have picked GMail is because you can check your mail from any Web browser. But if Outlook has no way of communicating your blocked sender rules to GMail (which it doesn't), then the next time you check your GMail inbox through a Web-browser, mail from senders that were blocked with Outlook will very likely be sitting right there in your GMail inbox. Likewise, perhaps your Web mail system has a way that you can automatically block certain senders and send their e-mail to a junk mail folder. Junk mail folders exist so you can periodically scan them to make sure everything that's in them belongs in them. But unless the Web mail system in question uses the IMAP protocol which can keep server-based and client-based folders in synch with each other, there's no way for the contents of the server's junk mail folder to flow down stream to the e-mail client's junk mail folder. Thusly, there's no way for you to check the junk mail being trapped by the server unless you physically check your Web mail system via the Web.
Another standard I like to talk about is a relationship management standard. The easiest way to talk about this is in terms of unsubscribing from a newsletter, but it goes well beyond that. Today, we have a federal law (the Can Spam Act), which, as far as I'm concerned is an e-mail marketer's dream. Instead of having provisions in it that make it illegal to send automated e-mail (regardless of its nature) to someone you have no pre-existing relationship with, it (1) presumes to define spam (recall that one man's junk is another man's treasure) and then (2) basically says it's OK to raid someone's inbox with unsolicited mail so long as that mail satisfies certain requirements. One of those is that it must have a valid means of unsubscribing.
But here's why it's a house of cards. There's no defacto way for unsubscribing. Some e-mail marketers (some would call these people spammers, I'm being cordial) provide a mailto: link that automatically starts an e-mail and populates its subject or body with the words "unsubscribe" or "remove" and the TO: field with some e-mail address that's especially set up for receiving such unsubscriptions. Other e-mail marketers may offer you a link to a Web page that kicks off some unsubscription business process on some server. Not that e-mail is a better solution, but the latter approach doesn't work if you have no connectivity.
When, in an attempt to respond to someone who has sent us an e-mail, we press the REPLY button, we are in essence kicking-off our own business process that results in the creation of an SMTP message. To the extent that I can generate SMTP messages whether I am on or offline, why can't I also create relationship management messages whether I am on or offline? For example, if you send an e-mail to me, three things should be possible. First, before my server can even advance the message to my inbox, it should be able to check that the server it was sent from supports the Internet's relationship management protocol (RMP). If it doesn't, the server should be able to, at my direction, refuse the mail altogether, triggering a message back to the sender that they must first enable their e-mail server for RMP support before my inbox will accept e-mail from it. Second, once RMP is enabled and I receive e-mail from you, I should be able to terminate my relationship with you, the sender, if I want. Third, I should be able to, at my option, terminate my relationship with your server's domain so that any e-mail coming from it (whether it comes from you or someone else) is refused and a message is returned explaining that an RMP rule has refused the message.
As I build RMP rules for my inbox, they are codified into an XML file much the same way RSS subscriptions can be codified into OPML. Call it RMML (Relationship Management Markup Language). RMML files can be moved around so that the rules I set up for one e-mail system can be applied to others (if I use more than one inbox or switch e-mail service providers). As an e-mail recipient, I start by whitelisting all e-mail, or blacklisting it. In other words, I can start by letting all e-mail through and then adding RMML rules as e-mails come in. Or I can start by letting no e-mails in and forcing senders to invite me into a relationship first.
If you're a sender who thinks you should have access to my inbox, the RMP protocol also provides a means of sending an RMP invitation. Invitations are a standard part of the RMP protocol and there's no text. It's simply an invitation. When your e-mail client gets an RMP invitation, your e-mail client presents it to you as a standard e-mail message that displays the credential of the sender. In some ways, it's like a LinkedIn or FaceBook invitation where connections aren't possible until you explicitly allow them. Instead of having the standard reply, delete, forward, and other buttons you see on most e-mail messages, your e-mail client would be smart enough to give you two choices: accept or deny. After you pick one, the next RMP protocol event is an RSVP to the sender.
I could keep going, describing these ideas in further detail or describing more of them. But it's not the ideas themselves I want to be considered. It's the idea that if the entire e-mail industry really wanted to see an end to spam, it could do it. It could get together and come up with standard ways for dissimilar e-mail systems to talk to each other in a way that spammers would be very quickly be ostracized from the system. But, despite their promises, don't count on that happening any time soon. Why? It's not in their best interests to make spamming a waste of time. If it were a waste of time, many of them would go broke. About the only solution provider I could commend -- Microsoft -- should be commended not on the basis of its solutions, but in its zeal to hunt down and prosecute spammers to the fullest extent of the law. Unfortunately, it's like the leaky damn. Put one spammer away and another one, or a hundred, turn up.
Lastly, every time I write about spam, I get flooded with e-mails from people and solution providers who think they've got the silver bullet. They're usually too many of them for me to reply to so please accept my apologies in advance for not writing back if you take the time to write me. I'll try to read them all. Just as soon as I finish wading through my junk mail folder making sure I've seen all the legitimate mail.