Email (email, RFC Style Guide) is undoubtedly one of the cornerstones of the internet. Before email, the internet was merely a network for researchers to synchronize technical information; email largely brought a breath of life to the internet. Today, as various Instant Messaging (IM) technologies mature, the casual conversations that once filled our lives through email are gradually fading, yet we can still glean some insights.
The author is limited in knowledge and energy, and if there are any oversights, please feel free to criticize and correct.
Communication on the Same System#
Today, email is often seen as one of the earliest decentralized messaging networks, allowing users to communicate across servers. However, its predecessor was confined to the host, used solely for communication between different users on time-sharing systems. MIT's CTSS system is a typical example.
┌───────┐ ┌───────┐
│ User ├─────────┐ ┌────────┤ User │
└───────┘ ┌──────┴─┴─────┐ └───────┘
│ Shared │
│ File(s) │
├──────────────┤
│ Time-sharing │
│ Mainframe │
┌───────┐ └──────┬─┬─────┘ ┌───────┐
│ User ├─────────┘ └────────┤ User │
└───────┘ └───────┘
The above diagram illustrates a popular implementation at the time, where information was transmitted by sharing a file among multiple users on the same mainframe. This method of communication later evolved into the precursor of email—a mail system on a single system. Even today, host-bound email still exists and is widely used in scenarios requiring message notifications, such as internal system alerts. In these cases, emails that are transmitted solely within the system can be easily deployed (as the technology is mature, and many systems even come with corresponding solutions), without incurring additional costs.
In fact, developers on both mainframes and minicomputers during the same period created various software for communication within the same system. Some of these required both sender and receiver to be online simultaneously, evolving into today's instant messaging, while others have a significant relationship with today's email. However, at that time, they were mostly incompatible with each other. These inventions predated the birth of the internet, and computer systems largely operated independently. Users on one device being able to communicate with each other was already satisfactory. By the 1970s, computers began to be commercialized, leading to the emergence of many commercial email formats for communication within offices.
Entering ARPANET#
The precursor to the internet is ARPANET, which marked the beginning of email being transmitted across systems. In 1971, Raymond Tomlinson sent the world's first true email, using a new version of an existing software called SNDMSG, which allowed information to be transmitted in file form across networks. Through ARPANET, this email was unprecedentedly sent from one host to another, ushering in the era of network communication. It also introduced the @ symbol for indicating the host to which a user belongs. This symbol is now widely used in various contexts to represent accounts on social platforms.
┌──────┐
│ User ├─────┐
└──────┘ │
│
┌────┴───┐
│ │
┌──────┐ │ Host ├─────────┐
│ User ├──────┤ │ │
└──────┘ └────────┘ ┌────┴──────┐
│ ARPANET │
┌────────┐ └────┬──────┘
│ │ │
│ Host ├─────────┘
│ │
┌──────┐ └─┬──┬───┘
│ User ├────────┘ │
└──────┘ │
│
│
┌──────┬─────┘
│ User │
└──────┘
At this time, email was sent using the NCP protocol, marking its first combination with a real protocol. NCP was soon replaced by TCP, and thus email systems gradually matured.
┌──────────┐ xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ┌──────────┐
│ Host │ x x │ Host │
│ │ x x │ │
│ │ x x │ │
│ │ x x │ │
│ │ x x │ │
│ │ x ┌───────────────────────┐ x │ │
│ │ x │ Network Applications │ Email... x │ │
│ │ x ┌────└───────────────────────┘────┐Higher-level x │ │
│ ┌───────┐ x │ Application Protocol │ x ├───────┐ │
│ │ NCP │ x ├─────────────────────────────────┤ x │ NCP │ │
│ │ ├──x─┤ Interface ┼─────────────x───┤ │ │
│ └───────┘ x │ Network Control Protocol │ x ├───────┘ │
│ │ x └─────────────────────────────────┘ x │ │
│ │ x ▲ x │ │
│ │ x │ x │ │
│ │ x │ x │ │
│ │ x │ x │ │
│ │ x Protocol x │ │
└──────────┘ x Layering x └──────────┘
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The Birth of Subsequent Protocols...#
Many familiar protocols have since emerged, such as SMTP, IMAP, and POP, as well as some proprietary protocols like Exchange. Whenever cross-server communication is involved, SMTP is undoubtedly the universal solution. It is precisely because of universal protocols like SMTP that today's email largely retains its decentralized nature.
┌───────────────────┐
│User: │
│[email protected]│
└────────┬──────────┘
│
Webmail
│
┌────────────┐ ┌─────┴──────┐
│ │ │ │
┌────────────────────────────────────┐ │ │ │ │
│ From: [email protected] │ │ │ │ │
│ To: [email protected] │ │ Port 25├─────────────────────►│ │
│ Subject: Body: ... │ │ │ SMTP │ │
└────────────────────────────────────┘ │ │ ─────────────────── │ │
│ │ TLS(Encryption) │ │
┌───────────────────┐ │ │ ─────────────────── │ │
│User: │ │ │ TCP │ │
│[email protected]│ │ │◄─────────────────────┤Port 25 │
└──┬───▲────────────┘ │ │ │ │
│ └───────IMAP/POP────────┤ │ │ │
│ │example.com │ │example.net │
└───────SMTP───────────────►│ Host │ │ Host │
└────────────┘ └────────────┘
Webmail allows users to view emails in a browser, using web protocols (such as HTTP(s)) to retrieve emails from servers. Nowadays, the vast majority of email service providers offer webmail services and encourage users to use them. Some providers that claim to prioritize privacy even avoid offering traditional protocol services (IMAP/POP, client SMTP), opting only for more modern webmail to mitigate risks associated with outdated protocols. However, critics argue that this practice may lead users to become overly reliant on a single platform, losing the portability of standard email protocols and weakening the decentralized nature of email systems. Others believe that webmail interfaces can be made more attractive or provide email service providers with more opportunities to collect user information.
Today, we have many well-known decentralized instant messaging standards. The most famous ones are probably XMPP and Matrix. Many open-source projects have replaced the similarly dated IRC with them. They actually adopt a similar approach to email, where users belong to different hosts, and both host-user and host-host communications use a universally applicable set of standards. When IMAP, POP, and SMTP were born, there was no data format like JSON that possessed both machine-readable and human-readable characteristics, but now, driven by JSON, cross-system communication has become effortless.
Open Source, Encryption, and Asynchronous Revival of Email#
We say that many open-source projects have replaced email writing with online forums and decentralized instant messaging standards, yet large open-source projects like Chromium and the Linux Kernel still use mailing lists. Many might think that this is a stubborn belief that mailing lists (email) are still not outdated and mistakenly assume that these projects refuse to switch collaboration methods simply due to the cost of migration. In fact, even today, mailing lists still outperform online forums and chat rooms (even decentralized chat protocols). Please allow me to share my perspective on why I believe the open-source community, encryption, and the concept of asynchronicity have revived email.
First, mailing lists are very easy to deploy. For users who are proficient, setting up a mailing list service can be done with just a few commands, while deploying an online forum may require extensive configuration. As traffic increases, it can also incur high costs. For many open-source projects, funding is tight, so they naturally choose to stick with the mailing list collaboration model, especially since everyone has already adapted to it. Simplicity also brings stability, which is why some large projects continue to use mailing lists; it is a familiar way for their developers and users to communicate and report issues, and the principle is quite simple—it's just mass email. Therefore, even when collaboration workflows encounter issues due to high traffic, it is easy to quickly identify the individual at fault, whereas web-based forums and collaboration based on rapidly evolving chat protocols may face more complex architectures and harder-to-locate problems. Sometimes, complexity can even introduce security risks that directly threaten the entire project's infrastructure.
Second, email provides comfort to individuals participating in projects. Most open-source projects are driven by volunteers; volunteers cannot serve the project around the clock, as they have their own lives to consider. Online forums require constant refreshing, and the "read" feature of instant messaging, along with the expectation for short, conversational replies, can create pressure to "respond immediately." Only email offers a perfectly balanced reminder intensity: it alerts you that there is an email but also allows for careful consideration or the option to ignore it. Personally, I feel that if an instant message is sent to someone and there is no response, it may seem impolite; however, if it's an email, the situation could be entirely different: if the other party does not reply, they might be considering whether their wording was inappropriate. This may be because, as a more formal medium, email inherently carries more respect and room for choice. Volunteers undoubtedly need respect; they participate in activities out of interest and should have the right to control their level of involvement. If it were a commercial company or an individual/group employed to contribute to an open-source project, timely responses to their clients would be a professional requirement, but for most volunteers, email is a way to respect each other's time.
Respect for time is not only reflected in the relaxed atmosphere of email but also in some functional characteristics that may be equally useful to commercial entities. Email has a natural asynchronous property, allowing multiple tasks to be concurrent. In a traditional chat room, various topics can flood into the chat box, and if there are interruptions, it can become chaotic. Certainly, modern chat clients have methods like "threads" to address this issue, but these methods may also have been inspired by email. Different topics in email can be laid out simultaneously, and their respective priorities can be set. The subject line provides a brief description of the issue, allowing participants to quickly identify the most valuable questions, and opinions from various sources can be categorized and summarized. The body of an email is clearly longer than an instant message, making email a tool that promotes thought. The writer realizes they need to accurately describe the issue, which helps organize their thoughts; this process itself aids in problem-solving and clarifying ideas. Compared to conversational communication, this type of exchange is actually more efficient and respects each other's time. Additionally, after years of development, most email clients can appropriately integrate with encryption technologies like OpenPGP to ensure secure communication.
In addition to all of the above, email is also widely compatible with various operating systems and devices, adaptable to different working conditions, and can help protect privacy (generally, the IP addresses of both sending and receiving parties are not disclosed to each other, let alone technologies like cookies). However, if today's email systems do not continue to develop their technology, this hard-won masterpiece may also be forgotten. New expansions of email have already emerged, such as email security services like DKIM, protocol redefinitions like JMAP, and enhanced encryption solutions like lacre.
Perhaps the future of email can still exist as a cornerstone of the internet.
The diagrams in this article were created using ASCIIFlow. Some content is referenced from Wikipedia.