X
Tech

After authentication of senders, ending spam requires a relationship managment protocol

One thing that virtually every e-mail security expert agrees on is that there's no silver bullet to the spam problem. But if there's the equivalent of a hollow point bullet that can do the most damage (what you want on the first shot), then authenticating an e-mail sender's identity (establishing that the e-mail actually came from the place it claimed to have come from) is probably that bullet.
Written by David Berlind, Inactive

One thing that virtually every e-mail security expert agrees on is that there's no silver bullet to the spam problem. But if there's the equivalent of a hollow point bullet that can do the most damage (what you want on the first shot), then authenticating an e-mail sender's identity (establishing that the e-mail actually came from the place it claimed to have come from) is probably that bullet. Unfortunately, it's not enough. Particularly when the other weapons in your arsenal -- for example laws -- fall into enemy hands.

And that's basically what happened when the government passed the now infamous Can Spam Act. Whereas some of the proposed anti-spam bills insisted that an e-mail sender must have a pre-existing relationship with a recipient before the sender could send unsolicited mail to that recipient, the bill that became law essentially legalized unsolicited e-mail so long as it conformed to certain conditions. For example, for unsolicited e-mail to escape the spambusters, it must contain a functioning means for the recipient to unsubscribe. But unsubscribe from what? E-mails sent by that sender? That organization? That server? That domain? You get the picture. To the extent that recipients consider unsolicited e-mail to be spam, the Can Spam Act might as well have been the Promote Spam Act.

In response to my last antispam blog post (which dovetailed my video) about the collaborative multilateral action that Google, AOL, Microsoft, and Yahoo! must take to imbue the Internet with a defacto approach to sender authentication (ANY defacto approach.. just pick/establish one) , ZDNet reader Peter Bittle wrote/asked:

......I agree that a specific authentication framework, whichever flavor might win, would be the better solution. A question that arises, though, is how would legitimate unsolicited mail be sent, i.e. updates from an ad agency retained by one of your active vendors? Just like the DoNotCall.gov list doesn't include companies you already have accounts with, e.g. your phone company or long distance, would there also have to be some sort of exceptions within this framework?......

And here's a slightly edited version of my response (excuse the disjointedness):

Your question regarding "legitimate unsolicited mail" is a great one that I've talked a lot about. Some people see unsolicited mail as spam no matter what. Others may want to see certain pieces of unsolicted mail. Personally, I think there's another layer of relationship and permission management technology that can work in combination with whatever authentication approach ends up getting used.

Start for example with the idea of unsubscribing. The Can Spam act has already legalized unsolicited mail as long as it isn't fraudulent and under the requirement that recipients can unsubscribe. However, unsubscribing is too non-standard of a process. There should be an unsubscribe protocol that works much the same way e-mail works, supporting a store-and-forward architecture and built-into that protocol are a series of return messages. For example,

1. unsubscribe me from the list that resulted in me getting this e-mail. 2. unsubscribe me from all lists on this server. 3. unsubscribe me from the domain altogether

I'm just scratching the surface, but this is really more about managing your relationship with a domain than it is about unsubscribing. Then, let's say I receive an e-mail from your list server... the first thing my email server does is a check (sort of like "FINGER") that asks, "Does the sender support the relationship management protocol?" If not, the e-mail is simply turned away. Instead of just being used as a convenient way of unsubscribing, REPORT SPAM buttons can be more about managing the reputation of some sending domain as respecting this protocol. It can't be hard to test and it'd be way better than subjective RBLs.

End user systems could be optionally configured by the user to require a pre-established relationship. Perhaps the first time you want to blast me with unsolicited mail, you first must do an equivalent of a knock on my door. First, using the authentication protocol, I verify that you are who you say you are. OK, you past the first test. Next, I get an elevator pitch. "So and so" wants to enter your inbox to tell you about shoes. Then, I can pre-emptively decide to allow it (whitelisting on both sending and receiving servers). This is the equivalent of an "OK, you have my permission." The idea is that unsolicited senders of mail have to earn my trust. It's not assumed (the way the Can Spam Act assumes it) and when you give me the elevator pitch, it had better be honest or I'll turn your domain off altogether.

I could keep going. But some protocols for handling subscription, unsubscription and permission to solicit would be another step in building a different Internet e-mail system. RSS could also play a role. For example, I should have a choice of receiving mail from you via standard Internet mail methods or by way of RSS. Any and all unsolicted mail must knock first. If I look through the peep hole and like what I see, I subscribe to your RSS feed through which you deliver your unsolicited mail. The minute you spam your feed, I turn you off. This way, solicitors never have unbridled access to my inbox.

Does this proposal need work? Absolutely. Is it perfect? No. Does something like this make sense given where we are today? I think so.

I consider this framework to be about putting the control over relationships and permissions in the hands of the recipients rather than the senders (as it essentially is today). If the laws are going to let us down (it's pretty hard for them not to), then the technology shouldn't. It needs to empower us not with something as simplistic as today's REPORT SPAM buttons or the Can Spam's "required" unsubscribe mechanisms, but rather something that's baked into the underlying e-mail protocols so that senders of e-mail, unsolicited or not, must pass the most important trust tests of all: yours.

Editorial standards