← RFC Reference

RFC 5751：S/MIME 3.2 消息规范

存在的原因

传输层安全性（TLS、STARTTLS）保护邮件在各跳之间的传输，但有局限性：

• 服务器操作员可以读取您的邮件。TLS 在每台服务器处终止。发送服务器、接收服务器和任何中介都能看到纯文本内容。
• 无法保证来源。DKIM 证明某个域处理了该消息，但无法证明是哪个人撰写的。
• 递送后无篡改检测。消息存储在服务器上后，如果消息被修改，DKIM 签名可能失效。S/MIME 签名保护内容本身。

S/MIME 提供端到端加密（仅收件人可解密）和数字签名（收件人可验证发件人身份和内容未被修改）。它使用与保护 HTTPS 相同的 PKI 中的 X.509 证书。

工作原理

两种操作

S/MIME 使用 CMS（密码消息语法）将标准 MIME 消息包装在密码信封中：

您可以仅签名、仅加密或签名后加密（最常见的组合）。

签名消息

发件人使用其私钥创建邮件内容的数字签名。存在两种格式：

• 明文签名（multipart/signed）：原始消息可被任何客户端读取。签名是单独的 MIME 部分。非 S/MIME 客户端正常查看消息并忽略签名。
• 不透明签名（application/pkcs7-mime）：消息和签名捆绑在一起。仅 S/MIME 感知的客户端可提取内容。

-- 明文签名消息结构 --
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha-256; boundary="----sig"

------sig
Content-Type: text/plain

这是原始消息内容。
任何电子邮件客户端都可以读取它。

------sig
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBgl...
（base64 编码的 CMS SignedData）
------sig--

加密消息

发件人使用收件人的公钥加密（来自其 X.509 证书）。仅收件人对应的私钥可解密：

-- 加密消息结构 --
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIAGCSqGSIb3DQEHA6CAMIA...
（base64 编码的 CMS EnvelopedData）

实际上，S/MIME 使用混合加密：随机对称密钥（如 AES-128-CBC）加密消息，收件人的 RSA/EC 公钥加密该对称密钥。

关键技术细节

证书要求

S/MIME 依赖由证书颁发机构 (CA) 颁发的 X.509 证书。证书必须：

• 在主题备用名称 (SAN) 或主题字段中包含发件人的电子邮件地址。
• 具有 emailProtection 扩展密钥用法 (EKU)。
• 由收件人客户端信任的 CA 颁发。

这是 S/MIME 采用的最大实际障碍：每个发件人都需要一个证书，每个收件人都需要发件人的公开证书来验证签名或发送加密回复。

算法要求（S/MIME 3.2）

SHA-1 和 3DES 仍然因向后兼容性而被引用，但被认为是较弱的。S/MIME 4.0 显著更新了这些要求。

证书发现

对于加密，发件人需要收件人的证书。常见的发现方法：

• 以前的通信：从收件人发送给您的已签名消息中提取证书。
• LDAP 目录：许多组织在 LDAP 目录中发布证书。
• DNS（SMIMEA/DANE）：RFC 8162 通过 SMIMEA 记录定义基于 DNS 的证书发现。
• 密钥服务器或网关：企业 S/MIME 网关集中管理证书。

常见错误

• 将 S/MIME 与 TLS 混淆。TLS 保护服务器之间的连接。S/MIME 保护消息内容端到端。它们解决不同的问题，应该一起使用。
• 将 SHA-1 用于签名。SHA-1 在碰撞抵抗方面在密码学上已被破坏。始终使用 SHA-256 或更强的。
• 加密但不签名。加密但未签名的消息对发件人身份没有证明。始终在加密之前签名以进行经过身份验证的加密。
• 忘记证书分发。如果您没有收件人的公开证书，就无法向其发送加密电子邮件。在部署 S/MIME 之前计划证书交换。
• 使用自签名证书。收件人的客户端将显示信任警告。使用来自公认 CA 的证书以实现互操作性。
• 未处理混合收件人。如果某些收件人有 S/MIME 证书而其他收件人没有，您需要发送两次消息：对有证书的加密，对没有的发送纯文本。
• 使用不透明签名破坏 DKIM。不透明签名消息重组了 MIME 正文，这可能使 DKIM 正文哈希失效。明文签名消息对 DKIM 兼容性更安全。

可递送性影响

• S/MIME 签名可以提高信任。某些企业邮件网关验证 S/MIME 签名并更有利地对待已签名消息。Microsoft Outlook 为有效的 S/MIME 签名突出显示信任功能区。
• 加密内容对垃圾邮件过滤器不透明。垃圾邮件过滤器无法检查加密消息正文。某些过滤器可能对加密消息持怀疑态度，而其他过滤器则将其放行。对于批量电子邮件，S/MIME 加密通常不实用。
• 不是 SPF/DKIM/DMARC 的替代品。S/MIME 在用户级别运行；SPF、DKIM 和 DMARC 在域级别运行。两个层都有不同的用途。S/MIME 证明个人身份；DKIM 证明域授权。
• 企业合规性。受管制行业（金融、医疗保健、政府）通常要求 S/MIME。对事务性电子邮件支持 S/MIME 签名对符合性敏感的收件人来说可以是差异化因素。

Related RFCs