您的论点是有效的，使用Sign & Encrypt方法，两层是独立的，这使您（作为 Bob）能够在签名仍然存在时重新加密 Alice 的消息并将其转发给 Carol。

另一种选择是先加密然后签名，但这种方法也存在漏洞。Bob 或任何窃听者可以删除签名并添加他自己的签名。在不知道加密消息的内容的情况下，他可以冒充自己作为消息的发送者。

关于 SE 的讨论很多，所以我不会深入讨论。例如：我们应该先签名后加密，还是先加密后签名？

该解决方案必须在签名和加密层之间添加绑定，因为漏洞在于这两个独立层所在的间隙。
正如您所说，我们可以将收件人的地址添加到消息的加密部分中。

在此页面（S/MIME、PKCS#7、MOSS、PEM、PGP 和 XML 中的缺陷签名和加密）的第 5 节中，提出了五个修复选项：

1. 将收件人姓名签名为明文
2. 将发件人姓名加密为明文
3. 合并两个名称
4. 再次签署签名和加密的消息
5. 再次加密签名的密文。

对于命名修复解决方案：

朴素的 Sign & Encrypt 看起来很安全的部分原因可能是，对于许多常见的有效负载消息，S&E 是安全的。例如，即使爱丽丝只是对文本“亲爱的鲍勃，交易结束”进行签名和加密。很遗憾，爱丽丝，'' 那么爱丽丝的消息是安全的，尽管只是偶然的。两个加密层下名称的存在是至关重要的，但包含两个名称并不是绝对必要的

使用签名/加密/签名：

内部签名：“爱丽丝写明文；”
加密：“只有 Bob 可以看到明文；”
外部签名：“Alice 使用密钥 B 进行加密。”

使用加密/签名/加密：

第一次加密：“只有 Bob 看到明文；”
签名：“爱丽丝写明文和密文；”
外层加密：“只有 Bob 可以看到 Alice 写了明文和密文。”

您还可以在该链接下找到成本/收益分析，最简单的修复是将收件人地址添加到明文中，然后签名和加密。

回到您的主要问题，PGP 客户端似乎没有标准实现来添加/验证密文中的收件人地址，因此可以继续手动将地址添加/验证到消息正文中。

这可以通过简单地使用适当的人际交流来防止。

通常，您以以下方式开始消息：

"Hello Bob
Nice to hear from you again.
bla bla bla"

因此，Carol 会很容易地检测到这种错误，因为消息没有发给他/她，并且当然会问 ​​Alice：“你把这个发给我了吗？那么你有错误的地址。” 爱丽丝会说：“不，我没有发给你，消息一定是泄露并重播了。”

请注意，“Hello Bob”应该是签名部分的一部分，因此攻击者无法修改。

如果您不知道邮件的名称或预期收件人，那么以特定方式突出内容以明确其是针对特定人的内容是正常的，因此如果邮件落入错误的收件箱，接收者会明白该消息不是给她的。

例如，如果您向“support@random_isp.com”发送消息

"Hello.
My broadband account just got suspended, my RandomISP customer number is 153424.
Could you check my account details if the latest bill payment has arrived and whats happened if not."

如果这封邮件会进入您的收件箱，那么很明显它不是有意或发送给您的。

另请注意，还有其他系统，如 SPF 和 DKIM，它们将验证并阻止使用发件人的电子邮件地址，在这种情况下，这也会放弃任何重播尝试，因为发件人的电子邮件与对应的公钥不匹配用于签名邮件的私钥。