【Email安全性的现状】

————————————————————————

    人如其名，[SMTP]（Simple Mail Transfer Protocol）协议的工作原理简单+直接，但同时也存在诸多安全隐患，发件人身份合法性验证就是其一。

    原始的[SMTP]没有要求验证发件人的合法性，各路坏人利用了此纰漏制造出来大量钓鱼邮件（phish）和诈骗邮件（fraud）等涉及到安全性的垃圾邮件（spam），这类spam的最大企图就是从收件人手动诱骗到一些有价值的信息（个人密码，银行卡密码，信用卡资料等等）。

    常见地，spammer们可以不费吹灰之力地伪造一封发自security@paypal.com的邮件，邮件正文内容则仿照着Paypal官方的密码找回邮件的样式和口吻，要求收件人输入自己的银行卡帐号和密码。如果不明真相的群众不知道这是一封钓鱼邮件，则非常容易上当受骗。

    近来有统计数据（http://www.marketingtechblog.com/dmarc-infographic/）显示，全球范围内每天仍有约1亿的钓鱼邮件在投递着，每年因phishing/fraud spam而泄漏的个人密码，银行卡/信用卡信息等资料更是不计其数，对受害人和社会造成的影响实在太大，太恶劣！

    同时各家电子邮件服务运行商（Email Sevice Provider，如网易，Gmail，Hotmail等）也苦不堪言，想尽办法希望能解决这类问题。

    后来相继出现了[SENDERID]，[SPF]，[DKIM]等电邮安全协议，试图辅助[SMTP]加强其安全性，解决伪造邮件的问题。这些安全协议在一定程度上发挥了功效，拦截掉一部分钓鱼邮件或诈骗邮件。无奈道高一尺魔高一丈，狡猾的spammer们的造假手段极其丰富和专业，他们很快发现并利用这些安全协议的不足之处，继续制造和发送钓鱼/诈骗邮件，其数量仍旧不菲！！无辜的邮箱用户们仍亟需帮助！

【DMARC诞生】

————————————————————————

    2012年1月30号，由Paypal，Google，微软，雅虎，ReturnPath等15家行业巨头（主要包括 金融机构，Email服务提供商，数据分析机构等）联手宣布成立了新的互联网联盟dmarc.org，致力于提交并推广一款[DMARC]新电子邮件安全协议。随着该联盟的日渐发展，继而有网易等其他行业先行者也加入到其中。

    “DMARC”是Domain-based Message Authentication, Reporting and Conformance的英文首字母缩写，其官网为 http://www.dmarc.org 。

    目前该组织的官方成员有：

    和其他电邮安全协议的美好初衷一样，[DMARC]协议的主要目的是识别并拦截钓鱼邮件，使钓鱼邮件不再进入用户邮箱中（收件箱or even垃圾箱），减少邮箱用户打开/阅读到钓鱼邮件的可能性，从而保护用户的帐号密码等个人信息安全。

    目前（2012-07-19）DMARC协议尚未成熟，仍处于草案（draft）阶段，至今已有两个草案版本，待其完善后将提交给IETF变成正式的RFC规范。所以严格地说，目前还只有DMARC草案（DMARC1 Version），未能称DMARC协议。

    [基本原理]：[DMARC]协议基于现有的[DKIM]和[SPF]两大主流电子邮件安全协议，由Mail Sender方（域名拥有者Domain Owner）在[DNS]里声明自己采用该协议。当Mail Receiver方（其MTA需支持DMARC协议）收到该域发送过来的邮件时，则进行DMARC校验，若校验失败还需发送一封report到指定[URI]（常是一个邮箱地址）。

【DMARC vs DKIM/SPF】

————————————————————————

