?咨詢郵箱：
?咨詢熱線：
【Email安全性的現(xiàn)狀】
————————————————————————
人如其名，[SMTP]（Simple Mail Transfer Protocol）協(xié)議的工作原理簡(jiǎn)單+直接，但同時(shí)也存在諸多安全隱患，發(fā)件人身份合法性驗(yàn)證就是其一。
原始的[SMTP]沒(méi)有要求驗(yàn)證發(fā)件人的合法性，各路壞人利用了此紕漏制造出來(lái)大量釣魚(yú)郵件（phish）和詐騙郵件（fraud）等涉及到安全性的垃圾郵件（spam），這類spam的最大企圖就是從收件人手動(dòng)誘騙到一些有價(jià)值的信息（個(gè)人密碼，銀行卡密碼，信用卡資料等等）。
常見(jiàn)地，spammer們可以不費(fèi)吹灰之力地偽造一封發(fā)自security@paypal.com的郵件，郵件正文內(nèi)容則仿照著Paypal官方的密碼找回郵件的樣式和口吻，要求收件人輸入自己的銀行卡帳號(hào)和密碼。如果不明真相的群眾不知道這是一封釣魚(yú)郵件，則非常容易上當(dāng)受騙。
近來(lái)有統(tǒng)計(jì)數(shù)據(jù)（http://www.marketingtechblog.com/dmarc-infographic/）顯示，全球范圍內(nèi)每天仍有約1億的釣魚(yú)郵件在投遞著，每年因phishing/fraud spam而泄漏的個(gè)人密碼，銀行卡/信用卡信息等資料更是不計(jì)其數(shù)，對(duì)受害人和社會(huì)造成的影響實(shí)在太大，太惡劣！
同時(shí)各家電子郵件服務(wù)運(yùn)行商（Email Sevice Provider，如網(wǎng)易，Gmail，Hotmail等）也苦不堪言，想盡辦法希望能解決這類問(wèn)題。
后來(lái)相繼出現(xiàn)了[SENDERID]，[SPF]，[DKIM]等電郵安全協(xié)議，試圖輔助[SMTP]加強(qiáng)其安全性，解決偽造郵件的問(wèn)題。這些安全協(xié)議在一定程度上發(fā)揮了功效，攔截掉一部分釣魚(yú)郵件或詐騙郵件。無(wú)奈道高一尺魔高一丈，狡猾的spammer們的造假手段極其豐富和專業(yè)，他們很快發(fā)現(xiàn)并利用這些安全協(xié)議的不足之處，繼續(xù)制造和發(fā)送釣魚(yú)/詐騙郵件，其數(shù)量仍舊不菲！！無(wú)辜的郵箱用戶們?nèi)载叫鑾椭?/P>
【DMARC誕生】
————————————————————————
2012年1月30號(hào)，由Paypal，Google，微軟，雅虎，ReturnPath等15家行業(yè)巨頭（主要包括 金融機(jī)構(gòu)，Email服務(wù)提供商，數(shù)據(jù)分析機(jī)構(gòu)等）聯(lián)手宣布成立了新的互聯(lián)網(wǎng)聯(lián)盟dmarc.org，致力于提交并推廣一款[DMARC]新電子郵件安全協(xié)議。隨著該聯(lián)盟的日漸發(fā)展，繼而有網(wǎng)易等其他行業(yè)先行者也加入到其中。
“DMARC”是Domain-based Message Authentication, Reporting and Conformance的英文首字母縮寫(xiě)，其官網(wǎng)為 http://www.dmarc.org 。
目前該組織的官方成員有：
和其他電郵安全協(xié)議的美好初衷一樣，[DMARC]協(xié)議的主要目的是識(shí)別并攔截釣魚(yú)郵件，使釣魚(yú)郵件不再進(jìn)入用戶郵箱中（收件箱or even垃圾箱），減少郵箱用戶打開(kāi)/閱讀到釣魚(yú)郵件的可能性，從而保護(hù)用戶的帳號(hào)密碼等個(gè)人信息安全。
目前（2012-07-19）DMARC協(xié)議尚未成熟，仍處于草案（draft）階段，至今已有兩個(gè)草案版本，待其完善后將提交給IETF變成正式的RFC規(guī)范。所以嚴(yán)格地說(shuō)，目前還只有DMARC草案（DMARC1 Version），未能稱DMARC協(xié)議。
[基本原理]：[DMARC]協(xié)議基于現(xiàn)有的[DKIM]和[SPF]兩大主流電子郵件安全協(xié)議，由Mail Sender方（域名擁有者Domain Owner）在[DNS]里聲明自己采用該協(xié)議。當(dāng)Mail Receiver方（其MTA需支持DMARC協(xié)議）收到該域發(fā)送過(guò)來(lái)的郵件時(shí)，則進(jìn)行DMARC校驗(yàn)，若校驗(yàn)失敗還需發(fā)送一封report到指定[URI]（常是一個(gè)郵箱地址）。
【DMARC vs DKIM/SPF】
————————————————————————
- DKIM/SPF/DMARC都是由Mail Sender/Domain Owner聲明在DNS里，但DKIM/SPF策略單一（如只能是Reject/Pass/Etc），而DMARC策略更靈活（多種組合策略，支持百分比等）。
- DKIM/SPF 的Mail Sender和Mail Receiver雙方無(wú)任何信息交流（協(xié)議本身已無(wú)這方面的考慮和設(shè)計(jì)），而DMARC協(xié)議本身就支持Report的功能（Domain Owner除可以聲明策略，還可以聲明自己用于接收Report的[URI]）。
- DKIM/SPF 可以嚴(yán)格限制某個(gè)域名的來(lái)源合法性，但無(wú)法限制該域名的子域名，相當(dāng)于子域名無(wú)法得到保護(hù)（無(wú)法窮舉每一個(gè)子域名并為它們逐一添加SPF記錄）。
- 當(dāng)一個(gè)站點(diǎn)的郵件服務(wù)器數(shù)量多或IP更換頻繁時(shí)，這個(gè)域通常不設(shè)置SPF或僅設(shè)置為軟失敗。
- 有些允許合法使用多個(gè)域名的郵箱服務(wù)器（譬如企業(yè)郵箱提供商），所有在同一家服務(wù)商上注冊(cè)企業(yè)郵服務(wù)的域名（如A.Com和B.Com），它們的SPF記錄都指向相同的IP列表，這種情況下僅僅靠SPF是阻止不了A.Com發(fā)送一封謊稱發(fā)自B.Com的偽造郵件的！
- 當(dāng)Mail Receiver方在MX機(jī)器上依據(jù)DKIM/SPF發(fā)現(xiàn)一封驗(yàn)證失敗但僅僅只能定性為可疑（如ADSP不是Discardable 或 SPF結(jié)果不是Hard-Fail）時(shí)，這時(shí)Mail Receiver方會(huì)很困惑（這封郵件到底是不是偽造的？！），無(wú)法確定下來(lái)到底要不要拒收（因?yàn)镸ail Receiver方不知道Domain Owner方對(duì)這類可疑郵件的處理態(tài)度，到底你們是希望我拒收呢還是漏進(jìn)來(lái)呢？漏進(jìn)來(lái)是放收件箱還是垃圾箱呢？）。。。而當(dāng)這封Spam逃過(guò)其他反垃圾手段（黑名單，郵件特征過(guò)濾，郵件內(nèi)容過(guò)濾等）的檢查之后，它就能漏進(jìn)到收件人的郵箱了。而如果Domain Owner方采用DMARC協(xié)議（可以在DNS記錄里明確地聲明對(duì)這類可疑郵件的處理策略，Reject或進(jìn)垃圾箱，相當(dāng)于授權(quán)給Mail Receiver方），那Mail Receiver方就可以非常果斷地（因?yàn)槭且罁?jù)Domain Owner的授權(quán)和策略），不帶一絲猶豫（擔(dān)心誤判）地處理這類郵件了。
- Etc
由于DMARC有諸多先天優(yōu)勢(shì)，故其發(fā)起者（DMARC聯(lián)盟）稱DMARC協(xié)議的目的之一就是替換掉[ADSP]。
【誰(shuí)需要DMARC】
————————————————————————
[1] 首先，對(duì)于Mail Sender/Domain Owner一方，他們大多會(huì) 發(fā)布SPF記錄 或 使用DKIM 來(lái)保護(hù)自己的域名免遭壞人偽造，現(xiàn)在有了這么一個(gè)優(yōu)秀的DMARC協(xié)議，是不是他們都需要再發(fā)布一條DMARC記錄來(lái)加強(qiáng)保護(hù)呢？
我個(gè)人的看法是：并非所有的域名都需要DMARC。理由是：
有這么一類特別的域名，它們經(jīng)常被spammer利用于偽造各種釣魚(yú)/詐騙郵件，譬如一些 銀行/保險(xiǎn)公司等金融企業(yè)（花旗，Bank Of America，F(xiàn)DIC，etc），支付商（支付寶，Paypal，etc），知名網(wǎng)站（Facebook，LinkedIn，etc），政府網(wǎng)站等等。這種類型的域名，事實(shí)已經(jīng)證明他們的域名僅僅靠SPF/DKIM的保護(hù)是不夠的，再新增依靠DMARC更有助于降低他們的域名被利用于偽造的可能性。
而對(duì)于一些普通域名（中小型企業(yè)，不知名網(wǎng)站，對(duì)外開(kāi)放注冊(cè)的服務(wù)商（如163.com/126.com/gmail.com/hotmail.com）），偽造這類域名的釣魚(yú)郵件的利益很低，大多數(shù)spammer不屑于去偽造來(lái)自這些域名的詐騙郵件（他們通過(guò)常規(guī)手段（批量注冊(cè)或低價(jià)購(gòu)買）就可以獲得一大堆合法帳號(hào)）。對(duì)于這類域名（數(shù)量應(yīng)遠(yuǎn)多于第一類），依靠SPF/DKIM就足夠保護(hù)自己的域名了，不再需要多一個(gè)DMARC，否則效果不明顯還反倒加大了維護(hù)成本（不是絕對(duì)^_^）
[2] 其次，對(duì)于Mail Receiver這一方，他們需要DMARC嗎？
當(dāng)然需要了，無(wú)論是對(duì)專業(yè)郵箱提供商（網(wǎng)易，Gmail等），還是個(gè)人架設(shè)的郵箱服務(wù)器（單位郵箱等），他們都非常希望攔截掉所有類型的垃圾郵件和偽造郵件。所以只要條件允許，他們都會(huì)支持越多的安全檢查手段（SPF/DKIM/DMARC等）。
[3] 再次，對(duì)于普通的郵箱用戶，他們需要DMARC嗎？
普通用戶是間接受益于DMARC。他們不需要每個(gè)人都參與到DMARC中，但他們需要選擇優(yōu)秀的已支持DMARC協(xié)議的郵箱服務(wù)商（如網(wǎng)易，Gmail等）來(lái)注冊(cè)，或要求他們的管理員升級(jí)自己的郵箱服務(wù)器使之支持DMARC協(xié)議，確保自己的個(gè)人信息安全受到更好的保護(hù)。
【DMARC技術(shù)方案】
————————————————————————
[1] DMARC不用于判斷一封郵件是否為垃圾郵件，而是將郵件區(qū)分為 Aligned / Non-Aligned 兩種類型。
- Aligned 表示郵件合法性驗(yàn)證通過(guò)，是一封來(lái)源可信的郵件。
- Non-Aligned 表示郵件合法性驗(yàn)證失敗，是一封來(lái)源偽造的郵件。
[2] 首先，由Mail Sender/Domain Owner方為“_dmarc”子域創(chuàng)建一條DNS TXT記錄（簡(jiǎn)稱DMARC記錄），以此來(lái)聲明自己的域名將使用DMARC協(xié)議來(lái)保護(hù)。
如下面paypal和支付寶兩個(gè)域名的DMARC記錄實(shí)例（DMARC記錄中各個(gè)tag的含義詳見(jiàn)[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] 接下來(lái)主要就是Mail Receiver方的工作了。當(dāng)Mail Receiver方收到一封郵件，發(fā)現(xiàn)信頭的From:域已設(shè)置有DMARC記錄，則開(kāi)始做DMARC校驗(yàn)，并結(jié)合DMARC校驗(yàn)結(jié)果和DMARC記錄里的p tag or sp tag里的策略來(lái)決定下一步的投遞動(dòng)作，而忽略這封郵件的DKIM/SPF檢查結(jié)果。
[4] DMARC校驗(yàn)的核心過(guò)程：
- 從郵件信頭中提取出信頭From字段的Domain（RFC5322.From Domain），稱域名A。域名A只能有一個(gè)域名。
- 查詢DNS，得到域名A的DMARC記錄。若該域無(wú)設(shè)置DMARC記錄，忽略本次DMARC校驗(yàn)。
- 校驗(yàn)DKIM，若DKIM驗(yàn)證成功的話，則獲取DKIM簽名中的"D="字段值，稱域名B。信頭中有多個(gè)DKIM簽名驗(yàn)證通過(guò)，則域名B有多個(gè)域名。
- 校驗(yàn)SPF，若SPF驗(yàn)證成功的話，則獲取本次SMTP會(huì)話中MAIL FROM值的Domain（RFC5321.MailFrom Domain，或稱Envelope Sender Domain），稱域名C。域名C只能有一個(gè)域名。
- 校驗(yàn)DMARC，將域名B+域名C中的每一個(gè)域名和域名A進(jìn)行DMARC比較（見(jiàn)第6點(diǎn)），若當(dāng)中有至少一個(gè)域名的比較結(jié)果為一致（Aligned）則認(rèn)為DMARC檢查通過(guò)（ Aligned ），否則認(rèn)為DMARC檢查失?。?Non-Aligned ）。
- DMARC比較： Relaxed模式下，所比較的域名和域名A完全一致，或?yàn)?U>域名A的父域名，則認(rèn)為是Aligned 。 Strict模式下，所比較的域名和域名A完全一致，才認(rèn)為是Aligned。
- 一旦整個(gè)DMARC校驗(yàn)結(jié)果為 Non-Aligned 且Pct命中，收信域?qū)?zhí)行DMARC策略：None/Quarantine/Reject（見(jiàn)[5]）。
- 上述過(guò)程中有很多因素會(huì)中斷/放棄本次DMARC檢查，如提取不到域名A，域名A不存在（Mx/A/DMARC記錄不存在），DMARC記錄Pct值限制等。
- 收信域還有義務(wù)（ 非強(qiáng)制 ）發(fā)送三類Report（見(jiàn)[6]）。
[5] DMARC策略（來(lái)自DMARC記錄的p/sp標(biāo)簽），DMARC1版本只有3個(gè)可選值：
- None 僅做測(cè)試，收信方應(yīng)忽略DMARC檢查結(jié)果，進(jìn)入后續(xù)的反垃圾流程，但不影響Report的發(fā)送。
- Quarantine 收信方應(yīng)認(rèn)為這是一封可疑郵件，投遞到垃圾箱或做特殊標(biāo)記。
- Reject 收信方應(yīng)直接拒絕本次SMTP會(huì)話請(qǐng)求（550）。
[6] DMARC report（來(lái)自DMARC記錄的rf/ri/rua/ruf標(biāo)簽），DMARC1版本定義3類report：
- Failure Reports（詳見(jiàn)[DMARC] Sepc 8.2），當(dāng)郵件的SPF或DKIM驗(yàn)證失敗時(shí)發(fā)送；Report格式可為[AFRF]（基于[ARF]）或[IODEF] ；Report發(fā)送方式有 Ssl Mailto/Http Post/Https Post 三種途徑。
- Aggregate Reports（詳見(jiàn) [DMARC] Sepc 8.1），匯總某個(gè)時(shí)間區(qū)間（Ri標(biāo)簽，缺省為86400）中的所有DMARC校驗(yàn)歷史數(shù)據(jù)（成功+失?。?；Report格式為[XML]（Zip壓縮） ，其XML Schema見(jiàn)Spec Appendix E附錄；Report發(fā)送方式同 Failure Reports。
- Error Reports（詳見(jiàn) [DMARC] Sepc 12.2.4），當(dāng)發(fā)送某份Failure Reports或 Aggregate Reports失敗時(shí)，需至少嘗試發(fā)送一次 Error Reports；Report格式為[MIME]，具體內(nèi)容要求見(jiàn)Sepc；須發(fā)送往全部Mailto URIs，可選地發(fā)送給其他Listed URIs（如Http/Https）。
【一個(gè)DMARC攔截釣魚(yú)郵件的例子】
————————————————————————
下面?zhèn)卧煲环庾苑Q發(fā)自security@paypal.com的郵件，發(fā)往網(wǎng)易郵箱（以163.com為例），看163.com的MX機(jī)器是否會(huì)拒收這封郵件。
[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] 連接網(wǎng)易域163.com的一臺(tái)MX機(jī)器，發(fā)送一封paypal偽造郵件：
[panda@mysvr ~] $ telnet 220.181.12.55 25 <-- 連接163.com域的mx機(jī)器
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:
250 Mail OK
rcpt to:
250 Mail OK
data
354 End data with
from:
to:test
subject:test
<-- 本封郵件的信頭無(wú)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] 本次測(cè)試的說(shuō)明：
- 上面這封偽造郵件，域名B+域名C中沒(méi)有一個(gè)域名和域名A能匹配上，即DMARC校驗(yàn)不通過(guò)（Non-Aligned）。那么根據(jù)Paypal.Com的DMARC策略（Reject）要求，163.Com的MX服務(wù)器拒收了這封郵件（返回了550 MI:DMA）。
- 在網(wǎng)易郵箱的幫助頁(yè)面（Http://Help.163.Com/09/1224/17/5RAJ4LMH00753VB8.Html）上，可以找到網(wǎng)易對(duì)其550 MI:DMA退信原因的解釋說(shuō)明：
【小結(jié)】
————————————————————————
在[DMARC]協(xié)議出現(xiàn)之前，網(wǎng)易/Gmail/Hotmail/Yahoo等ESP廠商對(duì)詐騙郵件的有效技術(shù)手段是有限的，而spammer和phisher們則仍舊肆無(wú)忌憚地不知疲倦地制造著各種偽造郵件（利益鏈還在，技術(shù)手段又有限，悲。。）。
現(xiàn)在有了DMARC協(xié)議，如上文測(cè)試?yán)又械暮?jiǎn)單偽造郵件，甚至是用心良苦制作精良的釣魚(yú)郵件，都將被識(shí)別出來(lái)，無(wú)法再進(jìn)入到收件人的郵箱中（連垃圾箱都不會(huì)進(jìn)入）！
而對(duì)于DMARC這個(gè)新鮮事物，DMARC聯(lián)盟，電子郵件服務(wù)商，IT媒體等各方無(wú)不拍手稱好，但也已經(jīng)有部分資深I(lǐng)T專業(yè)人士指出其局限性。各方對(duì)DMARC的態(tài)度和看法，有興趣的童鞋可見(jiàn)我的另一篇博文 http://blog.163.com/pandalove@126/blog/static/980032452012320115635999/ 。
無(wú)論如何，[DMARC]確實(shí)是一個(gè)很給力的電郵安全協(xié)議，目前，DMARC聯(lián)盟中的多家ESP廠商（Gmail/Hotmail）都已經(jīng)率先支持該協(xié)議。
在中國(guó)，網(wǎng)易郵箱也是相當(dāng)給力。作為該聯(lián)盟的官方成員，2012年4月起就開(kāi)始支持[DMARC]協(xié)議，是國(guó)內(nèi)首家支持DMARC協(xié)議的互聯(lián)網(wǎng)服務(wù)提供商，竭力保護(hù)著163.com/126.com/yeah.net等網(wǎng)易郵箱用戶的個(gè)人信息安全。感謝網(wǎng)易郵箱造福我們這些普通的郵箱用戶 ^_^ 
。
隨著越來(lái)越多的廠商了解并支持[DMARC]協(xié)議，相信全球會(huì)有越來(lái)越多的Email用戶受益于此，免遭釣魚(yú)郵件和詐騙郵件之苦。