電子郵件頭全揭密

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

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

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

4、就和zhangsan沒(méi)有關(guān)系了。中科院的郵件服務(wù)器發(fā)現(xiàn)這是發(fā)送給的某個(gè)用戶的信件，則和263的郵件服務(wù)器-比如說(shuō)是通信，并將郵件傳送給它?，F(xiàn)在郵件則被存儲(chǔ)在之上直到zhangsan在自己的PC機(jī)上撥號(hào)連接到263網(wǎng)絡(luò)察看并收取信件，這時(shí)將存儲(chǔ)的郵件傳送到zhangsan的個(gè)人PC機(jī)上。在這個(gè)過(guò)程中，郵件頭將三次被加到郵件中：在編輯時(shí)由郵件客戶程序加入；當(dāng)郵件傳輸?shù)綍r(shí)被加入；當(dāng)從傳送到時(shí)被加入；通常來(lái)說(shuō)客戶收取信件時(shí)并不添加郵件頭。下面我們就仔細(xì)看看這些郵件頭是如何產(chǎn)生的。當(dāng)lisi的郵件客戶程序編輯郵件并將其發(fā)送給時(shí)，郵件內(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: 中午搓飯？當(dāng)郵件從傳送到后，郵件內(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: 中午搓飯?當(dāng)收到信件并存儲(chǔ)等待zhangsan收取時(shí)，郵件內(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)容。下面是對(duì)其中內(nèi)容的詳細(xì)分析：Received: from 上面的內(nèi)容表示該郵件是來(lái)自于自稱(chēng)是的服務(wù)器。( 8)這句話表示該服務(wù)器的真實(shí)名字的確是，也就是說(shuō)它自稱(chēng)的身份是正確的，其IP地址為8。by (8.8.5/8.7.2)接收這封郵件的機(jī)器是。

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

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

10、為：zhangsan。Date: Tue, Mar 18 1997 14:36:14 PST郵件編輯時(shí)間為14:36:14 Pacific Standard Time on Tuesday, March 18, 1997。Message-Id: 給該郵件分配了這個(gè)號(hào)碼來(lái)標(biāo)識(shí)它。它和Received頭中的SMTP機(jī)ESMTPID號(hào)是不一樣的。因?yàn)樵撎?hào)碼是一直伴隨整個(gè)郵件的。而其它ID則僅僅在特定的郵件服務(wù)器上的郵件傳輸階段相關(guān)聯(lián)。因此該機(jī)器ID號(hào)對(duì)其它機(jī)器來(lái)說(shuō)沒(méi)有任何意義。有時(shí)候Message-ID包含了發(fā)送者郵件地址在其中。 X-Mailer: Outlook Express 5.5該消息是使

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

12、這些通信。而和電子郵件傳輸相關(guān)的端口是25。正常情況讓我們重新討論上面的例子，但是這次我們僅僅關(guān)心到之間的通信過(guò)程。首先.c打開(kāi)一個(gè)到的25號(hào)端口的連接，然后通過(guò)該連接發(fā)送郵件，當(dāng)然在發(fā)送郵件過(guò)程中會(huì)有一些管理命令交互過(guò)程。交互中的命令和相應(yīng)都或多或少的是可讀的。命令是SMTP協(xié)議規(guī)定的。如果監(jiān)聽(tīng)兩者之間的通信，可能有以下內(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 8, pleas

13、ed 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 Date: Tue, Mar 18 1997 14

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整個(gè)傳輸依賴于五個(gè)SMTP核心命令(當(dāng)然SMTP還有一些其它命令，但是它們并不是用來(lái)完成真正的郵件傳輸)：HELO，MAIL FROM，RCPT TO，DATA和QUIT。郵件發(fā)送者HELO命令用來(lái)標(biāo)識(shí)自己的身份。HELO 可以被解讀為嗨，

15、我是。當(dāng)然這里發(fā)送者可能會(huì)撒謊，但是沒(méi)有任何機(jī)制能防止發(fā)送者說(shuō)嗨，我是或是嗨，我是。然而在大多數(shù)情況下接收者都有一些方法來(lái)確認(rèn)發(fā)送者的真實(shí)身份。MAIL FROM命令標(biāo)識(shí)開(kāi)始郵件傳輸，含義是我有從某人發(fā)送來(lái)的郵件，該命令后跟的地址就是所謂的“信封地址”(在后面我們將深入討論)，信封from地址不一定是發(fā)送者自己的地址。這個(gè)明顯的安全漏洞是不可避免的(因?yàn)榻邮照卟⒉恢腊l(fā)送者機(jī)器上有哪些地址)，但是在特定的情況下這又是一個(gè)有用處的特色。RCPT TO和MAIL FROM是相輔相成的。其指定郵件接收者。通過(guò)多個(gè)RCPT TO命令一個(gè)郵件可以被發(fā)送給多個(gè)接收者。(在后面的郵件中繼部分將解釋該特色可能

16、針對(duì)某些不安全的系統(tǒng)濫用)。該命令后跟的地址稱(chēng)為envelope to地址。其指定了郵件將被投遞給哪些用戶，而和信件中的To:指定的地址沒(méi)有關(guān)系。DATA命令指示開(kāi)始實(shí)際的郵件內(nèi)容傳輸。DATA命令后輸入的任何內(nèi)容都被看做是郵件的一部分。而格式并沒(méi)有任何限制。以一個(gè)英文單詞加冒號(hào)開(kāi)始的行一般被郵件程序看做是郵件頭。以英文句號(hào)符號(hào)(.)開(kāi)始的行被認(rèn)為是郵件內(nèi)容結(jié)束。QUIT命令終止連接。SMTP協(xié)議規(guī)范定義在RFC 821中。非正常情況上面的例子有些過(guò)于簡(jiǎn)單。上面的例子有一個(gè)假設(shè)前提：兩個(gè)組織的郵件服務(wù)器相互之間能直接訪問(wèn)，而不需要經(jīng)過(guò)代理、防火墻等安全設(shè)備。這在當(dāng)前Internet環(huán)境下情況往

