本文提出在HTTP基础上构建现代邮件系统HMTP，保留user@domain地址格式，利用WebFinger、ActivityPub等现有技术替代SMTP的每个组件，实现自封闭的邮件传输协议。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节，并删减了与主题无关的评论性内容。

标题：现代电子邮件可以用现成的技术模块来构建

本文探讨了如何在HTTP协议之上设计一个电子邮件的继任者，以解决SMTP协议40年来积累的设计缺陷。目标并非取代现有邮件系统，而是通过组合现有技术，重新设计邮件系统的每一个环节：发送、接收、网关、密钥等。这个新系统只与自身通信，不会与Gmail等传统邮件服务交互。唯一保留的是 user@domain 的地址格式，其余一切都被重新设计。

由于这是一个基于HTTP的邮件系统，作者提议将其命名为HMTP（超文本邮件传输协议）。

技术栈准备： HTTP、TLS、WebFinger、ActivityPub、Webmention、Ed25519、HPKE、Sigchains等。

技术选型清单

该设计没有发明任何新技术，所有组件都已存在并经过大规模验证：

| 问题 | 现有技术 | 当前使用者 | | :--- | :--- | :--- | | 传输与状态码 | HTTP | 整个网络 | | 传输加密 | TLS + Let's Encrypt | 整个网络 | | 用户发现 | WebFinger (RFC 7033) | Mastodon及联邦宇宙 | | 消息投递 | POST到收件箱 | ActivityPub | | 发送者验证 | Webmention和DKIM模式 | IndieWeb、所有电子邮件 | | 签名 | Ed25519 | SSH、Signal | | 内容加密 | HPKE (RFC 9180) | MLS、TLS ECH | | 可轮换密钥的身份 | Sigchains | ATProto (Bluesky)、Keybase | | 阅读与同步 | JMAP (RFC 8620) | Fastmail | | 推送通知 | SSE / WebPush | 所有浏览器 | | 首次联系同意 | 消息请求 | Signal、Instagram | | 引用式附件（含哈希） | 内容寻址 | Git、IPFS、Matrix |

选择HTTP不仅出于实用，它直接解决了新协议需要构建的多个问题：TLS、虚拟主机、状态码（如202接受、429限速、404/410邮箱不存在、413内容过大等），以及现成的代理、负载均衡器等基础设施。

1. 发现与委派（更好的MX记录）

委派通过一个静态文档解决。例如，访问 https://example.com/.well-known/hmtp/ana 会返回一个JSON文件，其中包含收件箱地址和密钥信息。收件箱可以位于另一台主机上，这相当于MX记录，但无需修改DNS。GitHub Pages上的静态博客可以通过提供JSON文件将邮件委派给服务商。它还实现了MX记录从未做到的按用户委派（同一域名的不同邮箱可位于不同服务商）。WebFinger (RFC 7033) 已实现此功能，Mastodon证明了其可扩展性。

2. 可轮换密钥的身份

身份不能等同于密钥（密钥会丢失或过期），身份应是密钥所证明的东西。方案有两个锚点： * 密码学连续性：发现文档发布当前密钥和一个轮换链，其中每个新密钥由前一个密钥签名。知道旧密钥的人可以验证新密钥，无需信任第三方。这是ATProto或Keybase使用的sigchain。 * 域名控制作为后备：如果密钥丢失（如电脑被盗），域名可以声明一个没有链的新密钥，但需经过一个强制公告期（如30天），在此期间，知晓旧密钥的服务器会显示“身份由域名重新锚定，而非签名”的警告。

然而，域名锚定的身份有其弱点：域名是租用的，不是拥有的。如果域名过期被他人注册，新所有者可以在你的 .well-known 中发布他们的密钥，从而接收你的邮件并以你的身份签名。这是ATProto试图通过DID将身份与域名分离来解决的问题。

3. 带队列的投递（存储转发）

投递是通过POST请求将消息发送到收件人的收件箱。关键在于谁发起请求：你的客户端不直接投递给收件人，而是发送给你自己的服务器（一个经过身份验证的POST到你的发件箱）。你的服务器负责排队、指数退避重试和遵循 Retry-After 指令。这承认了SMTP中MUA/MSA/MTA分离的正确性。SMTP的一个巧妙之处在于，如果目标服务器宕机，你的服务器会重试数天。

一个改进是：每条消息携带一个由其内容哈希生成的ID，使重试具有幂等性。接收服务器通过ID去重，从而从根本上避免了因ACK失败导致的重复邮件。

4. 使用现有密钥进行签名和加密

消息是一个签名对象，而非纯文本。这带来了诸多好处： * 静态真实性：存储的邮件携带其密码学证明。转发会保留原始签名，即使经过多次转发也无法伪造发件人。 * 无需DKIM的发送者验证：接收服务器从 from 域名的 .well-known 获取公钥并验证签名。这是Webmention的验证方式。 * 端到端加密：发现文档发布加密密钥（X25519），消息体使用HPKE加密。信封（发件人、收件人、ID、日期）保持可见用于路由和过滤，只有收件人能阅读内容。 * 线程：通过内容哈希的 in_reply_to 和 references 字段，无需启发式算法即可重建对话。 * 附件：附件在消息外部。附件是一个包含 {hash, url, size} 的对象，指向发送者的服务器。接收者按需下载，其服务器可以镜像。不再有Base64膨胀邮箱。

5. 分层反垃圾邮件

