電子郵件 (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 製作。部分內容參考自維基百科。