電子郵件頭詳揭秘(1)

 一、簡介

這一部分內容將詳細討論email頭的方方面面。主要為用戶架設郵件服務器提供理論基礎并為管理員在出現電子郵件垃圾騷擾時提供發現垃圾郵件的真正源頭。根據郵件頭的知識有助于發現偽造的郵件。對于希望了解郵件是如何在網絡中傳輸的用戶同樣會有幫助。

雖然在討論中盡量有意避免如何偽造一封郵件的討論，但是在討論中的內容可能被惡意讀者用作創建偽造郵件的基礎。因為要在文章中舉例說明，因此在文章中有若干虛構的域名和隨意分配的IP地址作為示例使用。這些域名和IP都是任意任意選擇和偽造的，和Inte.net上真實的域名和IP沒有任何關系。

二、Email的傳輸過程

這部分包含一個簡單的對一個電子郵件生命周期的分析。這對于理解郵件頭能為你提供哪些信息是非常重要的背景信息。

從表面上看來郵件似乎是直接從發送者機器傳遞到接收者地址，但通常情況下事情并不是這樣。一個典型的電子郵件在其生命周期中至少要經過四臺計算機。

這是因為大多數企業或組織都有一個被稱為“郵件服務器”專用服務器來處理電子郵件，而這一般并不是用戶閱讀郵件的計算機。對于ISP來說，用戶從家里面的計算機撥號接入ISP網絡，這里將用戶家中的計算機稱為客戶機，而將ISP專門處理郵件的計算機稱為郵件服務器。當一個用戶發送郵件，他一般是在自己的計算機上編輯郵件，然后將郵件發送到ISP的郵件服務器上?？蛻魴C就此已經完成了自己的工作，而后面的工作則由ISP的郵件服務器來完成。首先ISP郵件服務器查找接收者指定的郵件服務器的IP地址，然后將郵件發送給該目的服務器?，F在郵件則存儲在接收者郵件服務器上等待接收者收取。當接收者從接受郵件服務器取得發送給他的郵件到自己的PC機以后，通常該郵件將被刪除。

假設若干個虛構的用戶< zhangsan@263.net>和<lisi@zky.ac.cn>。zhangsan是263這個ISP的撥號用戶。使用 outook express這個郵件客戶程序收發郵件。lisi是中科院的一個虛構用戶，他使用工作站通過單位局域網連接進入互聯網。

如果lisi想給zhangsan發送郵件，他在工作站(假設名字為alpha.zky.ac.cn)上編輯郵件，編輯好的信件從工作站發送到中科院的郵件服務器：mail.zky.ac.cn。一旦信件被發送到mail.zky.ac.cn，以后的信件發送過程就和zhangsan沒有關系了。中科院的郵件服務器發現這是發送給263.net的某個用戶的信件，則和263的郵件服務器-比如說是mail.263.net－通信，并將郵件傳送給它?，F在郵件則被存儲在mail.263.net之上直到zhangsan在自己的PC機上撥號連接到263網絡察看并收取信件，這時mail.263.net將存儲的郵件傳送到zhangsan的個人PC機上。

在這個過程中，郵件頭將三次被加到郵件中：在編輯時由郵件客戶程序加入；當郵件傳輸到mail.zky.ac.cn時被mail.zky.ac.cn加入；當從mail.zky.ac.cn傳送到mail.263.net時被 mail.263.net加入；通常來說客戶收取信件時并不添加郵件頭。下面我們就仔細看看這些郵件頭是如何產生的。

當lisi的郵件客戶程序編輯郵件并將其發送給mail.zky.ac.cn時，郵件內容如下.這些內容都是由郵件編輯程序(outlook express)添加的：

From: lisi@zky.ac.cn (Li Si)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

X-Mailer: Outlook Express 5.5

Subject: 中午搓飯？

當郵件從mail.zky.ac.cn傳送到mail.263.net后，郵件內容變為(新添加的內容是由mail.zky.ac.cn)：

