For those who don’t know, email is not owned by any one company. There are no copyrights or patents associates with email in itself. It is an open standard that changes over time through RFC’s. With that said, people and companies are free to write whatever software they want using that standard whether it is open or closed source, but it doesn’t change the standard itself.

My suggestion: Make metadata-minimized email the new standard.

Currently email has headers and a body. Even if the body is encrypted, the headers are not. These headers contain a lot of data that can be harvested even if you don’t know the contents of the message itself. This makes email inherently less private than other forms of electronic communication and is its greatest downfall.

metadata-minimized (m&m) email has a single piece of unencrypted metadata: The recipient’s email address. That’s it. The recipient has two pieces of information: The user and their domain. Nothing else is needed. For example: The user is “jsmith” and their domain is “”. If an email comes into’s servers, then the server will route the message to jsmith. There is no need to include a sender, time, server type, ip address, sender location, etc. that you would find in normal unencrypted headers. Only the recipient is needed.

What about spam?

That takes us to part 2 of the standard. All parts of the email outside of the recipient is always encrypted with the user’s public key. The user has the choice of whether or not to advertise their public key. If you don’t have it, you can’t email them because the message be automatically deleted. For business users this will reduce the amount of malware via email received dramatically. Also if the spammer doesn’t have your public key, they can’t spam you. If they do have it, then normal heuristic spam checking would need to be applied.

What about “other” metadata and backwards compatibility?

For example, what if the receiving server itself tags on things like “date received” and “IP address received from”, etc. even though that is not a part of the standard? There’s not a lot you can do about that but it is still far less data than would be available otherwise.

m&m email may not be backwards compatible with traditional email server because it would not know how to handle a message without all of the usual headers. On the other hand, a server built for m&m email could theoretically ignore the extra headers but would report to the user that the email is insecure.

One last thing…

What about services like Signal? There’s nothing wrong with Signal per se, but it is not an open standard nor do you know what kind of metadata they use or collect. Also, it is a short form messaging system. Email can be megabytes in size with text and attachments. Signal is meant for instant messages on mobile devices. There is a huge difference between use cases.

Let me know what you think. What would you add, change, or remove from this idea?