这篇文章系统记录了我对于DMARC协议的RFC-7489文档的阅读,记录一些我认为重要的关键点和相关问题。
RFC文档要点
DMARC不产生或鼓励提高通过身份验证的电子邮件的投递特权。
DMARC是一种策略分发机制,它支持对身份验证检查失败的消息进行越来越严格的处理,范围从无操作、更改交付到消息拒绝。
2.2 evaluation of anything other than RFC5322.From; 主要评估内容就是MIME.From
2.3 DMARC试图避免发送方和接收方之间需要第三方或预先发送协议。这保留了当前电子邮件基础设施的积极方面。
2.4 In particular, it does not address the use of visually similar domain names (“cousin domains”) or abuse of the RFC5322.From human-readable
. 3 When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment.
3.1 [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] can authenticate either the domain that appears in the RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/ HELO domain, or both. DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier.
3.1 之所以选择From domain作为DMARC机制的中心标识,是因为它是必需的消息头字段,因此保证出现在兼容的消息中,并且大多数邮件用户代理(MUAs)表示RFC5322。从字段作为消息的发起者,并向最终用户呈现此标题字段的部分或全部内容。
3.1 It is important to note that Identifier Alignment cannot occur with a message that is not valid per [MAIL], particularly one with a malformed, absent, or repeated RFC5322.From field, since in that case there is no reliable way to determine a DMARC policy that applies to the message. DMARC不能对有重复MIME.From的消息进行保护。
3.1.1 in relaxed mode, if a validated DKIM signature successfully verifies with a “d=” domain of “example.com”, and the RFC5322.From address is “alerts@news.example.com“, the DKIM “d=” domain and the RFC5322.From domain are considered to be “in alignment”. In strict mode, this test would fail, since the “d=” domain does not exactly match the FQDN of the address.
3.1.1 单个电子邮件可以包含多个DKIM签名,如果对任何DKIM签名进行了对齐和验证,则将其视为DMARC“pass”。
3.1.2 在放松模式下,[SPF]-身份验证域和RFC5322.From必须具有相同的组织域。在严格模式下,只有精确的DNS域匹配才能产生标识符对齐。HELO identity is not typically used in the context of DMARC。HELO标识通常不会在DMARC上下文中使用
3.2 组织域的确定方法 从公共后缀列表中找到最大匹配位x x+1为组织域
4.1 验证机制
- [DKIM], which provides a domain-level identifier in the content of the “d=” tag of a validated DKIM-Signature header field.
- [SPF], which can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity.
4.2 DMARC策略由域所有者发布,邮件接收者在SMTP会话期间通过DNS检索。DMARC的过滤功能是基于是否RFC5322.From字段域与SPF或DKIM的经过身份验证的域名(匹配)对齐。dmarc的记录提取也是基于RFC5322.From
4.2 DMARC使用的身份验证机制仅对DNS域进行身份验证,而不对消息中任何电子邮件地址标识符的本地部分进行身份验证,也不验证消息内容的合法性。
4.2 一条消息通过DMARC检查的要求 SPF/DMARC其一通过 并且5322.From和其对应的验证字段通过一致性检查。
4.3 流程图 先尝试从MIME.From中的域名DNS获取dmarc记录,如果没有会再尝试从组织域名DNS获取
6.3 DMARC通用格式和一些关键字段。
adkim DKIM的验证选择严格模式或宽松模式
aspf SPF的验证选择严格模式或宽松模式
fo 失败报告选项
p:要求的邮件接收者策略 必要字段
1
2
3
4
5none:域名所有者要求不采取特定措施
quarantine:域名所有者希望邮件接收者将DMARC验证失败的邮件标记为可疑的。
reject:域名所有者希望邮件接收者将DMARC验证失败的邮件拒绝。sp:要求邮件接收者对所有子域使用的策略
v:版本 必要字段
1
Version (plain-text; REQUIRED). Identifies the record retrieved as a DMARC record. It MUST have the value of "DMARC1". The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.
6.5 v=”DMARC1” 必须以这种形式在参数列表的首位出现
6.6.1 DMARC接收端措施
1
2
3没有RFC5322.From字段的邮件 拒绝
有多个RFC5322.From字段的邮件 拒绝
有一个RFC5322.From字段但是有多个地址的邮件 拒绝6.6.2 DMARC执行流程
- 1 从邮件正文中提取RFC5322.From字段
- 2 根据RFC5322.From字段中的域名,向对应的DNS服务器查询DMARC记录
- 3 进行DKIM签名验证。一封电子邮件可以包含多个DKIM签名,这一步的结果会传递给算法的其他部分,传递的参数必须包括每个已经检查的DKIM签名中的“d=”字段
- 4 进行SPF验证。结果会用于算法的其他部分,传递的参数一定要包括用于完成SPF校验的域名。
- 5 执行标识符对齐检查。当获取到DMARC记录同时进行了相关身份验证措施后,邮件接收方会进行标识符对齐检查。如果一种或多种身份验证标识符与RFC5322.From字段一直,这封邮件被认为通过了DMARC机制检查。
- 6 策略应用。利用邮件发送方DMARC记录中声明的处理策略(p字段)处理这封邮件。
6.6.3 DMARC记录的DNS查询流程。不以“v=”字段开始的DMARC记录会被丢弃。会对RFC5322.From字段中的域名进行检索,如果没有得到记录,会对其组织域进行检索。有多条DMARC记录会被视为配置失效。
6.7 Mail Receivers MAY choose to reject or quarantine email even if email passes the DMARC mechanism check.邮件接收者可以选择拒绝或隔离电子邮件,即使电子邮件通过了DMARC机制检查。
6.7 即使域所有者发布了“拒绝”策略,邮件接收者也可以选择接受DMARC机制检查失败的邮件。在完成失败邮件的交付时,建议至少添加Authentication-Results头字段.