HMTP: 使用现有Web标准设计现代电子邮件继任者
HMTP: 使用现有Web标准设计现代电子邮件继任者
HMTP（超文本邮件传输协议）是一种提出的电子邮件继任者，它使用包括HTTP、WebFinger和ActivityPub在内的现有Web标准栈来替代SMTP，以解决长期存在的垃圾邮件、欺骗和加密问题。
HMTP 使用现有Web标准的模块化栈替换SMTP
HMTP（超文本邮件传输协议）是一个设计实验，通过将老化的简单邮件传输协议（SMTP）替换为经过验证的Web技术组合来重新构想电子邮件。与其发明新协议，HMTP组装现有标准——如HTTP、WebFinger和ActivityPub——以消除电子邮件传递、身份验证和加密中的系统性缺陷。
HMTP 技术栈
HMTP 利用由已经大规模部署的标准化技术组成的“材料清单”：
| 问题 | 使用的技术 | 示例实现 |
|---|---|---|
| 传输及状态码 | HTTP | Web |
| 传输加密 | TLS + Let's Encrypt | Web |
| 用户发现 | WebFinger (RFC 7033) | Mastodon / Fediverse |
| 消息投递 | HTTP POST | ActivityPub |
| 发件人验证 | Webmention / DKIM 模式 | IndieWeb |
| 签名 | Ed25519 | SSH, Signal |
| 内容加密 | HPKE (RFC 9180) | MLS, TLS ECH |
| 身份连续性 | Sigchains | ATProto (Bluesky) |
| 读取和同步 | JMAP (RFC 8620) | Fastmail |
| 推送通知 | SSE / WebPush | 现代浏览器 |
| 首次联系同意 | 消息请求 | Signal, Instagram |
| 附件 | 内容寻址 | Git, IPFS, Matrix |
核心架构改进
发现和按用户委派
HMTP 使用静态发现文档替换基于 DNS 的 MX 记录。通过请求 GET https://example.com/.well-known/hmtp/user，发送者可以发现收件人的收件箱 URL 和公钥。这使得按用户委派成为可能，允许同一域名下的不同邮箱由不同提供商托管，而无需修改 DNS 记录。
加密身份和密钥轮换
HMTP 中的身份与特定密钥解耦，以确保连续性。它使用两个主要锚点：
- 加密连续性：一个“sigchain”，其中每个新密钥由前一个密钥签名，使用户能够轮换密钥而不丢失身份。
- 域控制后备：如果密钥丢失，域所有者可以在强制公告期后声明一个新密钥，以防止立即劫持。
幂等投递和存储转发
HMTP 保持了 SMTP 中 MUA（用户代理）和 MTA（传输代理）的分离。客户端向自己的服务器发送经过身份验证的 POST 请求，服务器随后处理队列，采用指数回off进行重试，并遵守 HTTP Retry-After 头。为了防止因确认失败导致的重复邮件，每条消息通过其内容的哈希进行标识，使得重试天然具备幂等性。
端到端加密和验证
消息被视为签名对象，而不是普通文本。这种架构提供了以下几个好处：
- 静态真实性：加密证明随消息一起传输，即使经过转发也无法伪造。
- 来源验证：接收者通过从发送者的
.well-known文件获取公钥来验证发送者。 - 默认端到端加密：使用 HPKE，消息体为收件人加密，而信封（元数据）保持可见以用于路由。
- 内容寻址附件：附件以
{hash, url, size}引用的形式存储。接收者按需下载它们，消除了邮箱中 base64 编码的膨胀。
解决垃圾邮件问题
HMTP 实施了一种分层防御策略，以取代目前对 IP 声誉和黑名单的依赖：
- 身份成本：将身份锚定到域名上会为大规模身份创建创造财务门槛（Sybil 成本）。
- 首次联系同意：未知发送者被放置在一个“请求”框中。用户必须显式接受陌生人的请求，线程才能移动到主要收件箱。
- 经济抑制：服务器可以用 HTTP
402 Payment Required响应首次联系尝试，引入可配置的成本以抑制冷发送垃圾邮件。
社区见解和技术批评
虽然 HMTP 提出了 SMTP 的现代替代方案，但技术讨论凸显了在采用和实施方面的若干挑战：
- 网络效应和兼容性：批评者认为电子邮件的普及使得不向后兼容的替代方案不太可能成功。一些人认为，对 SMTP 的渐进式改进（如 MTA-STS）更为务实。
- 内存管理：一些开发者警告不要为整个电子邮件文档使用纯 JSON，因为许多 JSON 解析器会将整个文档加载到内存中。他们建议采用混合方法，使用 JSON 头部后跟 MIME 正文，以允许流式传输。
- 邮件列表兼容性：内容寻址（将消息哈希作为 ID）可能会破坏传统邮件列表，因为这些列表经常修改头部以进行订阅管理。
- "垃圾邮件解决方案" 历史：一些观察者指出，类似的“终极垃圾邮件解决方案”在 1990 年代被提出，但在实践中由于人类交流的复杂性和问题的规模而被证明不可行。
"恶魔在于角落情况。这些问题已经被不同的方以不同的方式解决了数十年……除非你身处其中，否则你注定会重复同样的错误。
实施状态
HMTP 的工作原型已经用 Python 实现（github.com/tanrax/hmtp）。该原型演示了签名投递、来源验证、端到端加密、首次联系同意以及带有指数回off的重试队列。