HMTP：使用現有 Web 標準設計現代化電子郵件繼承者
HMTP：使用現有 Web 標準設計現代化電子郵件繼承者
HMTP 以現有 Web 標準的模組化堆疊取代 SMTP
HMTP (Hypertext Mail Transfer Protocol) 是一個設計實驗，旨在透過結合經過實戰檢驗的 Web 技術來取代老舊的 Simple Mail Transfer Protocol (SMTP)，從而重新構想電子郵件。HMTP 並非發明新協定，而是組合現有的標準——例如 HTTP、WebFinger 和 ActivityPub——以消除電子郵件傳遞、身份驗證和加密方面的系統性缺陷。
HMTP 技術堆疊
HMTP 利用由已大規模部署的標準化技術組成的「物料清單」：
| 問題 | 使用的技術 | 實作範例 |
|---|---|---|
| 傳輸與狀態碼 | HTTP | Web |
| 傳輸加密 | TLS + Let's Encrypt | 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 | 現代瀏覽器 |
| 初次聯繫同意 | 訊息請求 (Message Requests) | Signal, Instagram |
| 附件 | 內容定址 (Content Addressing) | Git, IPFS, Matrix |
核心架構改進
發現與個人用戶委派
HMTP 使用靜態發現文件取代基於 DNS 的 MX 紀錄。透過請求 GET https://example.com/.well-known/hmtp/user，發件人可以發現收件人的收件匣 URL 和公鑰。這實現了個人用戶委派，允許同一個網域下的不同信箱由不同的提供商託管，而無需修改 DNS 紀錄。
加密身份與金鑰輪換
HMTP 中的身份與特定金鑰解耦以確保連續性。它使用兩個主要的錨點：
- 加密連續性：一種「sigchain」，其中每個新金鑰都由前一個金鑰簽署，允許用戶在不丟失身份的情況下輪換金鑰。
- 網域控制回退：如果金鑰丟失，網域所有者可以在強制公告期後聲明新金鑰，以防止立即被劫持。
冪等傳遞與儲存並轉發 (Store-and-Forward)
HMTP 維持了 SMTP 中 MUA (User Agent) 與 MTA (Transfer Agent) 分離的特性。用戶端向自己的伺服器發送一個經過身份驗證的 POST 請求，然後由伺服器處理隊列、進行指數退避重試，並遵循 HTTP Retry-After 標頭。為了防止因確認失敗而導致的重複郵件，每條訊息都透過其內容的雜湊值 (hash) 來識別，從而在結構上實現了重試的冪等性。
端到端加密與驗證
訊息被視為簽署過的物件，而非鬆散的文本。這種架構提供了多項優點：
- 靜態狀態下的真實性：加密證明隨訊息一同傳遞，即使透過轉寄也無法偽造。
- 來源驗證：接收者透過從發件人的
.well-known文件中獲取公鑰來驗證發件人。 - 預設端到端加密：使用 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)。該原型展示了簽署傳遞、來源驗證、端到端加密、初次聯繫同意以及具有指數退避功能的重試隊列。