www.MarkTAW.com/technology/ASimpleSolutionToSpam.html (printable version)

A Simple Solution To Spam (And Phishing)
A high level overview of a method that I think can be used to create trust relationships between people using email to reduce the amount of spam that gets to us. Feedback & loopholes welcome.

I thought of this a year ago, but never expanded on it, but seeing An Effective Solution for Spam, I decided to write up my ideas.

Precedents

This system is based on existing technologies.

  1. For years now, programs have existed that will ask you to manually verify your existence. When I receive an email from someone who isn't on my white list, my system will send them an email to ask them to verify they exist. This is effective in reducing spam, but if they never respond to the verification email, I never get their message.
  2. In Yahoo Messenger, if someone adds you to their friends list, it asks you if you want them to be able to see you and send you messages.
  3. PGP and other open key encryption protocols (such as GPG) allow me to both digitally sign and encrypt messages for a particular person.
  4. CAPTCHAs are those little pictures with words in them that you use to verify that you're really a human being and not a computer. Unfortunately, computers are getting better and better at circumventing these.

It's also based on existing concepts.

  1. If I sign up for a forum, I'm allowed to send messages to other forum members. Because everything happens in a closed system (the forum software), I can be sure that the person sending me the email is someone I trust.
  2. There is an email system (I forget the name) that's designed for security. Your message never leaves their servers, and the person who receives the email has to go to their servers to pick it up. It's impossible for someone in between to intercept the message and read the email first without the system knowing, and it can be deleted after the intended recipient views it. Again, because the system is closed, it's impossible to spoof another person's identity.

The Original Concept - Individual Mail Servers

If everyone had their own mail server, which other people logged in to in order to send you mail, you could have as much control over this environment as you wanted. You could use a CAPTCHA to verify that someone is human, and you would know every person on your system, you could upgrade them to trusted sender, or you could downgrade them to spam or trash.

This system is an expansion on this idea, and while there are many more players involved - other mail servers, email clients, etc. the concept of a trusted system that verifies people and gives them trust relationships remains the same.

The Solution

This system is based on human verification and trusted senders. It uses 3 levels to notify someone who receives a message who the sender is.

You could substitute Red/Yellow/Green if you like too. Here's a step-by-step breakdown of how the system works.

  1. I upload my public key to my server.
  2. When you add me to your address book/add my name to the "to" line of your email, your email client sends a message to my server stating that you'd like to add me as a contact.
  3. My server will respond with my public key and a CAPTCHA.
  4. When you send the message, you type in the CAPTCHA, encrypt and sign it, along send along your public key. I can now verify you're human.
  5. When I receive your message, it's listed as gray (you've verified you're a human being), and I can choose to either blacklist you, or add you to my trusted white list.
  6. All future emails from you, I can verify are from you because they're signed, and I can verify they're for me because they're encrypted.

Most importantly, this system fails nicely. Any mail server or client that doesn't use this system will still work, but emails sent using it will never be upgraded to trusted status. While you can trust an email address, you can't verify that it actually is from sender. Perhaps these people can be given a special status... taupe or eggshell (just kidding).

Public Key Databases & Phishing

If your bank isn't yet in in your tusted system and they send you an email, you need to be able to verify it's from them. Their key should be associated with a public key database. This can be a third party like Verisign, or on the bank's domain. This way you can verify that an email from yourbank.com is really from yourbank.com.

Someone attempting to spoof yourbank.com could not gain trusted status because they couldn't spoof the public key. Even if yourbank.com isn't in your trusted system yet, a quick trip to the associated public key database (automated, of course) could verify that the email is legitimate.

This behaviour should mimic SSL, and as much care should be taken to keep the integrity of this information as is used with SSL keypairs.

Bulk Mail & Non-Human Generated Emails

If you join a mailing list, it's not really possible for the sender to encrypt every email for each recipient (technically, it's possible, but it could tie up the computer for a while). Mailing lists, and other non-human generated emails should have a special status. They will digitally sign their emails, but they won't encrypt them individually for each recipient.

System emails, like automated verifications should also fall under this category.

These are 90% like signed & encrypted messages - you still know who the sender is - but the recipient is in question, and it could be used to spoof the sender, fowarding an email that isn't intended for you. So they'll also enjoy a special status.

Large Organizations

Large organizations with many employees could use a master key / keyring relationship. This way you can simultaneously verify that the email is from your bank, and the banker in question. Again, a public key database should be used to prevent disgruntled employees from using old keys to being able to spoof the bank. The bank should be able to revoke a key, and by clicking on a "verify" button in your email client (or it's web equivelant), your email client should attempt to retrieve the certificate from the public key database.

This is one step beyond whitelisted, now instead of you trusting the sender, you're asking the bank to trust the sender as well.

Failsafes

Even though each message is encrypted, a secondary plaintext email can be sent along with it. This is similar to how HTML encoded emails send a second plain text version for non compliant email clients. Or, since everyone is now using encryption, it could be used for secure communications.

In order to maintain a trust relationship with everyone, you should be able to back up your private keys. Also, it would be a nuisance to have to restablish trust with everyone if you lost your list of public keys. The public keys you trust - being public - could be backed up on the mail server easily. Your private key could be encyrpted and then uploaded on to the mail server, requiring a password to decrypt it once you download it in to a new client, but this method seems somewhat insecure.

What level of privacy you require, and what methods you use to safeguard your privacy are up to you. Again, these keys should be treated with the same care as SSL keys.

Looks like someone's implemented something very similar & it's catching on.

Message Board: http://www.marktaw.com/forum/list.php?f=1

page first created on Tuesday, February 01, 2005

this site and it's contents copyright Mark Wieczorek