1：与 PGP 相比，S/MIME 的优势在于您签署/加密了完整的 mime 实体，而不是文本。这使得对整个消息/rfc822 进行签名/加密成为可能。是的，标题必须对 MTA 可见且可更改，但这可以通过获取整个邮件、S/MIME 签名或对其进行加密，然后将签名/加密的 S/MIME 实体打包到一个新的邮件容器中来实现。此功能甚至可以用于加密主题，方法是让内部（加密）主题为“这是您的信用卡号 1234-1234-1234-1234 的信用报告”，然后外部主题为“来自的加密邮件你的银行！”。

大多数 MUA 将通过显示按钮、附加文件或另一个 UI 元素来打开“包含”消息来对消息/rfc822 容器做出反应，或者它将在原始消息中显示包含的消息，如浏览器中的“iframe”工作. 这两种方法都允许您验证所有签名字段和所有数据，但根据 RFC 应该隐藏的数据除外。这使得甚至可以使用甚至不同的加密邮件。

例如，外部容器有From: YourBank Info Department <info@yourbank.com>但内部加密容器有From: Name Namesson <name.namesson@yourbank.com>

但是，在一种情况下，签名/加密/解密/验证完整的 MIME 容器/实体而不是纯文本是危险的。这是当某人签署/加密此人尚未创建的内容时。

一个例子是公证人验证我是男性，例如（我知道这是一个“愚蠢”的例子，但你了解签署 MIME 实体的危险）。

假设我要求公证人签署以下文件：

Content-Type: multipart/alternative; boundary="1234";

--1234
Content-Type: text/plain

Im a male
--1234
Content-Type: text/html

Im a female
--1234--

如果签名是使用 S/MIME 完成的，公证人将验证她/他看到的内容，假设公证人的客户端无法查看 HTML 邮件，然后将显示文本/纯文本版本。公证人标志是因为公证人知道我是男性。然后我将签名的邮件转发给具有 HTML 邮件客户端的验证者，该客户端当然会显示“我是女性”。

另一个例子如下：

 Content-Type: text/html

 I authorize the transfer of $ 100<font color="#FFFFFF"> 000 000 000</font><br>
 from your account to my account 1234 1234 1234

如果您作为客户经理签署此文件，并且目标邮件客户端（假设银行员工的邮件客户端在验证签名后从邮件中删除 HTML），您可以大概了解会发生什么。

在这种情况下，PGP 可以比 S/MIME 具有很大的安全优势，因为在 PGP 中，您确切地知道您在签名、加密、解密或验证什么。

2：在 PGP 中，将无符号数据附加到 -----BEGIN PGP...----- 和 -----END PGP...----- 之外很容易。在 S/MIME 中，这是在 S/MIME 容器之外完成的。这可以像 1 一样完成，将整个签名邮件重新打包到一个新的 message/rfc822 容器中，然后将免责声明添加到外部容器中。但是如果您需要在 S/MIME 邮件中添加免责声明，我建议您使用像 Ciphermail 这样的网关签名解决方案，可以在签名邮件之前添加免责声明。

3：MTA 可以修改 PGP 和 S/MIME 邮件中的所有外部标头。MTA 无论如何都不应该触及内部标题（除非它的签名、加密、解密或验证邮件）。一些 MTA 可能会将内容从 8bitmime 重新编码为 qp，以防接收服务器不宣布支持 8BITMIME，为什么最好始终将签名邮件作为引用打印发送。

4：S/MIME 通过将这些标头移动到 S/MIME 容器内来签署所有对内容解释有影响的标头，例如 Content-Type。PGP 应该完全忽略容器并始终签署明文，但是，MUA 可能会在不应该的情况下显示带有格式的 PGP 盔甲内的内容。在某些情况下，这也会影响签名验证，例如，如果邮件客户端将可见内容（例如，带有剥离的 HTML 标记）发送给 PGP 验证器，则内容将显示为无效。最好的方法是在使用 PGP 时，始终使用复制和粘贴 PGP 邮件的外部解决方案。或者使用可以将 PGP 邮件重新编码为文本/纯文本的中央解决方案，以确保这些对内容的解释没有任何影响。

5：对于 S/MIME 和 PGP，即使他们的客户端不支持 S/MIME 或 PGP，最终用户也可以看到签名数据。在 S/MIME 中，对于非 S/MIME 感知的客户端，签名邮件似乎有一个 smime.p7s 附件，如果您不想验证邮件，可以安全地忽略该附件。对于 PGP，它将如下所示：

