当发件人使用 Thunderbird 向收件人发送 S/MIME 加密邮件时，Thunderbird 除了需要收件人的证书外，还需要发件人的证书，以便 Thunderbird 可以将发件人的证书连同邮件一起发送给收件人。这样做有两个原因：

1) 使接收者可以在消息上验证发送者的数字签名，该数字签名是使用发送者的私钥与发送者证书中的发送者的公钥对应的。

2) 使收件人可以用加密的消息回复发件人。

Thunderbird（以及任何其他电子邮件客户端）也需要您自己的证书来为自己加密电子邮件。

为什么呢？

当您发送电子邮件时，不仅会发送电子邮件，还会将其副本保存在您的已发送文件夹中。因此，当您发送加密的电子邮件时，电子邮件不仅需要为收件人加密，还需要为您自己加密。否则，您将无法阅读自己发送的电子邮件副本。这意味着消息是使用收件人和发件人的公钥加密的，因此双方都可以使用他们的私钥对其进行解密。（顺便说一句，当您发送给多个收件人时，使用相同的机制。）

以上内容在RFC 8551 S/MIME 4.0 消息规范（及其前身）中进行了规定。引用自第 3.3 节创建仅包含信封的消息，步骤 2：

除了为每个接收者加密一份内容加密密钥 (CEK) 的副本外，还应该为发起者加密一份 CEK 副本并包含在 EnvelopedData 中。

请注意，内容加密密钥 (CEK) 是指使用临时生成的对称密钥 (CEK) 加密消息内容的实际机制。然后使用公钥对这个密钥进行非对称加密。因此，为了简单起见，当我们说消息使用公钥加密时，这实际上意味着只有 CEK 使用公钥加密并附加到消息中。详细规范可以在RFC 5652 Cryptographic Message Syntax (CMS)中找到。

从理论上讲，电子邮件客户端可以只为收件人加密，而不加密发送的副本，但这会造成用户很可能不知道的安全漏洞，这是完全不可取的。

一般来说，一个好主意^TM

根据 S/MIME 第 4 版标准，任何电子邮件客户端都需要证书或签名或对消息进行可逆加密没有技术原因。

但是对于任何一般可用性，所有电子邮件客户端都需要发件人证书是标准的：

• 签名以验证发件人：对于加密消息的生态系统而言，人们通常也无法确认发件人是不够的，尽管从技术上讲，这不是必需的
• 加密响应：如果收件人想要回复，发送的电子邮件将包含引用的第一条消息，如果发件人没有同时发送证书以发回加密消息，则该消息将不加密发送

因此，虽然可能有一个用例，您希望发送加密的电子邮件，但您不需要验证或回复发件人，但这肯定不是设置以用户为中心的电子邮件客户端的常见用例，并且事实上，阻止用户尝试以维护加密电子邮件生态系统的完整性是合理的。

如果您需要满足此用例，如您所演示的，制作自己的电子邮件发送脚本来执行此操作相当容易。

S/MIME 规范中概述

S/MIME 4 规范说客户端SHOULD也有一个证书，以便发送者的公钥能够访问用于加密消息的密钥，这意味着客户端，如 Thunderbird，将被期望遵循这一点。

还有一个版本的 Cryptographic Message Syntax CMS规范，其中用于加密消息的密钥来自接收方和发送方的密钥，这意味着发送方需要证书才能完全加密消息。目前我不知道 Thunderbird 是否使用这种方法创建它的消息密钥。