電子郵件頭全揭密

1、電子郵件頭全揭密這一部分內(nèi)容將詳細討論email頭的方方面面。主要為用戶架設郵件服務器提供理論基礎并為管理員在出現(xiàn)電子郵件垃圾騷擾時提供發(fā)現(xiàn)垃圾郵件的真正源頭。根據(jù)郵件頭的知識有助于發(fā)現(xiàn)偽造的郵件。對于希望了解郵件是如何在網(wǎng)絡中傳輸?shù)挠脩敉瑯訒袔椭?。雖然在討論中盡量有意避免如何偽造一封郵件的討論，但是在討論中的內(nèi)容可能被惡意讀者用作創(chuàng)建偽造郵件的基礎。因為要在文章中舉例說明，因此在文章中有若干虛構(gòu)的域名和隨意分配的IP地址作為示例使用。這些域名和IP都是任意任意選擇和偽造的，和Internet上真實的域名和IP沒有任何關系。二、Email的傳輸過程這部分包含一個簡單的對一個電子郵件生命周期的

2、分析。這對于理解郵件頭能為你提供哪些信息是非常重要的背景信息。從表面上看來郵件似乎是直接從發(fā)送者機器傳遞到接收者地址，但通常情況下事情并不是這樣。一個典型的電子郵件在其生命周期中至少要經(jīng)過四臺計算機。這是因為大多數(shù)企業(yè)或組織都有一個被稱為“郵件服務器”專用服務器來處理電子郵件，而這一般并不是用戶閱讀郵件的計算機。對于ISP來說，用戶從家里面的計算機撥號接入ISP網(wǎng)絡，這里將用戶家中的計算機稱為客戶機，而將ISP專門處理郵件的計算機稱為郵件服務器。當一個用戶發(fā)送郵件，他一般是在自己的計算機上編輯郵件，然后將郵件發(fā)送到ISP的郵件服務器上?？蛻魴C就此已經(jīng)完成了自己的工作，而后面的工作則由ISP的郵

3、件服務器來完成。首先ISP郵件服務器查找接收者指定的郵件服務器的IP地址，然后將郵件發(fā)送給該目的服務器?，F(xiàn)在郵件則存儲在接收者郵件服務器上等待接收者收取。當接收者從接受郵件服務器取得發(fā)送給他的郵件到自己的PC機以后，通常該郵件將被刪除。假設若干個虛構(gòu)的用戶和。zhangsan是263這個ISP的撥號用戶。使用outook express這個郵件客戶程序收發(fā)郵件。lisi是中科院的一個虛構(gòu)用戶，他使用工作站通過單位局域網(wǎng)連接進入互聯(lián)網(wǎng)。如果lisi想給zhangsan發(fā)送郵件，他在工作站(假設名字為)上編輯郵件，編輯好的信件從工作站發(fā)送到中科院的郵件服務器：。一旦信件被發(fā)送到，以后的信件發(fā)送過程

4、就和zhangsan沒有關系了。中科院的郵件服務器發(fā)現(xiàn)這是發(fā)送給的某個用戶的信件，則和263的郵件服務器-比如說是通信，并將郵件傳送給它。現(xiàn)在郵件則被存儲在之上直到zhangsan在自己的PC機上撥號連接到263網(wǎng)絡察看并收取信件，這時將存儲的郵件傳送到zhangsan的個人PC機上。在這個過程中，郵件頭將三次被加到郵件中：在編輯時由郵件客戶程序加入；當郵件傳輸?shù)綍r被加入；當從傳送到時被加入；通常來說客戶收取信件時并不添加郵件頭。下面我們就仔細看看這些郵件頭是如何產(chǎn)生的。當lisi的郵件客戶程序編輯郵件并將其發(fā)送給時，郵件內(nèi)容如下.這些內(nèi)容都是由郵件編輯程序(outlook express)添

5、加的：From: lisi (Li Si) To: zhangsan Date: Tue, Mar 18 1997 14:36:14 PST X-Mailer: Outlook Express 5.5 Subject: 中午搓飯？當郵件從傳送到后，郵件內(nèi)容變?yōu)?新添加的內(nèi)容是由)：Received: from ( 1) by (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST) From: lisi (Li Si) To: zhangsan Date: Tue, Mar 18 1997 14:36:14 PST

