電子メール (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 年、レイモンド・トムリンソンは世界初の本当の意味での電子メールを送信しました。使用されたのは、すでに存在していた 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 が疑いなく一般的な解決策です。このような一般的なプロトコルがあるおかげで、今日の電子メールは大いにその非中央集権的な性質を保っています。
┌───────────────────┐
│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 アドレスは互いに漏洩しないため、クッキーなどの技術については言うまでもありません）。しかし、今日の電子メールシステムは、技術が持続的に発展しなければ、再び輝きを取り戻したこの傑作も忘れ去られる可能性があります。現在、電子メールの新たな展開がいくつか登場しています。例えば、DKIM のようなメールセキュリティサービスや、JMAP のようなプロトコルの再構築、さらには lacre のような強化暗号化ソリューションです。
未来の電子メールが、依然としてインターネットの基礎として存在できることを願っています。
本文中の図表は ASCIIFlow を使用して作成しました。部分的な内容はウィキペディアを参考にしています。