Email郵件頭揭密(二)
發表于:2007-07-02來源:作者:點擊數:
標簽:
五、信封頭 上面關于SMTP的討論部分提到了“消息”頭和“信封”頭的不同之處。這種區別和導致的后果將在這里詳細地討論。 簡單地說,“信封”頭實際上是由接收消息的郵件服務器產生的,而不是發送者服務器。按照這個定義,“Received:”頭是信封頭,而一般來
五、信封頭
上面關于SMTP的討論部分提到了“消息”頭和“信封”頭的不同之處。這種區別和導致的后果將在這里詳細地討論。
簡單地說,“信封”頭實際上是由接收消息的郵件服務器產生的,而不是發送者服務器。按照這個定義,“Received:”頭是信封頭,而一般來說常常使用"envelope From"和"envelope To"來指示它們。
"envelope From"頭是從MAIL FROM命令得到的。如發送者郵件服務器發出命令MAIL FROM: ideal@
linuxaid.com.cn,則接收者服務器則產生一個"envelope From"頭:>From ideal@linuxaid.com.cn。
注意這里少了一個冒號—"From"而不是"From:"。也就是說信封頭在其后沒有冒號。當然這個慣例并不是標準,但是這時一個值得注意的慣例。
對應的是"envelope To"同樣來自于RCPT TO命令。如果發送者服務器發出命令RCPT TO: ideal@btamail
.net.cn。則"envelope To"為ideal@btamail.net.cn。一般來說實際上并沒有這樣一個郵件頭,它常常是包含在Received:頭中。
存在信封信息的一個重要結果就是消息From:和To:變得毫無意義。From:頭是由發送者提供的,同樣To:也是由發送者提供的。因此郵件僅僅基于"envelope To"來進行轉發路由,而不是基于消息To:。
為了從實際中理解這個概念,看看下面這樣的郵件傳輸:
HELO galangal.org
250 mail.zky.ac.cn Hello linuxaid.com.cn [202.99.11.120], pleased to meet you
MAIL FROM: forged-address@galangal.org
250 forged-address@galangal.org... Sender ok
RCPT TO: lisi@zky.ac.cn
250 lisi@zky.ac.cn... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@lemongrass.org
To: (這里你的地址被隱瞞以實現秘密郵件轉發和騷擾)
.
250 OAA08757 Message a
clearcase/" target="_blank" >ccepted for delivery
下面是對應的郵件頭:
>From forged-address@galangal.org
Received: from galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.5) for <tmh@zky.ac.cn>...
From: another-forged-address@lemongrass.org
To: (這里你的地址被隱瞞以實現秘密郵件轉發和騷擾)
注意到"envelope From"的內容和消息From:的內容和消息To:的內容都是發送者指定的,因此他們都是不可靠的。這個例子說明了為什么信封From、消息From:及消息To:在可能是偽造的郵件中是不可靠的,因為它們太容易偽造了。
"Received:"頭的重要性
在上面的例子中我們已經看到,"Received:"頭提供了詳細的消息傳輸歷史記錄,因此即使在其他郵件頭是被偽造的情況下也可能根據"Received:"頭得到某些關于該信件原始出處和傳輸過程的結論。這部分將詳細探討某些和異常的重要消息頭相關的問題,特別是如何挫敗那些常見的偽造技術。
毫無疑問的是,在"Received:"頭中唯一重要且有價值的偽造防護就是由接收服務器記錄的那些信息。前面提到發送者能偽造自己的身份( 通過在HELO命令中報告錯誤的身份)。幸運的是現代郵件服務器程序都可以檢測到這種錯誤信息并加以修正。
如果服務器linuxaid.com.cn的真實IP地址是202.99.11.120,發送郵件給mail.zky.ac.cn,但是使用HELO galangal.org命令來偽造自己的身份,則對應該次傳輸的"Received:"可能如下所示:
Received: from galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.5)...
(后面的其他信息被省略以更加清晰)。注意雖然zky.ac.cn沒有明確地說galangal.org不是發送者的真實身份,但是它記錄了發送者正確的IP地址。如果某接收者認為消息頭中的galangal.org是偽造者偽造的身份,他可以查看IP地址202.99.11.120來得到對應的正確域名是linuxaid.com.cn,而不是galangal.org。也就是說記錄發送服務器的IP地址提供了足夠的信息來確認可以的偽造行為。
很多現代郵件程序實際上將根據IP查看對應域名的過程自動化了。(這種查看過程被稱為反向DNS解析)。如果mail.zky.ac.cn使用這種軟件,則"Received:"頭則變為
Received: from galangal.org (linuxaid.com.cn [202.99.11.120]) by mail.zky.ac.cn...
從這里可以清楚地看到偽造行為。這個消息頭明確地說linuxaid.com.cn的IP地址是202.99.11.120,但是卻宣稱自己的身份為galangal.org。這樣的信息對于對于驗證和追蹤偽造信件是非常有用的。(因此,垃圾郵件發送者往往避免使用那些記錄發送者地址的郵件服務器進行垃圾郵件轉發。有時候它們可以找到不記錄發送者服務器,但是現在
網絡上這樣的服務器已經很少了)
偽造者偽造郵件的另外一個日益常見的技巧是在發送垃圾郵件以前添加偽造的"Received:"頭。這意味著從linuxaid.com.cn發送的假設的郵件的"Received:"頭的內容可能為:
Received: from galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.5)...
Received: from nowhere by fictitious-site (8.8.3/8.7.2)...
Received: No Information Here, Go Away!
很明顯,最后兩行內容完全是毫無疑義的,是由發送者編寫并在發送以前附在郵件中的。由于一旦郵件離開linuxaid.com.cn,發送者對郵件完全失去了控制。而且新的"Received:"頭總是出現添加在消息的頭部,因此偽造的"Received:"頭總是出現在"Received:"頭列表的尾部。這意味著任何人從頭到尾讀取"Received:"頭列表,追蹤郵件傳輸歷史,都能
安全地剔除在第一個偽造頭以后的內容。即使"Received:"頭看上去似乎是真實的,但是實際上都是偽造的。
當然,發送者不一定會用明顯的垃圾信息來迷惑你,一個處心積慮的偽造者可能創建如下所示的看似真實的"Received:"頭列表:
Received: from galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.5)...
Received: from lemongrass.org by galangal.org (8.7.3/8.5.1)...
Received: from graprao.com by lemongrass.org (8.6.4)...
這里泄漏偽造問題的唯一地方是第一個"Received:"頭中的galangal.org的IP地址。如果偽造者這里填寫了lemongrass.org和graprao.com 的真實IP地址,則這樣的偽造偽造仍然非常難以檢測。但是第一個"Received:"頭中的域名和IP的不匹配仍然揭露了消息是偽造的,并且該郵件是有網絡中地址為202.99.11.120的服務器注入到網絡中。然而大多數郵件頭偽造者一般都沒有這么狡猾,一般額外添加的"Received:"頭一般都很明顯地是偽造的垃圾。
原文轉自:http://www.kjueaiud.com