跳到主要内容

4. 概览

本节提供 DMARC 环境设计和运行方式的一般概览.

4.1. 认证机制​

本版本 DMARC 支持以下机制来确定 Authenticated Identifier:

  • [DKIM], 它在已验证 DKIM-Signature 头字段的 "d=" 标签内容中提供一个域级标识符.

  • [SPF], 它可以认证 [SMTP] HELO/EHLO 命令中的域 (HELO identity), 也可以认证 SMTP MAIL 命令中的域 (MAIL FROM identity). DMARC 使用 MAIL FROM identity 的 SPF 认证结果. [SPF] 的 Section 2.4 描述了 MAIL 命令为空路径时的 MAIL FROM 处理.

4.2. 关键概念​

DMARC policy 由 Domain Owner 发布, 并由 Mail Receiver 在 SMTP 会话期间通过 DNS 获取.

DMARC 的过滤功能基于 RFC5322.From 字段域是否与来自 SPF 或 DKIM 的已认证域名对齐 (匹配). 当为 RFC5322.From 字段中找到的域名发布了 DMARC policy, 且该域名未通过 SPF 或 DKIM 验证时, 在投递给参与的接收方时, 该消息的处置可能受到该 DMARC policy 的影响.

需要注意, DMARC 采用的认证机制只认证 DNS 域, 不认证消息中任何电子邮件地址标识符的 local-part, 也不验证消息内容的合法性.

DMARC 的反馈组件涉及收集声称来自 Organizational Domain 的已接收消息的信息, 用于向 Domain Owner 提供定期聚合报告. 此类报告的参数和格式将在本文档后续章节讨论.

启用 DMARC 的 Mail Receiver 还可能生成逐消息报告, 其中包含与 SPF 和/或 DKIM 失败的单个消息相关的信息. 在调试部署时 (如果可以确定消息虽未通过认证但仍为合法消息) 或分析攻击时, 逐消息失败报告是有用的信息来源. 此类服务的能力由 DMARC 启用, 但在其他引用材料 (如 [AFRF]) 中定义.

如果至少一种受支持的认证机制满足以下条件, 则消息满足 DMARC 检查:

  1. 产生 "pass" 结果, 并且

  2. 基于一个按 Section 3 定义处于 alignment 的标识符产生该结果.

4.3. 流程图​

    +---------------+
    | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
    +---------------+                        .           .         .
        |                                    .           .         .
        V                                    V           V         .
    +-----------+     +--------+       +----------+ +----------+   .
    |   MSA     |<***>|  DKIM  |       |   DKIM   | |    SPF   |   .
    |  Service  |     | Signer |       | Verifier | | Verifier |   .
    +-----------+     +--------+       +----------+ +----------+   .
        |                                    ^            ^        .
        |                                    **************        .
        V                                                 *        .
     +------+        (````````````)      +------+         *        .
     | sMTA |------->( other MTAs )----->| rMTA |         *        .
     +------+        (````````````)      +------+         *        .
                                            |             * ........
                                            |             * .
                                            V             * .
                                     +-----------+        V V
                       +---------+   |    MDA    |     +----------+
                       |  User   |<--| Filtering |<***>|  DMARC   |
                       | Mailbox |   |  Engine   |     | Verifier |
                       +---------+   +-----------+     +----------+

     MSA = Mail Submission Agent
     MDA = Mail Delivery Agent

上图展示了消息通过 DMARC 感知系统的简单流程. 实线表示实际消息流, 点线涉及用于获取与受支持消息认证方案相关的消息策略的 DNS 查询, 星号线表示消息处理模块与消息认证模块之间的数据交换. "sMTA" 是发送 MTA, "rMTA" 是接收 MTA.

实质上, 步骤如下:

  1. Domain Owner 构造 SPF policy, 并按照 [SPF] 将其发布到其 DNS 数据库中. Domain Owner 还按照 [DKIM] 所述配置其系统以进行 DKIM 签名. 最后, Domain Owner 通过 DNS 发布 DMARC 消息处理策略.

  2. Author 生成消息, 并将消息交给 Domain Owner 指定的邮件提交服务.

  3. 提交服务将相关细节传递给 DKIM 签名模块, 以便生成将应用于消息的 DKIM 签名.

  4. 提交服务将现在已签名的消息中继到其指定的传输服务, 用于路由到预期收件人.

  5. 消息可能经过其他中继, 但最终到达收件人的传输服务.

  6. 收件人投递服务通过将必要数据传递给各自模块来执行 SPF 和 DKIM 认证检查, 每个模块都需要查询 Author Domain 的 DNS 数据 (当标识符对齐时; 见下文).

  7. 这些结果与 Author 的域一起传递给 DMARC 模块. DMARC 模块尝试从 DNS 中为该域获取策略. 如果未找到, DMARC 模块确定 Organizational Domain, 并重复尝试从 DNS 中获取策略. (Section 6.6.3 对此有更详细描述.)

  8. 如果找到策略, 则将其与 Author 的域以及 SPF 和 DKIM 结果结合, 生成 DMARC policy result ("pass" 或 "fail"), 并且可以选择导致生成两类报告之一 (未示出).

  9. 收件人传输服务基于 DMARC 结果将消息投递到收件人收件箱, 或采取其他本地策略动作 (未示出).

  10. 在被请求时, 收件人传输服务从消息投递会话中收集数据, 用于提供反馈 (见 Section 7).

最后于 更新