6、Message-Id: X-Mailer: Outlook Express 5.5 Subject: 中午搓飯?當收到信件并存儲等待zhangsan收取時，郵件內(nèi)容變?yōu)椋?新添加的內(nèi)容是由添加的)：Received: from ( 8) by (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 1997 14:39:24 -0800 (PST) Received: from ( 1) by (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (

7、PST) From: lisi (Li Si) To: zhangsan Date: Tue, Mar 18 1997 14:36:14 PST Message-Id: X-Mailer: Outlook Express 5.5 Subject: 中午搓飯?最后這封信的內(nèi)容才是zhangsan收取并閱讀的內(nèi)容。下面是對其中內(nèi)容的詳細分析：Received: from 上面的內(nèi)容表示該郵件是來自于自稱是的服務器。( 8)這句話表示該服務器的真實名字的確是，也就是說它自稱的身份是正確的，其IP地址為8。by (8.8.5/8.7.2)接收這封郵件的機器是。

8、其運行的郵件程序為sendmail，版本為8.8.5/8.7.2。with ESMTP id LAA20869接收郵件的服務器為該郵件賦有ID號LAA20869(通常該號碼是郵件服務器內(nèi)部使用的，但是管理員可以根據(jù)該ID號在log文件中查找關于該信件的相關信息，但是通常該號都是沒有意義的)。for ;該郵件是發(fā)送給地址zhangsan的?？梢钥吹皆撪]件頭沒有To：相關內(nèi)容。Tue, 18 Mar 1997 14:39:24 -0800 (PST)這次郵件傳輸發(fā)生時間為：太平洋時間Tuesday, March 18, 1997, at 14:39:24(太平洋時間，因為它比格林威治時間晚8個小時

9、，因此是"-0800")。Received: from ( 1) by (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)該郵件頭記錄了郵件是從(lisi的工作站)傳送到到郵件服務器的。傳送發(fā)生在太平洋時間14:36:17。發(fā)送計算機自稱是，其真實名經(jīng)dns查詢的確是，其IP地址為1，郵件服務器軟件為sendmail v8.8.5。該信件被郵件服務器的賦給的ID號為004A21。From: lisi (Li Si)該郵件是由lis發(fā)送的，其名字為Li Si。To: zh

10、angsan郵件目的地址為：zhangsan。Date: Tue, Mar 18 1997 14:36:14 PST郵件編輯時間為14:36:14 Pacific Standard Time on Tuesday, March 18, 1997。Message-Id: 給該郵件分配了這個號碼來標識它。它和Received頭中的SMTP機ESMTPID號是不一樣的。因為該號碼是一直伴隨整個郵件的。而其它ID則僅僅在特定的郵件服務器上的郵件傳輸階段相關聯(lián)。因此該機器ID號對其它機器來說沒有任何意義。有時候Message-ID包含了發(fā)送者郵件地址在其中。 X-Mailer: Outlook Expr

11、ess 5.5該消息是使用Outlook Express發(fā)送的，版本號為5.5。Subject: 中午搓飯?郵件標題。郵件協(xié)議這部分內(nèi)容相對其它部分來說具有更多原理性內(nèi)容，主要討論郵件是如何從一點傳輸?shù)搅硗庖稽c的細節(jié)。你不需要理解每一句話，但是熟悉這方面的內(nèi)容有助于在郵件傳輸出現(xiàn)奇怪現(xiàn)象時弄明白問題所在。由于垃圾電子郵件發(fā)送者常常故意制造一些奇怪的情況以掩飾自己的身份，因此能理解這些奇怪的現(xiàn)象對對付這些家伙是非常有用的。為了在網(wǎng)絡上傳輸數(shù)據(jù)，計算機網(wǎng)絡協(xié)議使用了稱為端口的訪問入口，你可以將端口看做是一個通道，通過它計算機可以監(jiān)聽網(wǎng)絡通信以提供服務。為了同時監(jiān)聽多個通信，計算機需要有使用端口號碼