17、往是這樣的。但由于安全對(duì)于某些組織來(lái)說(shuō)非常重要，而且網(wǎng)絡(luò)或組織可能變得越來(lái)越龐大，情況就不那么簡(jiǎn)單了。對(duì)于具有代理型防火墻系統(tǒng)的郵件傳輸來(lái)說(shuō)，區(qū)別就在于在郵件的頭中多了一次轉(zhuǎn)發(fā)過(guò)程的記錄，也就是郵件首先從發(fā)送者郵件服務(wù)器發(fā)送到 防火墻上，然后再?gòu)姆阑饓Πl(fā)送到目的郵件服務(wù)器。郵件中繼中繼對(duì)于某些具有特殊的“生命”周期的郵件頭可能和前面討論的情況完全不同：Received: from ( 2) by (8.8.5) id 004B32 for ; Wed, Jul 30 1997 16:39:50 -0800 (PST) Received: from (

18、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?這個(gè)郵件頭和以前的不同之處可能會(huì)令你認(rèn)為這是一封垃圾郵件，但是這里引起你的懷疑的是Received:頭。從Received:頭看來(lái)，郵件是來(lái)自，然后從這里傳輸給，然后從這里

19、再次傳輸?shù)阶罱K目的地址：。從Received:頭看來(lái)事情就是這樣的，但是中間為什么會(huì)出現(xiàn)呢？因?yàn)樗桶l(fā)送者和接收者都沒(méi)有直接的關(guān)系。要理解原因需要對(duì)SMTP協(xié)議進(jìn)行一些了解。本質(zhì)上來(lái)講，傳輸過(guò)程是這樣的：連接的SMTP端口。告訴它“請(qǐng)發(fā)送這封郵件到rth。它可能是以最直接的方法來(lái)實(shí)現(xiàn)：RCPT TO: rth。到現(xiàn)在為止，接管對(duì)該郵件的處理。因?yàn)樗桓嬷獙⒃撔偶D(zhuǎn)發(fā)給其他一個(gè)域：，它就查找對(duì)于域名的郵件服務(wù)器然后將郵件轉(zhuǎn)發(fā)給。這個(gè)過(guò)程通常被稱(chēng)作郵件中繼(mail relaying)。出現(xiàn)郵件中繼是由于歷史的原因，使用郵件中繼是有它的好處的。到八十年代末期，很多網(wǎng)絡(luò)中的計(jì)算機(jī)都不是直接通信來(lái)傳輸

20、郵件。而是通過(guò)郵件路由來(lái)傳遞郵件，通過(guò)郵件路由服務(wù)器一步一步地進(jìn)行郵件傳輸。這樣做是非常麻煩的，發(fā)送者往往需要手工指定一封郵件需要經(jīng)過(guò)哪些郵件路由服務(wù)器，比如需要從San Francisco發(fā)送一封郵件到New York，則需要在信封中添加如下內(nèi)容：San Francisco, Sacramento, Reno, Salt Lake City, Rock Springs, Laramie, North Platte, Lincoln, Omaha, Des Moines, Cedar Rapids, Dubuque, Rockford, Chicago, Gary, Elkhart, Fort

21、 Wayne, Toledo, Cleveland, Erie, Elmira, Williamsport, Newark, New York City, Greenwich Village, #12 Desolation Row, Apt. #35, R.A. Zimmermann如果從郵局工作人員的角度來(lái)考慮，這種模型是非常有用的。在Gary的郵局只需要知道如何和臨近的郵局Chicago和Elkhart通信，而無(wú)需消耗資源計(jì)算如何將郵件發(fā)送到NewYork(這時(shí)候就很清楚為什么這種模式對(duì)于郵件發(fā)送者來(lái)說(shuō)非常糟糕，為什么這種方法被拋棄了)。但是這就是郵件被傳輸?shù)倪^(guò)程。因此服務(wù)器具有這樣的中繼

