电子邮件 (email, RFC Style Guide) 无疑是互联网的基石之一。在电子邮件之前，互联网还是一个供科研人员同步技术信息的网络；电子邮件，则很大程度上给互联网带来了生活的气息。而如今，各类即时消息 (Instant Messaging, IM) 技术逐步成熟，漫谈逐渐淡出你我生活的电子邮件，我们还能收获些许启迪。
笔者才疏学浅，精力有限，如果有所疏漏，还请您批评指正。
同系统上的通信#
今天，电子邮件常常被看作最早的去中心化消息网络，用户可以跨服务器进行通讯。然而电子邮件的前身是不离开主机的，只用作分时系统 (time-sharing) 上不同用户之间进行相互沟通。MIT 的 CTSS 系统就是典型案例。
┌───────┐ ┌───────┐
│ User ├─────────┐ ┌────────┤ User │
└───────┘ ┌──────┴─┴─────┐ └───────┘
│ Shared │
│ File(s) │
├──────────────┤
│ Time-sharing │
│ Mainframe │
┌───────┐ └──────┬─┬─────┘ ┌───────┐
│ User ├─────────┘ └────────┤ User │
└───────┘ └───────┘
上面这张图介绍了当时流行的一种实现，即通过同一大型机 (mainframe) 上多个用户之间分享一个文件来传递信息。这种沟通方式，稍后就演进成了电子邮件的前身 —— 一个系统上的邮件系统。而时至今日，不离开主机的电子邮件也仍然存在，并广泛运用于如系统内部告警等需要实现消息通知的场景。在这些场景中，只在系统内部传递的电子邮件可以简单地部署（因为技术已经很成熟，很多系统甚至自带了对应的解决方案），同时不产生额外开销。
其实，同时期无论是大型机还是小型机上的开发者，都研发了诸多实现同系统通信的软件，一部分要求发送方和接收方都要同时在线的演变成了今天的即时消息，而另一部分何今天的电子邮件则关系很大。但彼时，它们彼此大多互不兼容。因为这些发明都早在了互联网诞生之前，彼时计算机系统还彼此大多独立运行，一台设备上的用户能相互通信，也已经足够让人满意。而进入 1970 年代，计算机开始商业化应用，同时期产生了很多商业电子邮件格式，以实现办公室内的通信。
步入 ARPANET#
互联网的前身是 ARPANET, 而 ARPANET 则是电子邮件开始跨系统传递的开始。1971 年 Raymond Tomlison 发送了世界上第一封真正意义的电子邮件，使用的是已经存在的一个名为 SNDMSG 的软件的新版本，允许在网络之间以文件形式传递信息。通过 ARPANET, 这封电子邮件，史无前例地从一个主机发往另外一台主机，开启了网络通信时代。同时也第一次引入了 @ 这个符号，用于表示用户所属于的主机。这个符号如今也被广泛用在各种场合，表示社交平台上的账号。
┌──────┐
│ User ├─────┐
└──────┘ │
│
┌────┴───┐
│ │
┌──────┐ │ Host ├─────────┐
│ User ├──────┤ │ │
└──────┘ └────────┘ ┌────┴──────┐
│ ARPANET │
┌────────┐ └────┬──────┘
│ │ │
│ Host ├─────────┘
│ │
┌──────┐ └─┬──┬───┘
│ User ├────────┘ │
└──────┘ │
│
│
┌──────┬─────┘
│ User │
└──────┘
此时的电子邮件，因其通过 NCP 协议发送，也第一次和一个真正的协议相结合。NCP 很快被 TCP 取代，而电子邮件系统因此也逐步走向成熟。
┌──────────┐ 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
之后诞生的...#
之后诞生了很多大家已经熟悉的协议，譬如 SMTP, IMAP 和 POP, 以及一些私有协议比如 Exchange. 但凡是涉及跨服务器通信的领域，SMTP 是毫无悬念的通用解决方案。也正是因为有 SMTP 这样的通用协议，才让今天的电子邮件很大程度上保持了其去中心化的本色。
┌───────────────────┐
│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, 即可以在浏览器内查看电子邮件，使用 Web 协议（指 HTTP (s) 协议等）来从服务器检索电子邮件。现在，绝大多数电子邮件服务商都提供 Webmail 服务，且鼓励用户使用，而一些宣称注重隐私保护的提供者甚至会避免提供传统协议的服务 (IMAP/POP, 客户端 SMTP), 而只提供更为现代的 Webmail 来避免因为协议过旧造成风险。但同时也有批评声音指出这种做法会导致用户更加依赖单一平台，丧失标准电子邮件协议的便携性，削弱了电子邮件系统的去中心化特质。更有人认为 Webmail 界面可以制作得更漂亮，或者可以给电子邮件服务商更多机会来收集用户信息。
今天我们有很多耳熟能详的去中心化即时通讯标准。最著名的当属 XMPP 和 Matrix 了吧？许多开源项目已经用它们取代了和电子邮件同样有年代感的 IRC. 而它们其实也采用了和电子邮件类似的思路，即用户属于不同主机，而主机 - 用户，主机 - 主机之间都使用了一套处处通行的规范。IMAP, POP, SMTP 诞生的年代，还没有出现像 JSON 这样同时具备机器可读、人类可读特性的数据格式，而现在在 JSON 的驱动下，跨系统通信也变得易如反掌了。
开源、加密和异步复活了电子邮件#
我们说有很多开源项目用网络论坛、去中心化即时通讯标准取代了邮件写作，而又说像 chromium, Linux Kernel 这样的巨型开源项目都仍然使用邮件列表，很多人可能觉得以此为据来认定邮件列表（电子邮件）仍然没有过时属于太过顽固，并且误以为这些项目拒绝切换协作方式只是因为迁移需要成本。其实，直到今天，邮件列表仍然优于网络论坛、聊天室（哪怕是去中心化聊天协议）。烦请听听笔者的一家之言，以及为什么说开源社区、加密和异步的概念复活了电子邮件。
首先，邮件列表部署起来非常简单。对于操作熟练的用户来说，部署一个邮件列表服务只需要几行命令就能搞定，但部署一个网络论坛则可能需要诸多配置设置，流量增多后，还会产生高昂的资费。对于不少开源项目来说，资金很紧张，自然而然地就选择停在邮件列表的协作模式上，更何况大家已经普遍适应了呢？简单也带来了稳定，因而一些巨型项目会选择继续使用邮件列表，这是它们的开发者和用户熟悉的交流与报告问题的方式，并且原理上十分简单，无非就是邮件群发，所以流量巨大时，即使协作的工作流出了问题，也能很快定位到出错的个体，而基于 Web 的论坛和基于尚处于高速发展期的聊天协议的协作则可能面临更复杂的架构，更难定位的问题。有时，复杂性甚至会带来安全风险，直接威胁到整个项目的基础设施。
其次，电子邮件宽慰了参与项目的个人。大部分开源项目由志愿者驱动；志愿者，不可能全天候为了该项目服务，其还有自己的生活要顾及。网络论坛需要时常刷新，即时通讯的 “已读” 功能和短的、对话式的回复期待则会让人感到 “必须回复” 的压力。只有电子邮件提供了一个恰到好处的提醒强度：它会提醒现在有一封邮件，但同时也给了仔细思考或无视的机会。笔者个人觉得，一条即时消息发给他人，结果杳无音讯，感觉对方或许不大礼貌；但如果是电子邮件，情况则可能完全相反：如果对方不回复，却是先考虑自己是不是言辞用得不合宜。这可能是因为作为比较正式的形式，电子邮件先天带有更多的尊重，以及选择的余地。志愿者无疑需要尊重；志愿者为兴趣参与活动，自然也要有把握自己参与程度的权利。如果是一家商业公司，或者受雇为开源项目贡献的个人 / 团体，那么及时回复他们的客户属于一种职业要求，但对于更多的志愿者来说，电子邮件是对彼此时间的尊重。
对于时间的尊重绝不仅仅体现在电子邮件的宽松氛围，还会体现在一些对商业实体或许也同样有用的功能特质上。电子邮件具有天然的异步属性，即多个事务可以并发。如果是传统的聊天室，诸话题将似流水般涌进对话框，其中要是有穿插打岔则更是一片混乱。固然，现代聊天室客户端有 “讨论串” 等办法解决这种问题，但这些办法说不定也是受电子邮件的启发的。电子邮件中不同话题同时排开，并且可以设置各自优先级重要度。主题栏是对问题的简要描述，可以一眼让参与者看到最具备价值的问题，来自四面八方的意见也可以分类汇总整理。电子邮件的正文很明显会长于即时消息，使电子邮件成为促进思考的工具。撰写者意识到自己需要精确的描述问题所在，就会整理思绪，这一过程本身就有助于解决问题、理清头脑，相较于对话式的沟通，这样的交流其实更有效率，也更尊重彼此的时间。此外，经过长时间的发展，大部分电子邮件客户端都可以和 OpenPGP 这样的加密技术恰当配合，保障通信的安全。
除了以上种种，电子邮件还广泛兼容各类操作系统和设备，广泛适应各种工作条件，可以帮助保护隐私安全（一般情况下收发双方的 IP 地址都不会泄露给彼此，更不必说 cookies 等技术）等特质。但是今天的电子邮件系统，如果自身的技术不持续发展，这样一个好不容易重新熠熠生辉的杰作也有可能被遗忘。现在，电子邮件的新拓展已经出现不少，譬如 DKIM 这样的邮件安全服务，或者 JMAP 这样的协议重塑，还有 lacre 这样的强化加密方案。
或许未来的电子邮件，能依旧作为互联网的基石存在。
本文中的图表使用 ASCIIFlow 制作。部分内容参考自维基百科。