E-mail systems could very easily learn what isn't spam too

Perhaps it's time to revive the idea of JamSpam again since there hasn't been a whole lot of industry-wide progress on the spam front in recent years and the spam problem, as far as I can tell, isn't getting much better.Usually when I write something like that about spam, the result is a tidal wave of e-mail from anti-spam solution provider promising me that I won't be sorry if I try their solution out.

Perhaps it's time to revive the idea of JamSpam again since there hasn't been a whole lot of industry-wide progress on the spam front in recent years and the spam problem, as far as I can tell, isn't getting much better.

Usually when I write something like that about spam, the result is a tidal wave of e-mail from anti-spam solution provider promising me that I won't be sorry if I try their solution out. I have two answers for them. First, while many of them may be willing to state that they'll block 100 percent of inbound spam, none of them are willing to guarantee that they won't also block some legitimate mail as well. Heck, I can walk up to anybody's computer and, without dropping a dime, stop 100 percent of their spam. All I have to do is de-install their e-mail software (which in turn means they stop getting their legitimate mail too).

The answer is invariably some system-trains-itself-over-time mumbo jumbo meaning that it gets better with time but never perfect. The minute you have to check the Junk Mail or Suspected Spam folder to make sure there isn't anything hiding in there that shouldn't have been filtered out in the first place is the minute you probably shouldn't be wasting your time with an anti-spam system in the first place? Why bother? If you have to scan another folder for useful mail, it might as well be your inbox.  

My second answer is to go work some standards out and then get back to me. A sender authentication standard, if everyone abides, may not be the silver bullet. Nothing is. But it seriously moves the needle in the right direction. Dating back to the Fall of 2004, the first hope for at such a standard was dashed when Microsoft revealed that it might have intellectual property rights to the technology (Sender ID) in question (or a piece of it) and that it would be looking to enforce them. Recently, Microsoft relaxed its IP-heavy stance on Sender ID, paving the way for those aborted discussions to re-start.

So, unless I missed some news, let this be a call out to everyone who walked away from the table the first time (when Microsoft blew things up) to come back and work it out. Or, maybe like I said, it's time to revive JamSpam where we lock all the key players in a room for the day to see if they can make any progress.  

The point is that there are many opportunities to standardize on bits and pieces of information that are passed back and forth between systems, networks, e-mail clients, and even anti-spam solutions for which there's still room, even after certain anti-spam techs are baked into the infrastructure. I use about five different email systems. I have different inboxes. Some come through Outlook. Others are Web-based. I use Mozilla's Thunderbird for another. One thing I've noticed when using some of these systems is that they don't seem to do one the easiest things they could do when deciding what is not spam. For example, if, after opening an e-mail from someone, I press the reply button, that's a pretty good sign that it's not spam and that future e-mails from that sender should be allowed into my inbox. OK, so maybe some of you reply to spammers to say "please go away."  Well, how about you tweak the rule a bit to say "if I press the reply button and physically write a reply into the message, then it means the sender is not someone to blacklist."

Today, I still get phone calls from people with whom I've e-mailed back and forth many times saying "David, didn't you get my mail?" Answer? "No." Of course, that is until I check the folders where my systems shuffle off suspected spam to, scan them, and sure enough, find the missing message. Whether it's some technology on the server doing this, or some technology on the e-mail client that's taking charge -- it's infuriating to me that some how, some way, neither part of the system is capable of saying "wait a minute...David has actually written to this e-mail address before, so regardless of the content inside that's triggering the spam alarm, let it through."

Is this a 100 percent guaranteed to work all the time idea? No. Because it's entirely possible (especially given how everyone walked away from the sender authentication talks) that a spammer, in their spam to me, could be spoofing the sender's e-mail address to be one that I routinely interact with. So, automatically whitelisting a sender theoretically might let some spam through into my inbox. But in reality, looking at what is making its way to my inbox and junk mail folders, not one e-mail would have actually been such an exception to the rule.

Going back to the division of responsibility between client and server, this is where there is a huge problem that can only be solved by a standard. For example, if, either through watching who I reply to or through a menu option that says "white list this sender," an e-mail client whitelists a specific sender, that won't matter one hill o' beans if the server doesn't know about it and the server has its own set of rules for what gets through and what doesn't.

A great many e-mail servers and ISPs put faith in what third-party real-time black hole lists (RBLs) have to say about certain IP addresses on the Internet. If say, you outsource your e-mail systems (like my small company Mass Events Labs) does to a hosting service and that hosting service pumps all outbound email from all clients through that one IP address, it only takes some bad volume e-mail etiquette on behalf of one of your hosters' other customers to get noticed by an RBL and for a bunch of other e-mail servers and ISPs out there to simply reject your e-mail without further consideration. Without further consideration of what? Well, without further consideration of the fact that, through their e-mail clients, your intended recepients may have whitelisted you (perhaps automatically by virtue of the fact that they have exchanged e-mails with your e-mail address, e-mail domain, or IP address before. 

Today, there is NO way for a POP3 e-mail client like Outlook or Thunderbird to tell a POP3 server "hey, I know your checking some RBLs, but just in case an email comes from these senders, let it through to me." Since there are multiple providers of POP3 e-mail clients and multiple provider of POP3 e-mail servers (eg: Google, AOL, Yahoo, Microsoft, etc.), it would take a common standard so that any client could communicate its whitelist to any server without regard for who made which product. 

Today, right now, mission critical e-mails from my small business are not making it to their recipients even though those recipients have sent and received e-mail to and from our domain tens if not hundreds of times. This has go to stop. If it's time for me to organize JamSpam again to get these standards back on track and enough people want it, I'd be willing to give it another shot.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All