May 3rd, 2007
Against the growing tide of spam, here's one anti-spam standard we desperately need. Now.
If you've followed anything that I've written in the last few weeks, then you'd know that for the business I run on the side, I've got Google's Gmail set up to be the SMTP e-mail server that services the company's e-mail domain. In other words, when we exchange e-mail with other people, they don't see someperson@gmail.com. For free (yes, free), as a part of a brand called Google Apps, Google will actually host your company's e-mail system and give each user up to 2GB of storage. That actually dwarfs the storage they allow me to have here in my CNET Networks inbox (CNET Networks is the parent company to ZDNet). I can't imagine very many users needing more than 2GB. But if they do, for $50 per user, you can upgrade to the Premier Edition of Google Apps and everybody gets 10GB of storage. You also get a bunch of other stuff as part of Google Apps but I've already discussed that in other posts (and will continue to discuss it in future posts).
Once you've got Google hosting your company's e-mail systems, you can use any e-mail client (Outlook, Thunderbird, etc.) that supports the POP3 protocols to be your e-mail front-end. For now, I'm using Mozilla's Thunderbird, Version 2 of which just recently emerged from beta. I'm not particularly crazy about the Web interface for GMail and as such, can't remember the last time I actually used it to check my mail. So far so good, right? At first, there doesn't seem to be anything wrong with this picture. I send and receive company e-mail using Thunderbird. The fact that Google is driving the back-end is completely transparent to me and everybody I send mail to. But, as it turns out, there is a problem and it's not specific to Google. It's true of any e-mail service provider that allows POP3 access to their inboxes (just about every ISP qualifies too).
Talk to the systems administrators at any e-mail service provider or ISP and they'll tell you that they've got their own anti-spam systems in place that try to determine with some degree of confidence what is and what isn't spam. The net result of these automated system is that some e-mails are blocked altogether. In other words, they never even make it to your inbox. Other e-mails are flagged as potential spam and automatically shuffled into a special Junk Mail folder from where only you can rescue it. That is, if you look for it.
But let's say you're using a POP3 client to read your e-mail. If spam is shuffled off to a Junk Mail folder, unless you deliberately use the Web client to view the contents of that Junk Mail folder, you might never know that an important e-mail was mistakenly deposited there. Likewise, given how imperfect anti-spam systems are and the way there is no setting that perfectly blocks all junk mail while letting all legitimate mail in, some amount of spam invariably makes it all the way through to your e-mail client (again, Outlook, Thunderbird, etc.).
Most e-mail clients have reached a level of anti-spam sophistication where they're like a second layer of defense. If your e-mail service provider didn't detect that something is spam, the e-mail client just might and toss it into a junk mail folder. But here's the rub. Let's say you check that folder and discover something in there that isn't spam. Most e-mail clients give end-users the ability to add the sender of that e-mail to their safe-senders list. But there's no safe-senders protocol so that the same list is communicated down the line to the e-mail service provider. There should be. Likewise, if something you consider to be spam squeaks through to your inbox without getting trapped by your e-mail client or your e-mail service provider, not only should you be able to tell your e-mail client to dump future e-mails from that source into your junk mail folder, the act of doing so should, via some standard protocol, signal that preference to the e-mail service provider as well.
Think of it this way. Companies like AOL and Yahoo have a button on their Web mail interface that allows users to report an e-mail as spam. But shouldn't the act of blacklisting an e-mail sender through your e-mail client result in the same outcome? It doesn't. That "request" stays trapped in your e-mail client.
This sort of signalling back and forth between e-mail clients and servers as to who end-users consider to be spammers and who they consider to be safe-senders would be relatively trivial given the prevalance of Web services APIs on the Internet today. I know there's a great deal of debate around other potential anti-spam standard, but this one would be relatively easy to implement and would be of great benefit of everybody and it's time that Microsoft, AOL, Yahoo, Google, and any of the other major stakeholders in the Internet e-mail ecosystem get together and resolve this problem. Otherwise, we will have missed a great opportunity to empower end-users with the tools they need to define for themselves what is, and what is not spam.
Finally, it's time that e-mail clients and server got more intelligent in the way they go about deciding what is and what is not spam. Just yesterday for example, my fellow blogger George Ou sent me some e-mail regarding an offensive message on another blog. But he sent it from one of his non-CNET addresses. Even so, it was an address with which I have interacted with a great many times. How many times must an e-mail to a specific e-mail address emerge from my e-mail client and pass through my e-mail server before both decide that future e-mail from that address can't possibly be spam? After all, if I'm responding to a particular sender more than once (to account for the obligatory e-mail based unsubscription process), shouldn't my e-mail client and server be getting the message (pun intended).
