電子メール (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 ベースのフォーラムやまだ急成長中のチャットプロトコルに基づく協力は、より複雑なアーキテクチャに直面し、問題の特定が難しくなる可能性があります。時には、複雑さが安全リスクをもたらし、プロジェクトの基盤に直接脅威を与えることもあります。
次に、電子メールはプロジェクトに参加する個人を慰めます。ほとんどのオープンソースプロジェクトはボランティアによって推進されています。ボランティアは、そのプロジェクトのために 24 時間体制でサービスを提供することはできず、自分の生活にも配慮しなければなりません。ネットフォーラムは頻繁にリフレッシュする必要があり、インスタントメッセージの「既読」機能や短い対話形式の返信期待は、「返信しなければならない」というプレッシャーを感じさせます。電子メールだけが、ちょうど良い強度のリマインダーを提供します。それは今、メールが一通届いていることを知らせますが、同時にじっくり考えたり無視したりする機会も与えます。筆者個人の意見として、他者にインスタントメッセージを送信し、結果が音沙汰なしだと、相手があまり礼儀正しくないと感じることがあります。しかし、電子メールの場合、状況は全く逆になる可能性があります。相手が返信しない場合、自分の言葉遣いが適切でなかったのではないかと考えることができます。これは、比較的正式な形式として、電子メールが先天的により多くの尊重と選択の余地を持っているからかもしれません。ボランティアは間違いなく尊重されるべきです。ボランティアは興味に基づいて活動に参加するため、自分の参加度を把握する権利も必要です。もしそれが商業会社であったり、オープンソースプロジェクトに貢献するために雇われた個人や団体であれば、顧客に迅速に返信することは職業上の要求ですが、より多くのボランティアにとって、電子メールは互いの時間を尊重する手段です。
時間の尊重は、電子メールの緩やかな雰囲気だけでなく、商業実体にも同様に役立つ機能特性にも表れます。電子メールは天然の非同期属性を持ち、複数のタスクを同時に処理できます。従来のチャットルームでは、さまざまなトピックが対話ボックスに流れ込み、もし中断があればさらに混乱を招きます。確かに、現代のチャットクライアントには「スレッド」などの方法があり、この問題を解決していますが、これらの方法も電子メールからインスパイアを受けているかもしれません。電子メールでは、異なるトピックが同時に並べられ、それぞれの優先度を設定できます。件名欄は問題の簡潔な説明であり、参加者が最も価値のある問題を一目で見ることができます。四方八方からの意見も分類され、整理されます。電子メールの本文は明らかにインスタントメッセージよりも長く、電子メールは思考を促進するツールとなります。著者は、自分が問題を正確に説明する必要があることを認識し、思考を整理することができ、このプロセス自体が問題解決や頭を整理するのに役立ちます。対話形式のコミュニケーションと比較して、こうした交流は実際にはより効率的で、互いの時間をより尊重しています。さらに、長い時間の発展を経て、ほとんどの電子メールクライアントは OpenPGP のような暗号化技術と適切に連携し、通信の安全を保障しています。
これらの他にも、電子メールはさまざまなオペレーティングシステムやデバイスと広く互換性があり、さまざまな作業条件に適応し、プライバシーの安全を保護するのに役立つ特性を持っています（一般的に、送受信者の IP アドレスは互いに漏洩しないため、クッキーなどの技術については言うまでもありません）。しかし、今日の電子メールシステムは、技術が持続的に発展しなければ、再び輝きを取り戻したこの傑作も忘れ去られる可能性があります。現在、電子メールの新たな展開がいくつか登場しています。たとえば、DKIM のようなメールセキュリティサービスや、JMAP のようなプロトコルの再構築、さらには lacre のような強化暗号化ソリューションです。
未来の電子メールが、依然としてインターネットの基石として存在できることを願っています。
この記事の図表はASCIIFlowを使用して作成しました。一部の内容はウィキペディアを参考にしています。