没那么难，为什么这么多年都不标准？

因为那不会解决 PGP 试图解决的问题。

PGP 是端到端加密，因此如果 SMTP 服务器有任何方法可以破坏加密，那么该方案将失败。

对于您提出的方案，假设 Alice (alice@charlie.com) 想要向 Bob (bob@dave.com) 发送私人消息。使用您提出的方案，Alice 的邮件客户端或 Alice 的 SMTP 服务器通过与 dave.com 建立 TLS 连接来获取 Bob 的公钥。这很好，只要 dave.com 是诚实的并且实际上返回 Bob 的公钥。但是 dave.com 的运营商可能已将 dave.com 配置为返回由 Eve 创建的伪造公钥，或者 Eve 可以侵入 dave.com 并进行设置。现在 Alice 的邮件客户端/邮件服务器会很乐意接受 Eve 的证书，认为公钥是 Bob 的。在此模型中，dave.com 的运营商可以拦截 Bob 的任何电子邮件。

现在，只要 dave.com 是诚实的，这仍然可以防止第三方欺骗。如果这至少可以防止第三方窥探，我们为什么不这样做呢？主要是因为 SMTPS 也提供了相同级别的保护，同时也更加简单。如果邮件服务器运营商的 MITM 不是您关心的问题，那么您已经可以通过确保双方都使用 SMTPS 来很好地保护您的电子邮件。

请注意，端到端加密的难度与获取公钥无关。大多数支持 PGP 的电子邮件客户端还支持从 LDAP 或 HPKP 自动获取公钥。端到端加密的难点在于验证公钥。

没有已知的验证对用户完全透明且完全安全的公钥的方法。Web of Trust 或证书颁发机构模型最接近，但 Web of Trust 有很多警告，证书颁发机构模型依赖第三方进行验证。

将 PGP 集成到 SMTP 中。

PGP 是数据的容器格式（如邮件但不限于邮件），它为数据添加加密和/或签名。SMTP 是一种传输协议。

您不会将容器格式集成到传输协议中。这与说您应该将 Office（文本、图像...的容器）与 SMTP（传输）集成以将办公文档发送给某人是一样的。

PGP 也用于 SMTP 之外，因为它只是一个容器。而且 SMTP 也用于传输与 PGP 容器不同的东西，因为它只是一种传输协议。

如果您询问是否将 PGP 或 S/MIME 等端到端加密集成到 SMTP 中，它也不会起作用，因为 SMTP 是逐跳传递而不是端到端的。除此之外，SMTP 甚至不包括最后一跳，即从最后一个邮件服务器到客户端的传递。这是通过 POP 或 IMAP 等协议完成的。

Lea请求Luke的域名jedi.com的服务器告诉她luke@jedi.com的公钥……

这就是您拥有关键服务器或其他类型的中央目录的目的。但莉亚怎么知道这实际上是卢克的钥匙，而不是自称是卢克的人的钥匙？因此，您需要进行一些信任传播，例如以信任网络 (PGP) 或更集中的结构 (S/MIME) 的形式，或者通过信任特定中央目录中的所有内容。

因此，任务不是将 PGP 与 SMTP 集成，而是在邮件客户端中更好地支持 PGP，以便它们自动获取收件人的 PGP 密钥。但当然，在密钥服务器或其他目录的某个地方，必须首先为接收者提供一个可验证的 PGP 密钥，因此另一项任务是使密钥创建、发布和管理密钥（更新、撤销......）更容易。这些都是邮件传递 (SMTP) 本身之外的所有内容。

编写标准很容易。大约十年前，我就想到了这个问题。它归结为人力/成本因素。您如何说服 10 亿技术盲的人更新他们的软件而没有感知到的好处，并说服数千名跨平台的开发人员实施此协议，以及数百万组织切换到新协议，即使您提供它离开. 早在 2011 年，我们已经在世界某些地区用尽了 IPv4 地址，但互联网仍然没有在全球范围内使用 IPv6。尽管我们实际上扼杀了互联网的发展，但我们甚至无法说服人们改用 IPv6。即使您今天可以制定一个标准，并将其提交给 IETF 进行正式化和分发，也要到 2030 年，它才会普及到足以关闭当今运行的无数“经典”邮件服务器。

加密在邮件传输期间已经到位（STARTTLS在 SMTP 中），但还不够复杂，无法防止 MITM。

我相信 PGP 更像是电子邮件客户端之间的最终用户体验，如果您不完全信任所涉及的服务器，这将很有帮助。

（PGP 有时对不那么细心的用户很容易受到 MITM 的影响，但是，就像在 SSH 中一样，如果您检查正确的密钥签名，那么问题就解决了）

但是，对于像 Gmail 这样的基于云的电子邮件服务，它们无论如何都必须可供服务器使用，才能获得良好的用户体验，因此 PGP 只会成为障碍。

希望有一天我们会在 SMTP 中获得 MITM 证明加密，但这不是问题，因为邮件服务器位于受控网络上。