1. DKIM/SPF/DMARC都是由Mail Sender/Domain Owner声明在DNS里，但DKIM/SPF策略单一（如只能是Reject/Pass/Etc），而DMARC策略更灵活（多种组合策略，支持百分比等）。
2. DKIM/SPF 的Mail Sender和Mail Receiver双方无任何信息交流（协议本身已无这方面的考虑和设计），而DMARC协议本身就支持Report的功能（Domain Owner除可以声明策略，还可以声明自己用于接收Report的[URI]）。
3. DKIM/SPF 可以严格限制某个域名的来源合法性，但无法限制该域名的子域名，相当于子域名无法得到保护（无法穷举每一个子域名并为它们逐一添加SPF记录）。
4. 当一个站点的邮件服务器数量多或IP更换频繁时，这个域通常不设置SPF或仅设置为软失败。
5. 有些允许合法使用多个域名的邮箱服务器（譬如企业邮箱提供商），所有在同一家服务商上注册企业邮服务的域名（如A.Com和B.Com），它们的SPF记录都指向相同的IP列表，这种情况下仅仅靠SPF是阻止不了A.Com发送一封谎称发自B.Com的伪造邮件的！
6. 当Mail Receiver方在MX机器上依据DKIM/SPF发现一封验证失败但仅仅只能定性为可疑（如ADSP不是Discardable 或 SPF结果不是Hard-Fail）时，这时Mail Receiver方会很困惑（这封邮件到底是不是伪造的？！），无法确定下来到底要不要拒收（因为Mail Receiver方不知道Domain Owner方对这类可疑邮件的处理态度，到底你们是希望我拒收呢还是漏进来呢？漏进来是放收件箱还是垃圾箱呢？）。。。而当这封Spam逃过其他反垃圾手段（黑名单，邮件特征过滤，邮件内容过滤等）的检查之后，它就能漏进到收件人的邮箱了。而如果Domain Owner方采用DMARC协议（可以在DNS记录里明确地声明对这类可疑邮件的处理策略，Reject或进垃圾箱，相当于授权给Mail Receiver方），那Mail Receiver方就可以非常果断地（因为是依据Domain Owner的授权和策略），不带一丝犹豫（担心误判）地处理这类邮件了。
7. Etc

由于DMARC有诸多先天优势，故其发起者（DMARC联盟）称DMARC协议的目的之一就是替换掉[ADSP]。

【谁需要DMARC】

————————————————————————

[1]  首先，对于Mail Sender/Domain Owner一方，他们大多会 发布SPF记录 或 使用DKIM 来保护自己的域名免遭坏人伪造，现在有了这么一个优秀的DMARC协议，是不是他们都需要再发布一条DMARC记录来加强保护呢？

我个人的看法是：并非所有的域名都需要DMARC。理由是：

有这么一类特别的域名，它们经常被spammer利用于伪造各种钓鱼/诈骗邮件，譬如一些 银行/保险公司等金融企业（花旗，Bank Of America，FDIC，etc），支付商（支付宝，Paypal，etc），知名网站（Facebook，LinkedIn，etc），政府网站等等。这种类型的域名，事实已经证明他们的域名仅仅靠SPF/DKIM的保护是不够的，再新增依靠DMARC更有助于降低他们的域名被利用于伪造的可能性。

而对于一些普通域名（中小型企业，不知名网站，对外开放注册的服务商（如163.com/126.com/gmail.com/hotmail.com）），伪造这类域名的钓鱼邮件的利益很低，大多数spammer不屑于去伪造来自这些域名的诈骗邮件（他们通过常规手段（批量注册或低价购买）就可以获得一大堆合法帐号）。对于这类域名（数量应远多于第一类），依靠SPF/DKIM就足够保护自己的域名了，不再需要多一个DMARC，否则效果不明显还反倒加大了维护成本（不是绝对^_^）

[2]  其次，对于Mail Receiver这一方，他们需要DMARC吗？

当然需要了，无论是对专业邮箱提供商（网易，Gmail等），还是个人架设的邮箱服务器（单位邮箱等），他们都非常希望拦截掉所有类型的垃圾邮件和伪造邮件。所以只要条件允许，他们都会支持越多的安全检查手段（SPF/DKIM/DMARC等）。

[3]  再次，对于普通的邮箱用户，他们需要DMARC吗？

普通用户是间接受益于DMARC。他们不需要每个人都参与到DMARC中，但他们需要选择优秀的已支持DMARC协议的邮箱服务商（如网易，Gmail等）来注册，或要求他们的管理员升级自己的邮箱服务器使之支持DMARC协议，确保自己的个人信息安全受到更好的保护。

【DMARC技术方案】

————————————————————————

[1]  DMARC不用于判断一封邮件是否为垃圾邮件，而是将邮件区分为 Aligned / Non-Aligned 两种类型。

