SMTP has been around since 1982 and is used everywhere. It works, but it’s lacking in many ways, most of which are out of scope for this posting.

Basically the way it works is:

you write an e-mail to your mother (really, you should be calling your mother, but for the sake of this example, you can e-mail her). You click the send button, and your e-mail client (Maill.app, Outlook, etc…) opens up a connection to your mail server (most likely provided by your ISP) and says “Hi, I’d like to send an e-mail”, your mail server says “ok, go for it.”, and your mail client says “to:mom@mom.com subject:hi mom body:Mom, I’m outta money and my clothes are all dirty…”. Your mail server then looks up the mail server for mom.com. Then it opens up a connection to the mail server for mom.com. It says “Hi mail server, I have an e-mail for mom@mom.com, here it is: blah blah blah”. Then when your mom checks her e-mail, she sees your e-mail.
Sometimes usernames and passwords are included with this, to identify your rights to send e-mail through a given mail server.

So here is the fundamental issue I’d like to bring up: your username, password, what you write, and who you write to, are all sent, in plain text, between many computers and across many network connections. Intercepting e-mails, usernames, passwords, and more is very simple.

SMTPS is basically SMTP done over SSL. SSL is the same encryption technology used to make using your credit card on web pages safe and secure. This prevents anyone from snooping on your e-mails. Every single major mail client and mail server supports SMTPS. For some reason by default they just use SMTP.

The only reason I can think of for this, is that in order to use SMTPS, each server needs a SSL Certificate. Universally trusted certificates cost money and have to be installed. Self-signed certificates are free and easy to create, however, they don’t guarantee the identity of the server. So I can picture someone saying “since getting a trusted signed certificate can be a pain, we should default to non-encrypted transport, and just use SMTP.”

Here is the problem with that potential logic: let’s assume that instead of the current system, mail servers defaulted to creating self-signed SSL certificates automatically (with the option to install your own validated signed certificates if you have them), and defaulted to providing SMTPS and attempting SMTPS connections before falling back to SMTP if SMTPS is unavailable. It’s true that server identity validation won’t be provided by self-signed certificates, but we don’t have that now, so it’s no real loss. What we would get out of this is automatic encryption for all mail transport, protecting passwords and e-mail contents, with no effort.

Thoughts?

This idea plays into my larger scope thought, slowly being explained here.

PGP / GPG email encryption is a good thing. It’s a pretty secure system, and the public registries of public keys makes it easy to communicate securely with someone new, with a reasonable amount of trust. One major issue, which I think most people identify as the biggest issue with PGP, is that the popular mail programs don’t support it out of the box, or don’t support it well.

It would be great if every major e-mail program (Outlook, Mail.app, GMail, YahooMail, MSN Mail, etc..) all had built-in support for PGP, and could auto-create public/private key pairs, and upload the public key to the key-server automatically, etc…
And any time you were sending e-mail to someone who had a public key in the key-server, it would ask if you wanted to encrypt it. I also like the idea of auto-signing even non-encrypted mails, and you could then use the signature to validate that sender listed in the from or reply-to headers, actually sent the e-mail. If they don’t, you know it’s very likely to be spam (more on spam later…).

Implementing this using the OpenPGP RFC as a standard really wouldn’t be that hard. There are open source implementations in use today. And tons of available libraries to handle all the heavy lifting. I honestly don’t know what’s holding companies back from this. It would be very easy to do right, and aside from the privacy gains, the usefulness in other areas, like fighting spam, and being able to have some legal trust weight to verifiably signed e-mails, seems like a win-win situation. I’m going to leave my tin-foil hat off for now, and attribute the lack of this being in place to short-sighted non-standards embracing companies, and not governmental pressure.

However, the other MAJOR issue I see with PGP is this: key-pairs are associated with e-mail addresses. There is ideally a one-to-one relationship between e-mail address and PGP key-pairs. In practice this doesn’t work out all the time. I have, over time, had three different key-pairs linked with my primary e-mail address. I’d set one up, then over time stop using it, get a new computer, lose the old private key, and then have to create a new key-pair. So over time it became a one-to-many relationship, which as you can imagine, poses issues. This is just a side effect of the real issue. A PGP key-pair is meant to represent an individual entity (person or virtual person (such as a corporate e-mail address)). Signing something with my private key means that I signed it, not someone else. Message encrypted to my public key, should only be readable by ME the entity. So here is the issue.

People do not have a one-to-one relationship with e-mail addresses.
Currently I, the entity, have about 10 different e-mail addresses. In the past, I have had perhaps 10 other e-mail address, which I no longer control. This means that in order to be able to read all my current and archived mail, I would need to keep 20 private keys, forever.

Going the other way, many families share an ISP e-mail address. Obviously this is becoming less prevalent with the introduction of effective free solutions for e-mail, like GMail, however, it is still, and will continue to be an issue.
The relationship between entities and e-mail address is many-to many. This means that the relationship between entities and pgp key-pairs is many-to-many as well. This is a fundamental flaw in the implementation of PGP as a privacy and signing mechanism.

Tune back to learn how I think we should fix this….