12、標識多個不同的端口以區(qū)別這些通信。而和電子郵件傳輸相關的端口是25。正常情況讓我們重新討論上面的例子，但是這次我們僅僅關心到之間的通信過程。首先.c打開一個到的25號端口的連接，然后通過該連接發(fā)送郵件，當然在發(fā)送郵件過程中會有一些管理命令交互過程。交互中的命令和相應都或多或少的是可讀的。命令是SMTP協(xié)議規(guī)定的。如果監(jiān)聽兩者之間的通信，可能有以下內(nèi)容：(粗體部分是發(fā)出的)220 ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 1997 14:38:58 -0800 (PST) HELO 250 Hello 124.211

13、.3.78, pleased to meet you MAIL FROM: lisi 250 lisi. Sender ok RCPT TO: zhangsan 250 zhangsan. Recipient ok DATA 354 Enter mail, end with "." on a line by itself Received: from ( 1) by (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST) From: lisi (R.T. Hood) To: zhangsan D

14、ate: Tue, Mar 18 1997 14:36:14 PST Message-Id: X-Mailer: Outlook Express 5.5 Subject: 中午搓飯?Do you have time to meet for lunch?-lisi . 250 LAA20869 Message accepted for delivery QUIT 221 closing connection整個傳輸依賴于五個SMTP核心命令(當然SMTP還有一些其它命令，但是它們并不是用來完成真正的郵件傳輸)：HELO，MAIL FROM，RCPT TO，DATA和QUIT。郵件發(fā)送者HELO命

15、令用來標識自己的身份。HELO 可以被解讀為"嗨，我是"。當然這里發(fā)送者可能會撒謊，但是沒有任何機制能防止發(fā)送者說"嗨，我是"或是"嗨，我是"。然而在大多數(shù)情況下接收者都有一些方法來確認發(fā)送者的真實身份。MAIL FROM命令標識開始郵件傳輸，含義是"我有從某人發(fā)送來的郵件"，該命令后跟的地址就是所謂的“信封地址”(在后面我們將深入討論)，信封from地址不一定是發(fā)送者自己的地址。這個明顯的安全漏洞是不可避免的(因為接收者并不知道發(fā)送者機器上有哪些地址)，但是在特定的情況下這又是一個有用處的特色。RCPT TO和M

16、AIL FROM是相輔相成的。其指定郵件接收者。通過多個RCPT TO命令一個郵件可以被發(fā)送給多個接收者。(在后面的郵件中繼部分將解釋該特色可能針對某些不安全的系統(tǒng)濫用)。該命令后跟的地址稱為"envelope to"地址。其指定了郵件將被投遞給哪些用戶，而和信件中的To:指定的地址沒有關系。DATA命令指示開始實際的郵件內(nèi)容傳輸。DATA命令后輸入的任何內(nèi)容都被看做是郵件的一部分。而格式并沒有任何限制。以一個英文單詞加冒號開始的行一般被郵件程序看做是郵件頭。以英文句號符號(.)開始的行被認為是郵件內(nèi)容結(jié)束。QUIT命令終止連接。SMTP協(xié)議規(guī)范定義在RFC 821中。非正

