Email, as a communication medium, predates the concept of the web, and unfortunately, it remains firmly rooted in the era of its invention.
The web, when it was conceived, wasn't initially envisioned as the expansive network we know today. At its core, it was designed as a system for sharing documents. It's crucial to emphasize that the web operates as a democratic, open, and pull-based system. No one compels us to view specific web pages; we have the freedom to choose. Imagine an opposite scenario where our web browsers forced us to view pages dictated by website owners—this idea can be unsettling, especially in the context of the pervasive online advertising era.
Conversely, this is precisely how email functions. Any individual or entity can push content to your email client if they have knowledge of your email address. Unlike the web, which operates on a pull-based model, email traces its origins back to the FTP (File Transfer Protocol), designed for copying files between locations. While FTP supports both pulling and pushing, email was initially based on the push concept. The rationale behind this was that in its original, rudimentary proof of concept, the ultimate recipient couldn't be aware of the existence of a message on the remote, sending side. By the time email gained traction, reversing this push-centric architecture became impractical. Instead, email continued to build on the push model, akin to the familiar postal system. In the early days, particularly in academic and research environments, there were few bad actors, making this system viable.
This concept, conceived four decades ago, still shapes email today. FTP has been replaced by SMTP (Simple Mail Transfer Protocol), but the fundamental ideas persist. However, with the rise of spam, phishing, and various abuses as email became a global medium, corporations implemented numerous improvements. This resulted in a multitude of email RFCs (Request for Comments) that have rendered email so intricate that it would be a nearly insurmountable task for anyone to create their own email system from scratch today. In contrast, consider the web, where any programming language can be used to launch a web server with minimal code.
Email stands as one of the most crucial, if not the most critical, open global communication mediums today. However, it also remains one of the most insecure, antiquated, and frequently abused forms of communication. It serves as the primary vector for cyberattacks, yet no organization can function effectively without it.
Unlike many other communication protocols, email operates on a public, open, and inclusive framework that allows anyone to participate. However, its push-based nature necessitates gatekeepers to regulate "deliverability" in the face of the overwhelming volume of spam.
While gatekeepers are essential to maintaining email's functionality and security, the issue arises when global dominance is concentrated in the hands of just a few providers, like Google and Microsoft. This concentration of power essentially allows these gatekeepers to shape the entire email network. To draw a parallel with the web, it's akin to a web browser arbitrarily refusing to load web pages we request. Thankfully, with the web, we can switch browsers to bypass such gatekeepers. In the case of email, the final recipient isn't even aware of the gatekeepers' blocking.
Individuals who lack a deep understanding of email often propose commercial products such as chat applications or proprietary closed email systems as alternatives. However, this approach effectively means substituting one gatekeeper with another, rather than addressing the core issues related to centralization and control.
Creating a viable alternative to email is an enormous undertaking that requires substantial resources and infrastructure. Large corporations with a vested interest in the existing email landscape are unlikely to invest in such endeavors, as they benefit from the current situation both in terms of control and revenue. In fact, their tendency may be to complicate email further, using complexity as an excuse to exclude smaller providers from the network. When one examines the authors of RFCs (Request for Comments) from the past decade, this trend becomes readily apparent.
This situation underscores the need for continued discussion and exploration of ways to improve the email ecosystem, promote decentralization, and ensure greater privacy and security for users.
The web, even though commonly thought as a protocol for accessing websites is much more than that. It is a universal, stateless protocol which as mentioned previously, is meant for document or resource sharing, as per its own terminology. To understand why this is important, it is necessary to drop old terminology of sending and receiving which we are dragging from the postal as well email cruft.
When we send a physical parcel through the postal system, we understand that it cannot be recalled; it physically travels from sender to recipient. The early designs of email mirrored this nature. Once a message is sent, it's essentially gone, or to be more precise, the message is duplicated (often multiple times) and eventually resides on the recipient's system. At that point, the sender lost all control over their message, and there is no room for errors.
In contrast, the web operates with more flexibility. If we shift our perspective from "sending" messages to "sharing" online resources, as is common today, content creators not only have the ability to determine who can access and read their resources, but they can also revoke access if the content hasn't been accessed yet.
Email providers sometimes mimic such features with the "undo" function, but this is essentially a user interface trick, a momentary pause in sending the message. Once the message is sent, control over it is permanently relinquished.
The question arises: Why aren't such features native to the email protocol? Authors of messages should have control over their content, just as one controls the content of their own website or their uploads on platforms like YouTube. The answer to this issue is rather straightforward. To have control over received messages, there would be a requirement for robust sender authentication, a capability that email still lacks to this day.