The more technically inclined will recognize this idea as being inspired by both email encryption and existing challenge / response systems.

This post may get a bit technical, but once you think about it you’ll realize how very simple, user friendly, and effective this system is.

Please note that this is a VERY LONG post

Here is my idea: A small, but significant update to email systems. This update has only three parts:

1.) A “friend key” that’s generated once and that the user need never think about
2.) Support for “public door codes”
3.) Routing of older versions of email to an “old mail” folder for a limited time (just like the cut off date for public TV to turn into HDTV)

The long explanation of these few very simple additions:

The “friend key” is a simple hash key of sorts that is generated by the mail service. We’re not talking encryption grade here, though it certainly could be. The string could be based on their email address, their name, the time & date that it was created, and plain’ol random numbers and/or whatever else. I’ll leave that up to the coders, but those are some ideas.

EMail providers such as Hotmail, Yahoo, and GMail would have an “I know this person!” button that would be available when reading email. If it’s clicked then the user would be brought to a page (or shown a window) that explains what the feature is and why they should ONLY use it for people that they REALLY know. If they confirm that they genuinely know the person then a friend request is sent to that person’s email.

This is the part that’s inspired by existing challenge / response systems, but as you can see the idea takes a major hint from existing successful social services. The user is NEVER presented with something technical, ONLY with a system that’s already very familiar to them as a result of MySpace, Friendster, and so on: Thus, the “Friend request”.

An obvious link saying “## Number of Friend Requests” would be clickable and provide a window (or web page) to confirm or deny known or unknown persons. It would also provide a “this is spam” button to submit the key, name, email, and header data to a spammer database where it could be weighed against the number of times it has been flagged as spam.

• Friend requests would NOT have message bodies
• Any friend request found to contain a TLD (such as .com) would be silently deleted and added to a spammer database
• The information presented to “confirm” the person would show only their first name, last name, and email address. If you don’t recognize the name then you don’t know them.
• I’m against the option to add a personal message to friend requests, but I recognize that others may not be against this

NOTE: Friend requests could be sent manually by entering the email address of the person into a special “request to be added as a friend” box. Again, we are drawing inspiration from existing, successful systems being used by social web services available today.

URLs sent via friend requests could themselves be added to a spammer database, and in some cases the owners of web sites that are repeat offenders could be fined under existing anti-spam laws.

When using a program such as Outlook or Thunderbird the address book would be stored in an encrypted form on the user’s HDD. This should help prevent viruses/worms/trojans from spreading your keys and email addresses. If worse comes to worse, however, the user could simply generate a new friend key.

Here is where I draw inspiration from the PGP key system:

Once the two people confirm that they do in fact know each other then their “friend keys” are silently sent to each other. This key is invisibly added to their address book. From this point on their email will automatically be routed to the Inbox by default (though the user could set up filters to direct them as they wish).

If you receive an email from a person that you don’t have a “friend key” for then that email would NOT be viewable by the recipient. At all. Instead, the email provider (or program) would keep a numerical tally that says “## of messages from unknown sources”, or something similar to that.

This list could be automatically purged every 15 to 30 days. There would not even be a “spam folder”, only this “unknown sender” tally would exist.

There would be no risk of clicking a link (phishing), of tracking images, of attachments, or anything else that plagues today’s email. The only emails that enter your Inbox are those confirmed to be “friends”.

So what about folks that you know but who haven’t friended you, but have sent emails to you anyway?

When the person clicks on the “unknown sources” link they would be provided with a list of first names only. If they see the name of someone that they know (who is not already in their address book) then they could click a “more info” button that shows ONLY the first name, last name, and email address. From there they would have a “Junk It” button and a “display full email” button, but the email would be displayed inside of a “controlled environment” where only certain HTML was allowed and links were never clickable (or even masked).

As always, this “unknown list” would be compared to spam databases and anything with high marks could be deleted. Ultimately it will be easier for everyone to send friend requests.

So what about businesses and mailing lists that you WANT to be on? This is where the “public door codes” come in.

When a person signs up for a mailing list they would also provide a “public door code” (or whatever you want to call it). A new, unique code should be associated with every mailing list that the person signs up for. With this system, it will be OK if “Amazon” is used when signing up to Amazon.com.

Personal messages (to themselves) could also be allowed that will be included with the mailing list’s introductory message.

How and why would this work? How would this not be exploitable by spammers? Though they would certainly try, this system has significant ability to reduce (or eventually perhaps even eliminate) spam.

On the technical side, businesses would have this “public code” sent as either part of their headers or perhaps the email format could look like someone@gmail.com+publiccode.

The end user would have to add public codes to a list. On the surface this sounds like it would scare people away, but not really. It would be the same thing as adding “friends”, only there is no challenge / response per se and you don’t need an email address. Only the “door code”. You just need a user-friendly interface to add the codes to (and remove from).

OK, but what stops this from being exploitable by spammers? We’re not talking automatic delivery just because it has a door code:

• If a code isn’t in the person’s safe list then the email is silently added to a separate 15 to 30 day que (similar to the “unknown sources” tally)
• This que would not need to be available to the user, so these emails (and even the tally) need never be seen (though could be available by way of an “advanced” options window)
email addresses, mail servers, and other static header information of popular sources such as amazon.com and newegg.com could be maintained in a white list provided by mail providers or programs (like Thunderbird or Outlook). messages from white listed sources could produce a notification to the user if they have not yet been confirmed.
• When a user enters a public code into their OK list then a list of all emails that use that code could be presented. If white listed services are present in this list then they are the ONLY services that are presented to the user (though an option of “it’s not in the list, show me other possible matches” could be presented)
• once a “door code” is confirmed to be associated with a sender then all OTHER emails in the que that use that code are deleted and marked as spam. From that point on, all messages received that use the confirmed public code that do not match the confirmed message’s static header data are silently deleted with their information being added to spam databases
• If a “door code” is ever deleted from the list then all messages associated with that code are silently dropped but need not be added to a spam database. in some cases, unsubscribe requests could be automatically sent to white listed services when their door code is deleted

Yes, spammers and phishers would continue to flood random email addresses, but the vast majority of those spams would go unviewed and unanswered. Yes, though, I have to admit that I’m sure a few idiots would somehow figure out a way to still fall victim to it.

However, this would drive a seriously nasty pointy object into the hearts of spammers and phishers. The number of victims would be reduced dramatically, and selling email addresses to other mailing lists would have its value significantly reduced.

In the end, it’s a very simple system that requires little time and little effort to add. Tack on a few years or so for mail providers to comply to the new standard (ala public analog TV to HDTV) and you have a fairly gentle upgrade path.

This simple system is then wrapped inside of the very familiar, very user-friendly interface that we all use on social websites, and a ‘key list’ is maintained by mail providers and/or mail programs. Yet as simple as it is it would provide tons of power to mail providers (and programs) to virtually eliminate spam.

Look at the amount of money that spam costs everyone each year. Compare that cost with the cost of adding a few new features to your mail server / service. The choice in dollars ought to be obvious.

Some may say that upgrading mail servers and services is “too much”, but filters will never be enough and the problem of spam continues to grow. Something needs to be done at a deeper level, and I believe that my suggestion is relatively inexpensive, user friendly, and should be comfortably familiar to today’s Internet users.

Many people don’t like change, but for a little bit of change can go a long way.

~Steph

Technorati Tags: spam, anti-spam, email