22、的能力在那時(shí)是很重要的。而現(xiàn)在中繼通常被用作不道德的廣告商用來(lái)隱藏它們的原始地址，將埋怨轉(zhuǎn)嫁給被用來(lái)中繼的服務(wù)器而不是其所在ISP的技術(shù)。同樣通過(guò)中繼可以實(shí)現(xiàn)將發(fā)送信件的負(fù)載轉(zhuǎn)移到中繼服務(wù)器上，從而實(shí)現(xiàn)盜用中繼服務(wù)器的服務(wù)資源。在這里最重要的一點(diǎn)是理解郵件內(nèi)容是在發(fā)送點(diǎn)被編輯。中間的服務(wù)器只是參加了中間的傳輸工作，它并不能對(duì)發(fā)送者有任何的約束力。在上面的例子中應(yīng)該注意的另外一點(diǎn)是Message-Id:并不是由發(fā)送者服務(wù)器()而是中繼計(jì)算機(jī)()填寫(xiě)的。這是被中繼的郵件的一個(gè)典型特性，該特性反映了發(fā)送服務(wù)器并沒(méi)有提供Message-Id的事實(shí)。信封頭上面關(guān)于SMTP的討論部分提到了“消息”頭和“信

23、封”頭的不同之處。這種區(qū)別和導(dǎo)致的后果將在這里詳細(xì)地討論。簡(jiǎn)單地說(shuō)，“信封”頭實(shí)際上是由接收消息的郵件服務(wù)器產(chǎn)生的，而不是發(fā)送者服務(wù)器。按照這個(gè)定義，“Received:”頭是信封頭，而一般來(lái)說(shuō)常常使用envelope From和envelope To來(lái)指示它們。envelope From頭是從MAIL FROM命令得到的。如發(fā)送者郵件服務(wù)器發(fā)出命令MAILFROM: ideal，則接收者服務(wù)器則產(chǎn)生一個(gè)envelope From頭： From ideal。注意這里少了一個(gè)冒號(hào)-From而不是From:。也就是說(shuō)信封頭在其后沒(méi)有冒號(hào)。當(dāng)然這個(gè)慣例并不是標(biāo)準(zhǔn)，但是這時(shí)一個(gè)值得注意的慣例。對(duì)應(yīng)的是

24、envelope To同樣來(lái)自于RCPT TO命令。如果發(fā)送者服務(wù)器發(fā)出命令RCPT TO:ideal。則envelope To為ideal。一般來(lái)說(shuō)實(shí)際上并沒(méi)有這樣一個(gè)郵件頭，它常常是包含在Received:頭中。存在信封信息的一個(gè)重要結(jié)果就是消息From:和To:變得毫無(wú)意義。From:頭是由發(fā)送者提供的，同樣To:也是由發(fā)送者提供的。因此郵件僅僅基于envelope To來(lái)進(jìn)行轉(zhuǎn)發(fā)路由，而不是基于消息To:。為了從實(shí)際中理解這個(gè)概念，看看下面這樣的郵件傳輸：HELO 250 Hello 20, pleased to meet you MAI

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

26、 Received: from (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ā)送者指定的，因此他們都是不可靠的。這個(gè)例子說(shuō)明了為什么信封From、消息From:及消息To:在可能是偽造的郵件中是不可靠的，因?yàn)樗?/p>

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

28、發(fā)送郵件給，但是使用HELO 命令來(lái)偽造自己的身份，則對(duì)應(yīng)該次傳輸?shù)腞eceived:可能如下所示：Received: from (20) by (8.8.5).(后面的其他信息被省略以更加清晰)。注意雖然沒(méi)有明確地說(shuō)不是發(fā)送者的真實(shí)身份，但是它記錄了發(fā)送者正確的IP地址。如果某接收者認(rèn)為消息頭中的是偽造者偽造的身份，他可以查看IP地址20來(lái)得到對(duì)應(yīng)的正確域名是，而不是。也就是說(shuō)記錄發(fā)送服務(wù)器的IP地址提供了足夠的信息來(lái)確認(rèn)可以的偽造行為。很多現(xiàn)代郵件程序?qū)嶋H上將根據(jù)IP查看對(duì)應(yīng)域名的過(guò)程自動(dòng)化了。(這種查看過(guò)程被稱(chēng)為反向DNS解析)。如果使用這種軟件，則Received:頭則變?yōu)镽eceived: from ( 20) by .從這里可以清楚地看到偽造行為。這個(gè)消息頭明確地說(shuō)的IP地址是20，但是卻宣稱(chēng)自己的身份為。這樣的信息對(duì)于對(duì)于驗(yàn)證和追蹤偽造信件是非常有用的。(因此，垃圾郵件發(fā)