DMARC全称是Domain-based Message Authentication, Reporting and Conformance,他基于现有的DKIM和SPF两大主流电子邮件安全协议,由Mail Sender方(域名拥有者Domain Owner)在DNS里声明自己采用该协议。当Mail Receiver方(其MTA需支持DMARC协议)收到该域发送过来的邮件时,则进行DMARC校验,若校验失败还需发送一封report到指定URI(常是一个邮箱地址)。本期我们将重点介绍一下邮件认证安全的主角DMARC。
01
DMARC的背景
电子邮件认证技术SPF和DKIM是十多年前开发的,目的是为了更好地保证邮件发送者的身份。这些技术的使用量稳步增加,欺诈性和欺骗性电子邮件的问题并没有减少。看起来,如果发件人使用这些技术,那么电子邮件接收者就可以轻易地将欺骗性消息与经过适当验证的消息区分开来。不幸的是,由于多种原因,这种方式并没有解决。
可以解决这些问题的唯一方式是发送者和接收者彼此分享信息。接收者向发件人提供关于他们的邮件验证基础设施的信息,而发件人告诉接收者当收到没有验证的邮件时该怎么做。PayPal在2007年开创了这种方法,并制定了一个与雅虎的系统。Mail和更高版本的Gmail以这种方式进行协作。结果是非常有效的,导致怀疑欺诈电子邮件从PayPal接受这些接收器显着减少。DMARC的目标是建立在这个发送者和接收者系统上,协作改善发送者的邮件验证实践,并使接收者能够拒绝未经验证的消息。
02
DMARC和电邮认证过程
DMARC旨在适应组织的现有入站电子邮件验证过程。它的工作方式是帮助电子邮件接收者确定声称的消息是否与接收者知道发件人的信息“一致”。如果不是的话,DMARC将包含有关如何处理“不对齐”消息的指导。例如,假设接收者部署了SPF和DKIM以及自己的垃圾邮件过滤器,流程可能如下所示:
在上面的例子中,根据DMARC的测试对比应用于ADSP在流程中应用的同一点。所有其他测试不受影响。
DMARC被设计为满足以下“高标准”要求:
需要注意的是,DMARC建立在IETF目前正在开发的DomainKeys Identified Mail(DKIM)和Sender Policy Framework(SPF)规范上。DMARC旨在通过增加对以下方面的支持来取代ADSP:
03
DNS中的DMARC资源记录
DMARC策略作为文本(TXT)资源记录(RR)发布在DNS中,并通告电子邮件接收方应该如何处理收到的不对齐邮件。
考虑一个示例DMARC TXT RR为域名“sender.dmarcdomain.com”读取:
"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com"
在这个例子中,发送者请求接收者完全拒绝所有未对齐的消息,并且以指定的聚合格式向指定的地址发送拒绝的报告。如果发送者正在测试它的配置,它可以用“quarantine”代替“reject”,告诉接收者他们不一定拒绝该消息,但考虑隔离它。
DMARC记录遵循DKIM中定义的基于DNS的密钥记录的可扩展“标签值”语法。下面的图表说明了一些可用的标签:
标记名 | 作用 | 实例 |
---|---|---|
v | 协议版本 | v=DMARC1 |
pct | 消息过滤的百分比 | pct=20 |
ruf | URI取证报告 | ruf=mailto:authfail@example.com |
rua | URI报告汇总 | rua=mailto:aggrep@example.com |
p | 组织域策略 | p=quarantine |
sp | OD子域策略 | sp=reject |
adkim | DKIM队列模式 | adkim=s |
aspf | SPF队列模式 | aspf=r注:这个图表中的例子仅供说明 |
DMARC的设计基于全球最大的部署SPF和DKIM的邮件发送器和接收器的实际经验。考虑到了这样一个事实,即组织几乎不可能将业务环境切换到生产。有许多内置的方法可以“调节”DMARC处理,从而使各方都能够随着时间的推移而全面部署。