Email2.0
For those who may not know, email is not owned by any one company. There are no copyrights or patents associated with email itself. It’s an open standard that evolves over time through RFCs. While individuals and companies are free to develop software—whether open or closed source—using this standard, the core of email remains unchanged.
My Suggestion: Make Metadata-Minimized Email the New Standard Currently, email consists of headers and a body. Even if the body is encrypted, the headers are not. These headers contain a significant amount of data that can be harvested, even if the message content remains unknown. This makes email inherently less private than other forms of electronic communication, and it’s one of its greatest vulnerabilities.
What is Metadata-Minimized (M&M) Email?#
M&M email would have just one piece of unencrypted metadata: the recipient’s email address. That’s it. The recipient’s information consists of two parts: the user and their domain. For example, in jsmith@example.com, “jsmith” is the user, and “example.com” is the domain. When an email reaches the example.com server, it simply routes the message to jsmith. There’s no need to include the sender’s information, timestamp, server type, IP address, or any other details typically found in unencrypted headers. Only the recipient’s address is necessary.
What About Spam?#
This brings us to the second part of the standard. All elements of the email, apart from the recipient’s address, would be encrypted using the recipient’s public key. Users could choose whether or not to advertise their public key. If you don’t have the recipient’s public key, you can’t send them an email—the message would be automatically deleted. For business users, this would drastically reduce the amount of malware received via email. Additionally, if a spammer doesn’t have your public key, they can’t spam you. If they do have it, standard heuristic spam checks would still apply.
Handling Other Metadata and Backwards Compatibility#
What if the receiving server adds metadata like “date received” or “IP address received from,” even though it’s not part of the M&M standard? Unfortunately, there’s little that can be done to prevent this. However, the amount of data exposed would still be significantly less than what is typically available.
M&M email may not be backwards compatible with traditional email servers, as they might not know how to handle a message without all the usual headers. Conversely, an M&M-compliant server could theoretically ignore extra headers but would inform the user that the email is insecure.
And What About Services Like Signal?#
There’s nothing inherently wrong with Signal, but it’s not an open standard, and users don’t know what kind of metadata is collected or used. Additionally, Signal is designed for short-form messaging on mobile devices. Email, on the other hand, can handle megabytes of data, including text and attachments. The use cases for email and Signal are fundamentally different.
Let me know what you think! What would you add, change, or remove from this idea?