17、常情況上面的例子有些過于簡單。上面的例子有一個假設前提：兩個組織的郵件服務器相互之間能直接訪問，而不需要經(jīng)過代理、防火墻等安全設備。這在當前Internet環(huán)境下情況往往是這樣的。但由于安全對于某些組織來說非常重要，而且網(wǎng)絡或組織可能變得越來越龐大，情況就不那么簡單了。對于具有代理型防火墻系統(tǒng)的郵件傳輸來說，區(qū)別就在于在郵件的頭中多了一次轉(zhuǎn)發(fā)過程的記錄，也就是郵件首先從發(fā)送者郵件服務器發(fā)送到 防火墻上，然后再從防火墻發(fā)送到目的郵件服務器。郵件中繼中繼對于某些具有特殊的“生命”周期的郵件頭可能和前面討論的情況完全不同：Received: from ( 2) by (8.8.

18、5) id 004B32 for ; Wed, Jul 30 1997 16:39:50 -0800 (PST) Received: from (20) by (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 1997 19:36:28 -0500 (EST) From: Anonymous Spammer To: (recipient list suppressed) Message-Id: X-Mailer: Massive Annoyance Subject: WANT TO MAKE ALOT OF MONEY?這個

19、郵件頭和以前的不同之處可能會令你認為這是一封垃圾郵件，但是這里引起你的懷疑的是"Received:"頭。從"Received:"頭看來，郵件是來自，然后從這里傳輸給，然后從這里再次傳輸?shù)阶罱K目的地址：。從"Received:"頭看來事情就是這樣的，但是中間為什么會出現(xiàn)呢？因為它和發(fā)送者和接收者都沒有直接的關系。要理解原因需要對SMTP協(xié)議進行一些了解。本質(zhì)上來講，傳輸過程是這樣的：連接的SMTP端口。告訴它“請發(fā)送這封郵件到rth。它可能是以最直接的方法來實現(xiàn)：RCPT TO: rth。到現(xiàn)在為止，接管對該郵件的處理。因為它被告知將該

20、信件轉(zhuǎn)發(fā)給其他一個域：，它就查找對于域名的郵件服務器然后將郵件轉(zhuǎn)發(fā)給。這個過程通常被稱作郵件中繼(mail relaying)。出現(xiàn)郵件中繼是由于歷史的原因，使用郵件中繼是有它的好處的。到八十年代末期，很多網(wǎng)絡中的計算機都不是直接通信來傳輸郵件。而是通過郵件路由來傳遞郵件，通過郵件路由服務器一步一步地進行郵件傳輸。這樣做是非常麻煩的，發(fā)送者往往需要手工指定一封郵件需要經(jīng)過哪些郵件路由服務器，比如需要從San Francisco發(fā)送一封郵件到New York，則需要在信封中添加如下內(nèi)容：San Francisco, Sacramento, Reno, Salt Lake City, Rock S

21、prings, Laramie, North Platte, Lincoln, Omaha, Des Moines, Cedar Rapids, Dubuque, Rockford, Chicago, Gary, Elkhart, Fort Wayne, Toledo, Cleveland, Erie, Elmira, Williamsport, Newark, New York City, Greenwich Village, #12 Desolation Row, Apt. #35, R.A. Zimmermann如果從郵局工作人員的角度來考慮，這種模型是非常有用的。在Gary的郵局只需要

22、知道如何和臨近的郵局Chicago和Elkhart通信，而無需消耗資源計算如何將郵件發(fā)送到NewYork(這時候就很清楚為什么這種模式對于郵件發(fā)送者來說非常糟糕，為什么這種方法被拋棄了)。但是這就是郵件被傳輸?shù)倪^程。因此服務器具有這樣的中繼的能力在那時是很重要的。而現(xiàn)在中繼通常被用作不道德的廣告商用來隱藏它們的原始地址，將埋怨轉(zhuǎn)嫁給被用來中繼的服務器而不是其所在ISP的技術。同樣通過中繼可以實現(xiàn)將發(fā)送信件的負載轉(zhuǎn)移到中繼服務器上，從而實現(xiàn)盜用中繼服務器的服務資源。在這里最重要的一點是理解郵件內(nèi)容是在發(fā)送點被編輯。中間的服務器只是參加了中間的傳輸工作，它并不能對發(fā)送者有任何的約束力。在上面的例子

23、中應該注意的另外一點是"Message-Id:"并不是由發(fā)送者服務器()而是中繼計算機()填寫的。這是被中繼的郵件的一個典型特性，該特性反映了發(fā)送服務器并沒有提供Message-Id的事實。信封頭上面關于SMTP的討論部分提到了“消息”頭和“信封”頭的不同之處。這種區(qū)別和導致的后果將在這里詳細地討論。簡單地說，“信封”頭實際上是由接收消息的郵件服務器產(chǎn)生的，而不是發(fā)送者服務器。按照這個定義，“Received:”頭是信封頭，而一般來說常常使用"envelope From"和"envelope To"來指示它們。"envelo

