跳到主要内容

1. 简介

DomainKeys Identified Mail (DKIM) 允许个人, 角色或组织通过把其有权使用的域名 [RFC1034] 与消息 [RFC5322] 关联起来, 声明对该消息承担某种责任. 这可以是作者所在组织, 操作性中继, 或其某个代理. 责任声明通过加密签名验证, 并通过直接查询 Signer 的域来取得相应公钥. 消息从作者传送到收件人时会经过中继, 这些中继通常不会对消息内容作实质性修改, 因而会保留 DKIM 签名. 一条消息可以包含多个签名, 这些签名可以来自参与该消息处理的同一组织或不同组织.

DKIM 采用的方法不同于以往的消息签名方法, 例如 Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] 和 OpenPGP [RFC4880], 其差异包括:

  • 消息签名写入为一个消息 header field, 因此人工收件人和现有 MUA (Mail User Agent) 软件都不会因为消息正文中出现签名相关内容而混淆;

  • 不依赖由知名且受信任的证书机构签发公钥/私钥对;

  • 不依赖部署任何新的 Internet 协议或服务来分发或撤销公钥;

  • 签名验证失败不会强制拒收消息;

  • 不试图把加密纳入该机制; 并且

  • 消息归档不是设计目标.

DKIM:

  • 与现有电子邮件基础设施兼容, 并尽可能保持透明;

  • 只需要最少的新基础设施;

  • 可以独立于客户端实现, 从而缩短部署时间;

  • 可以渐进部署; 并且

  • 允许把签名委托给第三方.

1.1. DKIM 架构文档​

建议读者熟悉 [RFC4686], [RFC5585] 和 [RFC5863] 中的材料, 它们分别提供 DKIM 的发展背景, 服务概览, 以及部署和运维方面的指导与建议.

1.2. 签名身份​

DKIM 将消息 Signer 的身份问题与消息声称作者的身份问题分离. 具体而言, 签名包含 Signer 的身份. Verifier 可以使用签名信息来决定如何处理消息. 签名身份作为签名 header field 的一部分包含在内.

INFORMATIVE RATIONALE: 由于包括 MUA 在内的收件方邮件系统对消息有多种解释方法, DKIM 签名指定的签名身份不要求匹配任何特定 header field 中的地址.

1.3. 可扩展性​

DKIM 设计用于支持电子邮件标识问题所体现的极高可扩展性需求. 域名数量以数百万计, 单个地址的数量则更为庞大. DKIM 试图保留当前电子邮件基础设施的积极特性, 例如任何人无需引荐即可与其他任何人通信的能力.

1.4. 简单密钥管理​

DKIM 不同于传统的层次化公钥系统, 因为它不需要证书机构基础设施; Verifier 直接从所声明 Signer 域内的仓库请求公钥, 而不是从第三方请求.

DNS 被提议作为公钥的初始机制. 因此, DKIM 当前依赖 DNS 管理以及 DNS 系统的安全性. DKIM 的设计允许在其他密钥获取服务可用时扩展到这些服务.

1.5. 数据完整性​

A DKIM 签名把 "d=" 名称与消息部分或全部内容计算出的哈希关联起来 (见 Section 3.7), 以防止该签名被复用于不同消息. 验证签名只断言被哈希的内容自签名以来未发生变化, 并不对"保护"消息端到端完整性作任何其他断言.

最后于 更新