E-mail is facing a decline. This is something I lament, and I plan to write more about that general problem, but today I want to point out something that is true, but usually not recognized. Namely that E-mail today is often secure in transit, and we can make better use of that and improve it.

The right way to secure any messaging service is end-to-end. That means that only the endpoints -- ie. your mail client -- have the keys and encrypt or decrypt the message. It's impossible, if the crypto works, for anybody along the path, including the operators of the mail servers as well as the pipes, to decode anything but the target address of your message.

We could have built an end-to-end secure E-mail system. I even proposed just how to do it over a decade ago and I still think we should do what I proposed and more. But we didn't.

Along the way, though, we have mostly secured the individual links an E-mail follows. Most mail servers use encrypted SMTP over TLS when exchanging mail. The major web-mail programs like Gmail use encrypted HTTPS web sessions for reading it. The IMAP and POP servers generally support encrypted connections with clients. My own server supports only IMAPS and never IMAP or POP, and there are others like that.

What this means is that if I send a message to you on Gmail, while my SMTP proxy and Google can read that message, nobody tapping the wire can. Governments and possibly attackers can get into those servers and read that E-mail, but it's not an easy thing to do. This is not perfect, but it's actually pretty useful, and could be more useful.

Most of our internet is designed by people presuming e-mail is totally in the open. So you regularly get E-mails saying, "We have a new bill for you, we are not going to include it in the email, you must now log in to your web site to read the message." This is the norm for sites with even the mildest sense of security.

But the reality is, if your address is on one of the major providers that has gone all-encrypted like GMail has, and they use outgoing encrypted SMTP, they can send you that E-mail with pretty high confidence in the security of it. It's a level that I would be fine with all the "go to our web site to read this message" emails that I get being just sent directly to my address. And they should be fine too.

Sure, if you are worried about spy agencies or the sort of hackers who can get into Google, you should not trust this. But most of us should. And it's only getting better. Thanks to our efforts at EFF with "let's encrypt," more and more servers are coming up by default ready to use encrypted channels for mail.

For a simple step one, sites could gather a list of domains known to be link-secure. That means they are known to encrypt all traffic, and also that they do not rely on any "mail exchanger" sites to receive their mail and forward it on, unless they are also link-secure. Since you could throw major sites like GMail on that list right away, you would already be enabling a very large fraction of the world's e-mail population.

For step two, we should define a way for sites to declare they follow proper link hygiene on mail they receive.

1. They are enabled for SMTP over TLS, so that anybody who attempts to mail them using that succeeds, with no fall-back to unencrypted.
2. They only permit users to read their mail over encrypted protocols like IMAPS, POPS or HTTPS for webmail.
3. If they use a mail-exchanger (MX) site, it is also configured this way, and always forwards the mail over encrypted link.

In this world there are still a few risks. A user could forward their mail to an outside address. In spite of all efforts, a link might get misconfigured and fall back to unprotected. (Encryption fall-back is always a dangerous thing, but it is necessary here as you must take mail from anybody.)

In the case of the mail forward, that's OK because the user chose it. But sometimes it is the sender who demands the security, so we need to step the game up a bit.

• Mails desiring this level of security would be tagged with a header
• Any compliant server attempting to send such a mail would drop and bounce the message back to the sender if it could not establish a secure link to the target server, and the target server did not assert it is link-secure.

We don't want a lot of mail bouncing, so this would be tied with a companion record to the MX record which defines where e-mails go on the internet. (If the MX record can be extended safely this could be done instead.) This extra flag would for any MX or A record site, indicate if the site declares itself link-secure at that MX point. Mailers could know if the mail will be kept link-secure, and send real messages. If a link is not link-secure, they could decide to send a different message -- such as the "Pick up your message at our web-site" ones that are so annoying

In the event of a failure of a link believed to be link secure, the message can either be bounced (letting the sender decide what to do) or possibly this could trigger the sending of only a safe section of the message to the recipient. For example, the message could contain a MIME part marked as the one for insecure messages, and it could contain an explanation or the information on how to log in to pick up the message.

This proposal has the virtue that almost everything is in place, or will be in place soon, for it to already work. Sites would just need to update MX records. Sites could also declare their status in any SMTP dialog and senders could remember that. The information could come with a TTL (lifetime) to say how long you can remember it. The advantage of this approach is that a change just in the mail software is enough.

The downside of doing this is it might make us even less motivated to get end-to-end encryption working. We do need secure e-mail. In spite of the fact that people won't send you billing information in e-mail, almost everybody uses it as the basis of all account security. Almost every site will let somebody who can read your email do things like reset your password, or worse, get it mailed to them! It's crazy to imagine that we think mail is unsafe for sending your phone bill, but good enough for this.

But even before any protocol changes, we could start this today, by simply tagging the larger sites that are already link-secure. Indeed, if we did that, I would switch to using a GMail for all site sites that want to send me secure E-mails. They would be forwarded to my regular email, but as long as GMail does that link-secure, it's safe from taps on the link.

Mail protocol changes

• A database of servers with known link security levels to get things going before any protocol or DNS changes. Most major mail providers will be already in it.
• SMTP servers would be able to declare their level of link security upon connection, which means
  • 1: They always attempt encrypted SMTP to other servers
  • 2: If they host mail, they only allow reading it over secure protocols
  • 3: They are able to bounce mail rather than forward it over an insecure link if requested.
  • 4: They are able to bounce mail rather than forward to a server without the same level of security.
• Mail sending tools can know some addresses will follow link security rules, and send confidential mails to them. (ie. Point to web site if mailing unknown domain, just send the data directly if going to gmail or similar.)
• Mail sending tools can tag messages with desired levels of link security, and handle bounces for security downgrades.
• A parallel to the MX record which declares the link-security of a mail exchanger even before connecting to it