24、pe From"頭是從MAIL FROM命令得到的。如發(fā)送者郵件服務器發(fā)出命令MAILFROM: ideal，則接收者服務器則產(chǎn)生一個"envelope From"頭：> From ideal。注意這里少了一個冒號-"From"而不是"From:"。也就是說信封頭在其后沒有冒號。當然這個慣例并不是標準，但是這時一個值得注意的慣例。對應的是"envelope To"同樣來自于RCPT TO命令。如果發(fā)送者服務器發(fā)出命令RCPT TO:ideal。則"envelope To"為ide

25、al。一般來說實際上并沒有這樣一個郵件頭，它常常是包含在Received:頭中。存在信封信息的一個重要結(jié)果就是消息From:和To:變得毫無意義。From:頭是由發(fā)送者提供的，同樣To:也是由發(fā)送者提供的。因此郵件僅僅基于"envelope To"來進行轉(zhuǎn)發(fā)路由，而不是基于消息To:。為了從實際中理解這個概念，看看下面這樣的郵件傳輸：HELO 250 Hello 20, pleased to meet you MAIL FROM: 250 forged-addressgal

26、. Sender ok RCPT TO: lisi 250 lisi. Recipient OK DATA 354 Enter mail, end with "." on a line by itself From: To: (這里你的地址被隱瞞以實現(xiàn)秘密郵件轉(zhuǎn)發(fā)和騷擾) . 250 OAA08757 Message accepted for delivery下面是對應的郵件頭：> From Received: from g

27、 (20) by (8.8.5) for . From: To: (your address suppressed for stealth mailing and annoyance) 注意到"envelope From"的內(nèi)容和消息From:的內(nèi)容和消息To:的內(nèi)容都是發(fā)送者指定的，因此他們都是不可靠的。這個例子說明了為什么信封From、消息From:及消息To:在可能是偽造的郵件中是不可靠的，因為它們太容易偽造了。"Received:"

28、;頭的重要性 在上面的例子中我們已經(jīng)看到，"Received:"頭提供了詳細的消息傳輸歷史記錄，因此即使在其他郵件頭是被偽造的情況下也可能根據(jù)"Received:"頭得到某些關于該信件原始出處和傳輸過程的結(jié)論。這部分將詳細探討某些和異常的重要消息頭相關的問題，特別是如何挫敗那些常見的偽造技術。毫無疑問的是，在"Received:"頭中唯一重要且有價值的偽造防護就是由接收服務器記錄的那些信息。前面提到發(fā)送者能偽造自己的身份(通過在HELO命令中報告錯誤的身份)。幸運的是現(xiàn)代郵件服務器程序都可以檢測到這種錯誤信息并加以修正。如果服務器的真

29、實IP地址是20，發(fā)送郵件給，但是使用HELO 命令來偽造自己的身份，則對應該次傳輸?shù)?quot;Received:"可能如下所示：Received: from (20) by (8.8.5).(后面的其他信息被省略以更加清晰)。注意雖然沒有明確地說不是發(fā)送者的真實身份，但是它記錄了發(fā)送者正確的IP地址。如果某接收者認為消息頭中的是偽造者偽造的身份，他可以查看IP地址20來得到對應的正確域名是，而不是galangal.or

30、g。也就是說記錄發(fā)送服務器的IP地址提供了足夠的信息來確認可以的偽造行為。很多現(xiàn)代郵件程序?qū)嶋H上將根據(jù)IP查看對應域名的過程自動化了。(這種查看過程被稱為反向DNS解析)。如果使用這種軟件，則"Received:"頭則變?yōu)镽eceived: from ( 20) by .從這里可以清楚地看到偽造行為。這個消息頭明確地說的IP地址是20，但是卻宣稱自己的身份為。這樣的信息對于對于驗證和追蹤偽造信件是非常有用的。(因此，垃圾郵件發(fā)送者往往避免使用那些記錄發(fā)送者地址的郵件服務器進行垃圾郵件轉(zhuǎn)發(fā)。有時候它們可以找到不記錄發(fā)送者服務器，但是現(xiàn)在網(wǎng)落上這樣的服務器已經(jīng)很少了)偽造者偽造郵件的另外一個日益