• Aligned 表示邮件合法性验证通过，是一封来源可信的邮件。
• Non-Aligned 表示邮件合法性验证失败，是一封来源伪造的邮件。

[2]  首先，由Mail Sender/Domain Owner方为“_dmarc”子域创建一条DNS TXT记录（简称DMARC记录），以此来声明自己的域名将使用DMARC协议来保护。

如下面paypal和支付宝两个域名的DMARC记录实例（DMARC记录中各个tag的含义详见[DMARC] spec 6.1）：

[panda@mysvr ~] $ dig +short txt _dmarc.paypal.com

"v=DMARC1\\; p=reject\\; rua=mailto:DL-PP-DK-Reports@ebay.com\\; ruf=mailto:dk@bounce.paypal.com\\;"

[panda@mysvr ~] $ dig +short txt _dmarc.alipay.com

"v=DMARC1\\; p=none\\; rua=mailto:dmarc@alipay.com\\; ruf=mailto:dmarc@alipay.com"

[panda@mysvr ~] $

[3]  接下来主要就是Mail Receiver方的工作了。当Mail Receiver方收到一封邮件，发现信头的From:域已设置有DMARC记录，则开始做DMARC校验，并结合DMARC校验结果和DMARC记录里的p tag or sp tag里的策略来决定下一步的投递动作，而忽略这封邮件的DKIM/SPF检查结果。

[4]  DMARC校验的核心过程：

1. 从邮件信头中提取出信头From字段的Domain（RFC5322.From Domain），称域名A。域名A只能有一个域名。
2. 查询DNS，得到域名A的DMARC记录。若该域无设置DMARC记录，忽略本次DMARC校验。
3. 校验DKIM，若DKIM验证成功的话，则获取DKIM签名中的"D="字段值，称域名B。信头中有多个DKIM签名验证通过，则域名B有多个域名。
4. 校验SPF，若SPF验证成功的话，则获取本次SMTP会话中MAIL FROM值的Domain（RFC5321.MailFrom Domain，或称Envelope Sender Domain），称域名C。域名C只能有一个域名。
5. 校验DMARC，将域名B+域名C中的每一个域名和域名A进行DMARC比较（见第6点），若当中有至少一个域名的比较结果为一致（Aligned）则认为DMARC检查通过（ Aligned ），否则认为DMARC检查失败（ Non-Aligned ）。
6. DMARC比较： Relaxed模式下，所比较的域名和域名A完全一致，或为域名A的父域名，则认为是Aligned 。 Strict模式下，所比较的域名和域名A完全一致，才认为是Aligned。
7. 一旦整个DMARC校验结果为 Non-Aligned 且Pct命中，收信域将执行DMARC策略：None/Quarantine/Reject（见[5]）。
8. 上述过程中有很多因素会中断/放弃本次DMARC检查，如提取不到域名A，域名A不存在（Mx/A/DMARC记录不存在），DMARC记录Pct值限制等。
9. 收信域还有义务（ 非强制 ）发送三类Report（见[6]）。

[5]  DMARC策略（来自DMARC记录的p/sp标签），DMARC1版本只有3个可选值：

• None 仅做测试，收信方应忽略DMARC检查结果，进入后续的反垃圾流程，但不影响Report的发送。
• Quarantine 收信方应认为这是一封可疑邮件，投递到垃圾箱或做特殊标记。
• Reject 收信方应直接拒绝本次SMTP会话请求（550）。

[6]  DMARC report（来自DMARC记录的rf/ri/rua/ruf标签），DMARC1版本定义3类report：

• Failure Reports（详见[DMARC] Sepc 8.2），当邮件的SPF或DKIM验证失败时发送；Report格式可为[AFRF]（基于[ARF]）或[IODEF] ；Report发送方式有 Ssl Mailto/Http Post/Https Post 三种途径。
• Aggregate Reports（详见 [DMARC] Sepc 8.1），汇总某个时间区间（Ri标签，缺省为86400）中的所有DMARC校验历史数据（成功+失败）；Report格式为[XML]（Zip压缩） ，其XML Schema见Spec  Appendix E附录；Report发送方式同 Failure Reports。
• Error Reports（详见 [DMARC] Sepc 12.2.4），当发送某份Failure Reports或 Aggregate Reports失败时，需至少尝试发送一次 Error Reports；Report格式为[MIME]，具体内容要求见Sepc；须发送往全部Mailto URIs，可选地发送给其他Listed URIs（如Http/Https）。

