現代のメールは借り物の部品で構築できる

HTTP上にメールの successor を設計し、SMTPが40年間引きずってきたデザイン上の欠陥を修正しましょう。一つずつです。目標は、現在のメールシステムを置き換えることではありません、神にかけて！しかし、学習し、楽しみ、送信、受信、ゲートウェイ、鍵など、あらゆる要素を置き換えるための現在の技術を発見することです。このシステムはGmailや従来のメールプロバイダーと通信することはありません。それは自分自身とだけ通信します。私たちが保持するのはアドレスの形式、user@domainだけです。それ以外はすべて再発明されます。HTTP上のメールシステムなので、プロトコルに良い名前はHMTP: Hypertext Mail Transfer Protocol（SMTPのSはSimpleのSですが、HTTPのHのために席を譲ります）でしょう。今度は技術スタックを準備する時です: HTTP、TLS、WebFinger、ActivityPub、Webmention、Ed25519、HPKE、sigchainsなど。 材料リスト このデザインは単一の技術を発明していません。すべてはすでに存在します。 | 問題 | 既存技術 | 今日誰が使っているか | |---|---|---| | トランスポートとステータスコード | HTTP | ウェブ全体 | | トランスポート暗号化 | TLS + Let's Encrypt | ウェブ全体 | | ユーザー発見 | WebFinger (RFC 7033) | MastodonとFediverse | | メッセージ配信 | POST to an inbox | ActivityPub | | 送信者検証（送信元） | The Webmention and DKIM pattern | IndieWeb、メール全体 | | 署名 | Ed25519 | SSH、Signal | | コンテンツ暗号化 | HPKE (RFC 9180) | MLS、TLS ECH | | 鍵ローテーションを生き残るID | Sigchains | ATProto (Bluesky)、Keybase | | 読み込みと同期 | JMAP (RFC 8620) | Fastmail | | プッシュ通知 | SSE / WebPush | すべてのブラウザ | | 初回連絡同意 | Message requests | Signal、Instagram | | ハッシュによる添付ファイル参照 | Content addressing | Git、IPFS、Matrix | 私たちが使用するすべての部品は、何百万人もの人々によって標準化され、展開され、大規模で実証されています。唯一新しいのは組み立てです。 HTTPを選択するのは単なる実用主義ではありません。新しいプロトコルがいずれ構築しなければならない多くのことを、最初から解決します: TLS、仮想ホスティング、SNI: 無料で。ステータスコード: メールプロトコルが必要とするカタログはすでにHTTPに存在します。202 Accepted (配信キュー入り)、429 Too Many Requests + Retry-After (レート制御)、404/410 (メールボックス不明/削除済み)、3xx (メールボックス移動済み)、413 (サイズ超過)。有料スパム対策でさえ、1997年からコードが予約されています: 402 Payment Required。 既存のインフラストラクチャ: プロキシ、ロードバランサー、Nginx、あらゆる言語のライブラリ。プロトコルは新しいサーバーではなくなり、WebmentionやMicropubのようなHTTP上の規約になります。 次のレベルに進みましょう: HTTP上で、ユーザーを発見し、IDを検証し、メッセージを配信し、署名し、暗号化するにはどうすればよいでしょうか？ 1. 発見と委任（より良いMX） 委任は静的ドキュメントで解決されます: GET https://example.com/.well-known/hmtp/ana { "inbox": "https://mail.migadu.example/hmtp/inbox/ana", "keys": { ... }, "devices": [ ... ] } 受信トレイは別のホストに存在できます: それはMXレコードですが、DNSに触れることはありません。GitHub Pages上の静的ブログは、JSONファイルを配信することで、プロバイダーにメールを委任できます。そして、MXが決してできなかったことを可能にします: ユーザーごとの委任（ドメインの各メールボックスが異なるプロバイダーに）。ルートを発明する必要さえありません。WebFinger (RFC 7033) はまさにこれを実行し、Mastodonはすでにそれがスケーリングすることを証明しています。 2. 鍵ローテーションを生き残るID IDは鍵であってはなりません（失われたり、期限切れになったりします）。それは鍵を戻すものでなければなりません。2つのアンカーを持つ提案: 暗号学的連続性: 発見ドキュメントは現在の鍵とローテーションのチェーンを公開します。各新しい鍵は前の鍵によって署名されます。鍵Nであなたを知っていた人は、誰にも信頼せずに鍵N+1を検証できます。それはsigchainであり、ATProtoがDIDsで行っていること、またはKeybaseが行っていたことです。フォールバックとしてのドメイン制御: 署名付きローテーションなしで鍵を失った場合（ラップトップが盗まれた）、ドメインはチェーンなしで新しい鍵を宣言し、強制的な発表期間（例えば30日）があります。その間、あなたを知っていたサーバーは「ドメインによってIDが再アンカーされました、署名によるものではありません」という警告を表示します。しかし、ドメインアンカーIDには独自の致命的な欠点があります。ドメインは所有されるのではなく、レンタルされます。支払いを停止すると、期限切れになり、誰かが登録します。新しい所有者はあなたの.well-knownに鍵を公開し、その瞬間からあなたのメールを受信し、あなたとして署名します。正当な相続人と不法占拠者を区別できる人はいません。これはATProtoがDIDsでIDをドメインから分離しようとしている問題であり、別のインフラストラクチャの代償を払っています。私たちはそれが既知の解決策を持つ現実の問題であることを知っています。では、先に進みましょう。 3. キューによる配信（ストアアンドフォワード） 配信は受信者の受信トレイへのPOSTです: POST /hmtp/inbox/ana HTTP/1.1 Host: mail.migadu.example Content-Type: application/hmtp+json 鍵はリクエストではなく、それを行う主体です。あなたのクライアントは受信者に直接配信するのではなく、あなた自身のサーバー（あなたのアウトボックスへの認証済みPOST）に配信し、あなたのサーバーがキューイングし、指数関数的バックオフでリトライし、Retry-Afterを尊重します。これはSMTPのMUA/MSA/MTA分離が正しかったことを認めることです。メールの静かな天才の一つは、宛先サーバーがダウンしていても、あなたのサーバーは何日もリトライし、あなたはそれを忘れることです。しかし、SMTPにはなかった改善を加えましょう。各メッセージにはコンテンツのハッシュであるIDが含まれているため、リトライは冪等です。受信サーバーはIDによって重複排除し、古典的な「ACKが失敗したための重複メール」は構築によって消滅します。 宛先ノードが最初の試行でダウンした場合の配信の完全なサイクル: ```mermaid sequenceDiagram autonumber participant Ana as Ana's client participant SA as Ana's server participant SB as Bob's server Ana->>SA: POST /outbox (signed message) SA-->>Ana: 202 queued SA->>SB: GET /.well-known/hmtp/bob SB-->>SA: Bob's inbox and keys SA->>SB: POST /hmtp/inbox/bob (envelope + sealed body) Note over SB: down: no response Note over SA: queue: retries with exponential backoff SA->>SB: POST /hmtp/inbox/bob (retry, same id) SB->>SA: GET /.well-known/ana SA-->>SB: Ana's signing key Note over SB: signature verified, deduplicated by id SB-->>SA: 201 delivered ``` 図にはプロトコル全体が含まれていることに注意してください: .well-knownへの2つのGETは発見と検証、POSTは配信、そしてキューは本来あるべき場所、送信者のサーバーにあります。 4. すでにある鍵での署名と暗号化 メッセージは、ゆるいテキストではなく、署名されたオブジェクトです: ```json { "id": "sha256:9f2c...", "from": "ana@example.com", "to": ["bruno@example.org"], "date": "2026-07-26T10:00:00Z", "in_reply_to": "sha256:11ab...", "subject": "Re: that idea", "body": { "type": "text/markdown", "content": "<encrypted>" }, "signature": "..." } ``` これは多くの利点をもたらします: 静止状態での認証: 保存されたメールは暗号学的証明を持ちます。転送は元の署名を保持します。転送の連鎖を経ても、送信者の偽造は不可能になります。DKIMなしでの送信者検証: 受信サーバーは送信元ドメインの.well-knownを取得し、鍵が署名していることを確認します。これはWebmention検証と同じ操作です。証明は送信元で取得されます。E2E: 発見ドキュメントは暗号化鍵（X25519）を公開します。本文はHPKEで封印されます。エンベロープ（from, to, id, date）はルーティングとフィルタリングのために可視のままですが、コンテンツは受信者のみが閲覧できます。スレッド: content hashによるin_reply_toとreferences。ヒューリスティクスなしで再構築された会話。添付ファイル: メッセージの外。添付ファイルは送信者のサーバーを指す{hash, url, size}です。受信者はオンデマンドでダウンロードし、そのサーバーはそれをミラーリングできます。メールボックスのbase64肥大化はもうありません。 5. レイヤードスパム対策 あらゆるシステムと同様に、これは複数の防御層を必要とする複雑な問題です。HMTPでは3つから始めることができます: IDコスト: ana@example.comとして署名するには、example.comで鍵ドキュメントを配信する必要があります。IDはドメインに紐付けられており、ドメインには費用がかかります。これは自己署名IDにはないSybilコストです。しかし、ドメインは無限の