Received: from alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11]) by mail.zky.ac.cn (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)

From: lisi@zky.ac.cn (Li Si)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

Message-Id: <lisi031897143614-00000298@mail.zky.ac.cn>

X-Mailer: Outlook Express 5.5

Subject: 中午搓飯?

當mail.263.net收到信件并存儲等待zhangsan收取時，郵件內容變為，(新添加的內容是由mail.263.com添加的)：

Received: from mail.zky.ac.cn (mail.zky.ac.cn [124.211.3.78]) by mail.263.net (8.8.5/8.7.2) with ESMTP id LAA20869 for <zhangsan@263.net>; Tue, 18 Mar 1997 14:39:24 -0800 (PST)

Received: from alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11]) by mail.zky.ac.cn (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)

From: lisi@zky.ac.cn (Li Si)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

Message-Id: <lisi031897143614-00000298@mail.zky.ac.cn>

X-Mailer: Outlook Express 5.5

Subject: 中午搓飯?

最后這封信的內容才是zhangsan收取并閱讀的內容。下面是對其中內容的詳細分析：

Received: from mail.zky.ac.cn

上面的內容表示該郵件是來自于自稱是mail.zky.ac.cn的服務器。

(mail.zky.ac.cn [124.211.3.78])

這句話表示該服務器的真實名字的確是mail.zky.ac.cn，也就是說它自稱的身份是正確的，其IP地址為124.211.3.78。

by mail.263.net (8.8.5/8.7.2)

接收這封郵件的機器是mail.263.net。其運行的郵件程序為sendmail，版本為8.8.5/8.7.2。

with ESMTP id LAA20869

接收郵件的服務器為該郵件賦有ID號LAA20869(通常該號碼是郵件服務器內部使用的，但是管理員可以根據該ID號在log文件中查找關于該信件的相關信息，但是通常該號都是沒有意義的)。

for <zhangsan@263.net>;

該郵件是發送給地址zhangsan@263.net的?？梢钥吹皆撪]件頭沒有To：相關內容。

Tue, 18 Mar 1997 14:39:24 -0800 (PST)

這次郵件傳輸發生時間為：太平洋時間Tuesday, March 18, 1997, at 14:39:24(太平洋時間，因為它比格林威治時間晚8個小時，因此是"-0800")?！?

Received: from alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11]) by mail.zky.ac.cn (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)

該郵件頭記錄了郵件是從alpha.zky.ac.cn(lisi的工作站)傳送到到郵件服務器mail.zky.ac.cn 的。傳送發生在太平洋時間14:36:17。發送計算機自稱是alpha.zky.ac.cn，其真實名經dns查詢的確是 alpha.zky.ac.cn，其IP地址為124.211.3.11，郵件服務器軟件為sendmail v8.8.5。該信件被郵件服務器的mail.zky.ac.cn賦給的ID號為004A21。

From: lisi@zky.ac.cn (Li Si)

該郵件是由lis@zky.ac.cn發送的，其名字為Li Si。

To: zhangsan@263.net

郵件目的地址為：zhangsan@263.net?！?

Date: Tue, Mar 18 1997 14:36:14 PST

郵件編輯時間為14:36:14 Pacific Standard Time on Tuesday, March 18, 1997。

Message-Id: <lisi031897143614-00000298@mail.zky.ac.cn

mail.zky.ac.cn給該郵件分配了這個號碼來標識它。它和Received頭中的SMTP機ESMTP ID號是不一樣的。因為該號碼是一直伴隨整個郵件的。而其它ID則僅僅在特定的郵件服務器上的郵件傳輸階段相關聯。因此該機器ID號對其它機器來說沒有任何意義。有時候Message-ID包含了發送者郵件地址在其中。

X-Mailer: Outlook Express 5.5

該消息是使用Outlook Express發送的，版本號為5.5。

Subject: 中午搓飯?

郵件標題。

郵件協議