【一个DMARC拦截钓鱼邮件的例子】

————————————————————————

    下面伪造一封自称发自security@paypal.com的邮件，发往网易邮箱（以163.com为例），看163.com的MX机器是否会拒收这封邮件。

[1]  首先查询一下paypal.com的DMARC记录：

[panda@mysvr ~] $ dig +short txt _dmarc.paypal.com

"v=DMARC1\\; p=reject\\; rua=mailto:DL-PP-DK-Reports@ebay.com\\; ruf=mailto:dk@bounce.paypal.com\\;"

[panda@mysvr ~] $

[2]  连接网易域163.com的一台MX机器，发送一封paypal伪造邮件：

[panda@mysvr ~] $ telnet 220.181.12.55 25     <-- 连接163.com域的mx机器

Trying 220.181.12.55...

Connected to 163.mxmail.netease.com (220.181.12.55).

Escape character is '^]'.

220 163.com Anti-spam GT for Coremail System (163com[20111010])

helo aa.com

250 OK

mail from:  <-- 自称来自aa@aa.com，那么aa.com将作为本次会话的域名C（RFC5321.MailFrom domain）。

250 Mail OK

rcpt to:

250 Mail OK

data

354 End data with .

from:  <-- 伪造称自己是security@paypal.com，那么paypal.com将作为本次会话的域名A（RFC5322.From domain）。

to:test

subject:test

<-- 本封邮件的信头无DKIM签名，那么域名B将为空（"d" tag of DKIM-Signature）。

test

.

550 MI:DMA mx30, UMCowEA5KktUto9Pd5j7AQ--.2229S2 1334818442 http://mail.163.com/help/help_spam_16.htm?ip=220.181.15.243&hostid=mx30&time=1334818442  <-- 163.com返回550 MI:DMA并拒收了这封邮件。

quit

221 Bye

Connection closed by foreign host.

[panda@mysvr ~] $

[3]  本次测试的说明：

• 上面这封伪造邮件，域名B+域名C中没有一个域名和域名A能匹配上，即DMARC校验不通过（Non-Aligned）。那么根据Paypal.Com的DMARC策略（Reject）要求，163.Com的MX服务器拒收了这封邮件（返回了550 MI:DMA）。
• 在网易邮箱的帮助页面（Http://Help.163.Com/09/1224/17/5RAJ4LMH00753VB8.Html）上，可以找到网易对其550 MI:DMA退信原因的解释说明：

【小结】

————————————————————————

    在[DMARC]协议出现之前，网易/Gmail/Hotmail/Yahoo等ESP厂商对诈骗邮件的有效技术手段是有限的，而spammer和phisher们则仍旧肆无忌惮地不知疲倦地制造着各种伪造邮件（利益链还在，技术手段又有限，悲。。）。

    现在有了DMARC协议，如上文测试例子中的简单伪造邮件，甚至是用心良苦制作精良的钓鱼邮件，都将被识别出来，无法再进入到收件人的邮箱中（连垃圾箱都不会进入）！

    而对于DMARC这个新鲜事物，DMARC联盟，电子邮件服务商，IT媒体等各方无不拍手称好，但也已经有部分资深IT专业人士指出其局限性。各方对DMARC的态度和看法，有兴趣的童鞋可见我的另一篇博文 http://blog.163.com/pandalove@126/blog/static/980032452012320115635999/ 。

    无论如何，[DMARC]确实是一个很给力的电邮安全协议，目前，DMARC联盟中的多家ESP厂商（Gmail/Hotmail）都已经率先支持该协议。

    在中国，网易邮箱也是相当给力。作为该联盟的官方成员，2012年4月起就开始支持[DMARC]协议，是国内首家支持DMARC协议的互联网服务提供商，竭力保护着163.com/126.com/yeah.net等网易邮箱用户的个人信息安全。感谢网易邮箱造福我们这些普通的邮箱用户 ^_^  。

    随着越来越多的厂商了解并支持[DMARC]协议，相信全球会有越来越多的Email用户受益于此，免遭钓鱼邮件和诈骗邮件之苦。