HMTP: 既存のWeb標準を用いたモダンなメール後継者の設計
HMTP: 既存のWeb標準を用いたモダンなメール後継者の設計
HMTPはSMTPを既存のWeb標準のモジュール式スタックに置き換える
HMTP (Hypertext Mail Transfer Protocol) は、老朽化した Simple Mail Transfer Protocol (SMTP) を、実証済みのWeb技術の組み合わせに置き換えることでメールを再定義する設計実験です。新しいプロトコルを発明するのではなく、HMTPは HTTP、WebFinger、ActivityPub といった既存の標準を組み立てることで、メールの配信、本人確認、および暗号化におけるシステム的な欠陥を排除します。
HMTPの技術スタック
HMTPは、すでに大規模に展開されている標準化された技術からなる「部品表 (bill of materials)」を活用しています：
| 問題 | 使用される技術 | 実装例 |
|---|---|---|
| 転送とステータスコード | HTTP | The Web |
| 転送暗号化 | TLS + Let's Encrypt | The Web |
| ユーザーの発見 | WebFinger (RFC 7033) | Mastodon / Fediverse |
| メッセージ配信 | HTTP POST | ActivityPub |
| 送信者検証 | Webmention / DKIM pattern | IndieWeb |
| 署名 | Ed25519 | SSH, Signal |
| コンテンツ暗号化 | HPKE (RFC 9180) | MLS, TLS ECH |
| アイデンティティの継続性 | Sigchains | ATProto (Bluesky) |
| 閲覧と同期 | JMAP (RFC 8620) | Fastmail |
| プッシュ通知 | SSE / WebPush | Modern Browsers |
| 初回コンタクトの同意 | Message Requests | Signal, Instagram |
| 添付ファイル | Content Addressing | Git, IPFS, Matrix |
コアとなるアーキテクチャの改善
発見とユーザーごとの委任
HMTPは、DNSベースのMXレコードを静的な発見ドキュメントに置き換えます。送信者は GET https://example.com/.well-known/hmtp/user をリクエストすることで、受信者のインボックスURLと公開鍵を特定できます。これによりユーザーごとの委任が可能になり、同じドメイン上の異なるメールボックスを、DNSレコードを変更することなく異なるプロバイダーでホストできるようになります。
暗号学的アイデンティティと鍵のローテーション
HMTPにおけるアイデンティティは、継続性を確保するために特定の鍵から切り離されています。以下の2つの主要なアンカーを使用します：
- 暗号学的継続性: 新しい鍵が前の鍵によって署名される「sigchain」により、ユーザーはアイデンティティを失うことなく鍵をローテーションできます。
- ドメイン制御のフォールバック: 鍵を紛失した場合、ドメイン所有者は即時のハイジャックを防ぐために、義務付けられた告知期間の後に新しい鍵を宣言できます。
冪等な配信とストア・アンド・フォワード
HMTPは、MUA (User Agent) と MTA (Transfer Agent) のSMTPにおける分離を維持します。クライアントは自身のサーバーに認証されたPOSTを送信し、サーバーがキューの処理、指数バックオフを用いたリトライ、および HTTP Retry-After ヘッダーの遵守を行います。確認応答の失敗による重複メールを防ぐため、すべてのメッセージはコンテンツのハッシュによって識別され、構造的にリトライが冪等（idempotent）になるよう設計されています。
エンドツーエンド暗号化と検証
メッセージは、単なるテキストではなく署名付きオブジェクトとして扱われます。このアーキテクチャは以下の利点を提供します：
- 保存時の真正性: 暗号学的証明がメッセージと共に移動するため、転送されても偽造が不可能です。
- 送信元検証: 受信者は、送信者の
.well-knownドキュメントから公開鍵を取得することで送信者を検証します。 - デフォルトのE2E暗号化: HPKEを使用することで、メッセージ本文は受信者向けに暗号化され、エンベロープ（メタデータ）はルーティングのために可視なままとなります。
- コンテンツアドレス指定の添付ファイル: 添付ファイルは
{hash, url, size}参照として保存されます。受信者は必要に応じてそれらをダウンロードするため、メールボックス内でのbase64エンコーディングによる肥大化が解消されます。
スパム問題の解決
HMTPは、現在のIPレピュテーションやブロックリストへの依存に代わる、階層的な防御戦略を実装します：
- アイデンティティのコスト: アイデンティティをドメインに紐付けることで、大量のアイデンティティ作成に対する経済的障壁（sybil cost）を生み出します。
- 初回コンタクトの同意: 未知の送信者は「リクエスト」ボックスに配置されます。ユーザーは、スレッドがメインのインボックスに移動する前に、見知らぬ相手からのリクエストを明示的に承認する必要があります。
- 経済的ディスインセンティブ: サーバーは、初回コンタクトの試行に対して HTTP
402 Payment Requiredコードで応答することができ、コールドスパムに対して設定可能なコストを導入できます。
コミュニティの洞察と技術的批判
HMTPの提案はSMTPに代わるモダンな選択肢を提示していますが、技術的な議論では採用と実装に関するいくつかの課題が指摘されています：
- ネットワーク効果と互換性: 批判的な意見として、メールの普及度の高さから、後方互換性のない置き換えが成功する可能性は低いというものがあります。SMTPへの漸進的な改善（MTA-STSなど）の方が現実的であるという示唆もあります。
- メモリ管理: 一部の開発者は、メールドキュメント全体に純粋なJSONを使用することに対して警告を発しています。多くのJSONパーサーはドキュメント全体をRAMにロードするため、ストリーミングを可能にするためにJSONヘッダーの後にMIMEボディを続けるハイブリッドアプローチが提案されています。
- メーリングリストの互換性: コンテンツアドレス指定（IDのためにメッセージをハッシュ化すること）は、購読管理のためにヘッダーを頻繁に修正する従来のメーリングリストを壊す可能性があります。
- 「スパム解決策」の歴史: 一部の観測者は、スパムに対する同様の「究極の解決策」が1990年代にも提案されていたが、人間同士のコミュニケーションの複雑さと問題の規模のために、実際には機能しなかったことを指摘しています。
「悪魔はコーナーケース（例外的なケース）に潜んでいる。それらは数十年にわたり、異なる当事者によって異なる方法で解決されてきた……。あなたがその経験をしていない限り、同じ間違いを繰り返す運命にある。」
実装状況
HMTPの動作するプロトタイプがPythonで実装されています (github.com/tanrax/hmtp)。このプロトタイプは、署名付き配信、送信元検証、E2E暗号化、初回コンタクトの同意、および指数バックオフを備えたリトライキューを実証しています。