HMTP可以从三个层面入手： 1. 身份成本：以 ana@example.com 签名需要在 example.com 提供密钥文档。身份锚定于域名，而域名需要花钱。这为创建独立身份设置了成本。 2. 首次联系同意：未知发件人的邮件不会进入收件箱，而是进入“请求”箱，并显示其第一条消息（类似Signal的消息请求）。你接受后，对话才永久开启。陌生人可以“敲门”，但不能填满你的客厅。 3. 陌生人可选邮资：服务器可以对首次联系回复 402 Payment Required 状态码。每个邮箱可配置，使冷垃圾邮件的成本不再为零。

6. 阅读也需标准化

电子邮件将发送（SMTP）和阅读（IMAP/POP）标准化为两个独立的世界。HMTP无需发明新东西：通过JSON/HTTP阅读、同步和搜索邮箱已由IETF标准化为JMAP。HMTP定义投递，阅读则使用JMAP并增加一个新对象类型。通过SSE或WebPush向客户端推送。整个周期（发送、投递、阅读、同步）都基于HTTP。

结论

电子邮件的每个问题都有已部署的解决方案：Mastodon的发现、ActivityPub的投递、IndieWeb的验证、Bluesky的可轮换身份、Fastmail的阅读、Signal的同意。电子邮件的升级版已经存在，但无人将其组装起来。

HMTP用现代方案解决了诸多问题： * 信誉与权限（SPF、DKIM、DMARC等）：被每条消息的密码学验证取代，只需一次签名和一次GET请求。可验证的属性无需信誉。 * 发件人伪造：在结构上不可能。接收方根据 from 域名的密钥验证签名，签名随消息一起传递，即使被转发。 * 邮件委派（MX记录）：由 .well-known 中的静态文档实现，支持按用户委派，无需修改DNS。 * 内容隐私（PGP从未普及）：默认端到端加密，接收服务器存储其无法读取的消息体。 * 垃圾邮件（事后统计过滤）：首次联系同意、锚定于域名的有成本身份、以及可选的 402 邮资。 * 重试导致的重复：消息ID是内容的哈希，重试具有幂等性，接收方自动去重。 * 基于启发式的线程重建：in_reply_to 指向父消息的哈希，对话成为可验证的图。 * 轻量邮箱：附件通过引用（哈希+URL）实现，按需下载。 * 简单、熟悉的基础设施：一切通过标准HTTPS传输，使用与网站相同的Nginx和证书。 * 密钥轮换（DKIM的操作噩梦）：一条命令即可完成。由于没有固定密钥，新密钥立即被信任，被盗密钥也迅速失效。

作者已实现一个工作原型（Python），涵盖了完整传输：签名投递、源端验证、端到端加密、首次联系同意、去重、线程、带指数退避的队列和单命令密钥轮换。原型有意省略了外围组件，如签名轮换链、402 邮资、引用式附件和JMAP阅读。README包含快速入门指南、双节点加密邮件演示以及从DNS到systemd的完整生产指南。请注意，这是一个设计实验，密码学实现未经审计，请勿用于任何依赖其安全性的机密信息。

根据评论内容，总结如下：

主要观点与论据：

1. 对“首次联系同意”机制的认可与质疑

   • 支持者认为该机制能有效控制陌生人邮件（如Signal的请求箱），避免垃圾邮件填满收件箱（评论1）。
   • 质疑者指出，这仅将问题转移，若忽略所有外部通信，效果有限（评论4）。
   • 关键引用：
     • "A stranger can knock on your door... but they can't fill up your living room."（评论1）
     • "Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored."（评论4）

2. 对“域名控制作为后备”的争议

   • 反对者认为域名是“租用”而非“拥有”，过度依赖域名是弱点，应强调私钥丢失后需重新开始（评论2）。
   • 关键引用：
     • "a domain is not owned, it is rented... I want to normalise the idea that if you lose your private key, you need to start again."（评论2）

3. 对电子邮件替代方案的可行性讨论

   • 部分评论认为网络效应使邮件难以被替代，建议通过向后兼容SMTP或增量改进（如MTA-STS）来推动（评论3）。
   • 另一些评论批评基于HTTP的设计，认为“并非一切都是超文本”（评论9），或指出HTTP应更像SMTP（评论13）。
   • 关键引用：
     • "I think the network effects make email hard to replace... If this could include a migration path, with backwards compatibility with SMTP, I think it would have a better shot."（评论3）
     • "Not everything is hypertext."（评论9）

4. 对垃圾邮件解决方案的探讨

   • 支持“邮资”机制（如402响应）以增加垃圾邮件成本（评论4、12）。
   • 但评论4认为，仅靠“首次联系同意”无法根治问题。
   • 关键引用：
     • "Optional postage for strangers... the cost of cold spamming stops being zero."（评论4）
     • "I like that the author at least head fakes towards postage, which is how spam gets solved, for real."（评论12）

5. 其他技术细节与用户体验批评

   • 内容寻址邮件可能破坏邮件列表功能（评论6）。
   • 网站设计（如实时访客计数器）影响可访问性（评论7）。
   • 关键引用：
     • "Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id."（评论6）
     • "The obnoxious real time visitors counter seriously screws with my screen reader."（评论7）

平衡性总结：
评论对提案既有积极评价（如首次联系同意、邮资机制），也有尖锐批评（域名依赖、HTTP基础、用户体验）。多数评论认为邮件替代方案需解决网络效应、向后兼容性及实际部署问题，而非仅停留在理论设计。