這部分內容相對其它部分來說具有更多原理性內容，主要討論郵件是如何從一點傳輸到另外一點的細節。你不需要理解每一句話，但是熟悉這方面的內容有助于在郵件傳輸出現奇怪現象時弄明白問題所在。由于垃圾電子郵件發送者常常故意制造一些奇怪的情況以掩飾自己的身份，因此能理解這些奇怪的現象對對付這些家伙是非常有用的。

為了在網絡上傳輸數據，計算機網絡協議使用了稱為端口的訪問入口，你可以將端口看做是一個通道，通過它計算機可以監聽網絡通信以提供服務。為了同時監聽多個通信，計算機需要有使用端口號碼標識多個不同的端口以區別這些通信。而和電子郵件傳輸相關的端口是25。

正常情況

讓我們重新討論上面的例子，但是這次我們僅僅關心mail.zky.ac.cn到mail.263.net之間的通信過程。首先 mail.zky.edu.c打開一個到mail.263.net的25號端口的連接，然后通過該連接發送郵件，當然在發送郵件過程中會有一些管理命令交互過程。交互中的命令和相應都或多或少的是可讀的。命令是SMTP協議規定的。如果監聽兩者之間的通信，可能有以下內容：(粗體部分是 mail.zky.ac.cn發出的)

220 mail.263.net ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 1997 14:38:58 -0800 (PST)

HELO mail.zky.ac.cn

250 mail.263.net Hello mail.zky.ac.cn [124.211.3.78], pleased to meet you

MAIL FROM: lisi@zky.ac.cn

250 lisi@zky.ac.cn... Sender ok

RCPT TO: zhangsan@263.net

250 zhangsan@263.net... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

Received: from alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11]) by mail.zky.ac.cn (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)

From: lisi@zky.ac.cn (R.T. Hood)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

Message-Id: <lisi031897143614-00000298@mail.zky.ac.cn>

X-Mailer: Outlook Express 5.5

Subject: 中午搓飯?

Do you have time to meet for lunch?

--lisi

.

250 LAA20869 Message aclearcase/" target="_blank" >ccepted for delivery

QUIT

221 mail.263.net closing connection

整個傳輸依賴于五個SMTP核心命令(當然SMTP還有一些其它命令，但是它們并不是用來完成真正的郵件傳輸)：HELO，MAIL FROM，RCPT TO，DATA和QUIT。

郵件發送者HELO命令用來標識自己的身份。HELO mail.zky.ac.cn可以被解讀為"嗨，我是mail.zky.ac.cn"。當然這里發送者可能會撒謊，但是沒有任何機制能防止發送者 mail.zky.ac.cn說"嗨，我是mail.xxx.com"或是"嗨，我是mail.yyy.com"。然而在大多數情況下接收者都有一些方法來確認發送者的真實身份。

MAIL FROM命令標識開始郵件傳輸，含義是"我有從某人發送來的郵件"，該命令后跟的地址就是所謂的“信封地址”(在后面我們將深入討論)，信封from地址不一定是發送者自己的地址。這個明顯的安全漏洞是不可避免的(因為接收者并不知道發送者機器上有哪些地址)，但是在特定的情況下這又是一個有用處的特色。

RCPT TO和MAIL FROM是相輔相成的。其指定郵件接收者。通過多個RCPT TO命令一個郵件可以被發送給多個接收者。(在后面的郵件中繼部分將解釋該特色可能針對某些不安全的系統濫用)。該命令后跟的地址稱為"envelope to"地址。其指定了郵件將被投遞給哪些用戶，而和信件中的To:指定的地址沒有關系。

DATA命令指示開始實際的郵件內容傳輸。DATA命令后輸入的任何內容都被看做是郵件的一部分。而格式并沒有任何限制。以一個英文單詞加冒號開始的行一般被郵件程序看做是郵件頭。以英文句號符號(.)開始的行被認為是郵件內容結束。

QUIT命令終止連接。

SMTP協議規范定義在RFC 821中。