-----BEGIN PGP SIGNED MESSAGE-----
bla bla bla

Best regards, Name Namesson
-----BEGIN PGP SIGNATURE-----
fkjhdklghdflhilgnegdngnlbvilgbdgeetbugbzjbeu
-----END PGP SIGNATURE-----

因此邮件客户端用户可以看到消息的内容，即使客户端根本不支持签名。如果你想添加验证说明，您可以添加伊斯利tihs INSIDE的签名邮件（因此它被签署）。

如果您想在签名内容之外添加此类说明，可以参考我的回答的第 2 点。对于加密邮件，在 PGP 中它与签名邮件相同 - 例如，将其添加到 BEGIN/END 标题行之外。对于 S/MIME，您必须重新打包邮件，因此将加密邮件放入 message/rfc822 容器中，然后将其添加到包含解密说明的明文容器中。

6：是的，您可以在 S/MIME 中隐藏 To 和 CC，只需将它们移动到加密的消息/rfc822 容器中即可。但是，建议有一个指向原始收件人的 To，以防止邮件被垃圾邮件过滤器丢弃，因为垃圾邮件过滤器可能会将 To: 与信封收件人进行比较，如果不匹配，它会将其视为垃圾邮件。但是，CC 可以安全地隐藏起来，只有拥有钥匙的人才能看到。

在 PGP 中，这是不可能的，因为 PGP 会加密明文。但是，您也可以在明文邮件的开头手动添加如下文本：“我确实将这封邮件的副本发送到 name2@somehost.com 和 name3@someotherhost.com”。

7：是的。中间 MTA 可以验证邮件内的签名。对于 S/MIME，这可以完全透明地发生。在 PGP 中，只有将密钥上传到中间 MTA 知道的密钥服务器并从中下载密钥时，才会发生这种情况。请注意，对于 MTA 到 MTA 的完整性，我建议改用 DKIM、STARTTLS 和 SPF。例如，您可以配置 MTA 以强制 STARTTLS 到您知道支持 TLS 的邮件服务器。

8：不。签名和加密的消息总是稍微大一点。如果您将邮件签名或加密到具有大小限制的主机，则需要考虑这一点。同样，S/MIME 和 PGP 会使邮件尽可能小，因此加密邮件实际上会“泄露”邮件的大小。但是，它可以隐藏加密消息的“真实”大小，方法是用无用的数据填充它。您甚至可以添加类似“这是确保加密数据始终具有相同大小的填充”的通知。然后添加大块 lorem ipsum 文本。注意 lorem ipsum 块的大小不能小于最大的邮件，否则人们可以在加密的内容中看到大于一定大小的邮件。

请注意，S/MIME 在一个大块中一次性对所有文本进行签名或加密，然后添加 smime.p7s 附件。加密的 S/MIME 邮件只有附件 smime.p7m ，PGP 确实单独加密附件，为什么这些附件的大小会泄漏。PGP 附件是整体加密的。PGP 附件是通过在包含签名的邮件中附加一个新附件来签名的。例如，Powerpoint.ppt 是通过将附件 Powerpoint.ppt.asc 附加到邮件来签名的，因此邮件包含 Powerpoint.ppt 和 Powerpoint.ppt.asc 文件。但是，如果你想在加密时隐藏附件的大小，你可以总是把附件放在一个 .zip 文件中，然后在这个 zip 里面，你放一个无用的文件，比如 large ，使你的所有 zip 的大小都是固定的。注意，接下来需要根据压缩（或关闭压缩）计算无用文件的大小，无用文件需要是随机数据。当您加密包含您的附件和无用文件的此 zip 文件时，它将被转换为一个二进制 blob，其中那些没有密钥的人无法看到有关您发送的附件的大小、名称或数量的任何信息。

9：可以，前提是网关知道接收方的私钥。这对 PGP 和 S/MIME 都有效。如果您想将审核邮件发送给您不知道私钥的收件人，您可以始终加密来自网关的邮件，并将“未加密”的邮件发送到网关，但通过其他方式加密，例如 STARTTLS，和/或使用网关知道其私钥的密钥加密的 PGP/SMIME。如果第三方位于异地，您可以始终将第三方的密钥添加为 S/MIME 和 PGP 中的接收者，从而允许审核员在真正的接收者之外进行解密。