Relabel the Email Send Button “Make Public”

By Marvin Waschke

Email is not private. Ever.

We’ve heard a lot about email security during the last year and I am afraid people may have gotten some wrong impressions from the discussion. Most of the debate has been over the use of secure email servers. People may get the impression that using a secure email server makes the information in email private. Securing an email server makes it difficult to snoop into email stored on the server, but that is only a small piece of the picture.

Using email for critical private information is unwise under any circumstances. I fear this point is lost in the discussion. An email server is only one vulnerability in the chain of vulnerabilities from sender to receiver. You can never be certain, even reasonably sure, they are all safe.

Sending information in an email exposes the information in ways you may not realize and cannot control. Unauthorized snooping is not the only problem. Any email sent or received over company email belongs to the companies involved, not the sender and reciever. A business may be legally required to make their email public in court. An additional danger is the email message you receive may not be the message your correspondent sent to you. The sender in the email header may not be the real sender. Email was designed for convenience, not for integrity or privacy of communications.

My attitude, and that of a few other software and network architects with whom I have discussed it with recently, is to treat an email as a postcard, open to anyone who cares to snoop.

How email snooping works

To understand email security, you have to know a little about the email system architecture. There are five components: the email sending client, the receiving client, the connecting infrastructure, and the sending and receiving servers. Usually the sending and receiving clients are a single piece of software, like Outlook or Thunderbird, but the sender and receiver each has their own client. In addition, unless you are sending email to someone in your own domain (in other words, the right side of the “@” in both addresses are the same) the email will go from the sender’s client to the sender’s email service to the receiver’s email service to the receiver’s client. The connecting infrastructure is usually the Internet, and it can be the most vulnerable part of the process. Sometimes email is encrypted on the wire, sometimes not.

As an email sender, you can protect your email client by choosing a reputable email service, managing your email account passwords carefully, and following good security practices on the devices you use for sending and receiving email, but you cannot control the receiver’s elements in the chain. No matter how careful you are, there are still many opportunities for tampering with the email you send and receive.

Email encryption

However, you can do something: you can send encrypted messages that you encrypt yourself and your recipients must decrypt themselves. That eliminates most of the issues. The problem is that you can’t send an encrypted message to just anyone because you and your recipient have to share a secret key. This is the method behind PGP (Pretty Good Privacy) that technical types have used for a long time for email privacy. Some off-the-shelf products require less technical skill to use than PGP, but senders and recipients still have to share some secret information before the communication takes place. Off-the-shelf products can hide the sharing and lessen the pain, but you and your correspondents will probably still have to use the same kind of email client. Unfortunately, much of the time, the less pain you go through in set up, the easier the system is to hack.

Emails encrypted today will be easy to hack in a few years

Email that I encrypt myself is the only kind that I consider secure. But I also keep in mind that encryption-based systems are still fallible. What is safe today may be vulnerable tomorrow because all encryption can be broken if sufficient computing power is applied. Today, breaking the most secure encryption requires decades of compute time, but tomorrow’s computers are likely to be much more powerful. Also, if an encryption key gets into the wrong hands, the message is no longer private. If a careless recipient saves an unencrypted copy of a message, it is no longer private. A strong but poorly implemented encryption is still weak. Encryption products that ought to have been secure have been found insecure through implementation errors.

Email places your message in the hands of strangers

Email was, like the Internet, designed for flexible and open communications. Its complex and sprawling structure will not change overnight. Computer and network security in general has improved greatly in recent years, but the criminals have gotten better too.

The upshot is that secure email servers do not secure email. I, and many other software engineers and architects, regard all email as insecure. Period.

Hitting the send button makes it public.

About the Author

Marvin Waschke was a senior principal software architect at CA Technologies. His career has spanned the mainframe to the cloud. He has coded, designed, and managed the development of many systems, ranging through accounting, cell tower management, enterprise service desks, configuration management, and network management. Waschke represented CA Technologies on the DMTF Cloud Management Working Group, DMTF Open Virtualization Format Working Group, DMTF Common Information Model REST Interface Working Group, OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) Technical Committee, DMTF Cloud Auditing Data Federation Working Group (observer), DMTF Configuration Database Federation Working Group, W3C Service Modeling Language Working Group, and OASIS OData Technical Committee (observer). On his retirement from CA, he was honored as a DMTF Fellow for his distinguished past and continuing significant contributions to the DMTF and continues his work with the DMTF on cloud standards. Waschke was the editor-in-chief of the CA Technology Exchange (an online technical journal). He is the author of Cloud Standards: Agreements That Hold Together Clouds and How Clouds Hold IT Together: Integrating Architecture with Cloud Deployment.

Marv Waschke's latest book is Personal Cybersecurity (ISBN 9781484224298).