史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 應用軟體使用技術文件
忘記密碼?
註冊帳號 論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2004-01-20, 01:30 PM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 電子郵件頭解析

一、簡介

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

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

二、Email的傳輸程序

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

從表面上看來郵件似乎是直接從傳送者機器傳遞到接收者位址,但通常情況下事情並不是這樣。一個典型的電子郵件在其生命週期中至少要經過四台電腦。

這是因為大多數企業或組織都有一個被稱為「郵件伺服器」專用伺服器來處理電子郵件,而這一般並不是用戶閱讀郵件的電腦。對於ISP來說,用戶從家裡面的電腦撥號接入ISP網路,這裡將用戶家中的電腦稱為客戶端機,而將ISP專門處理郵件的電腦稱為郵件伺服器。當一個用戶傳送郵件,他一般是在自己的電腦上編輯郵件,然後將郵件傳送到ISP的郵件伺服器上。客戶端機就此已經完成了自己的工作,而後面的工作則由ISP的郵件伺服器來完成。首先ISP郵件伺服器搜尋接收者指定的郵件伺服器的IP位址,然後將郵件傳送給該目的伺服器。現在郵件則存儲在接收者郵件伺服器上等待接收者收取。當接收者從接受郵件伺服器取得傳送給他的郵件到自己的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-通信,並將郵件傳送給它。現在郵件則被存儲在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 accepted 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中。

非正常情況

上面的例子有些過於簡單。上面的例子有一個假設前提:兩個組織的郵件伺服器相互之間能直接訪問,而不需要經過代理、防火牆等安全設備。這在當前Internet環境下情況往往是這樣的。


但由於安全對於某些組織來說非常重要,而且網路或組織可能變得越來越龐大,情況就不那麼簡單了。


對於具有代理型防火牆系統的郵件傳輸來說,區別就在於在郵件的頭中多了一次轉發程序的記錄,也就是郵件首先從傳送者郵件伺服器傳送到防火牆上,然後再從防火牆傳送到目的郵件伺服器。

郵件中繼

中繼

對於某些具有特殊的「生命」週期的郵件頭可能和前面討論的情況完全不同:

Received: from unwilling.intermedia.com (unwilling.intermedia.com [98.134.11.32]) by mail.zky.ac.cn (8.8.5) id 004B32 for <lisi@zky.ac.cn>; Wed, Jul 30 1997 16:39:50 -0800 (PST)
Received: from linuxaid.com.cn ([202.99.11.120]) by unwilling.intermedia.com (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 1997 19:36:28 -0500 (EST)
From: Anonymous Spammer <junkmail@linuxaid.com.cn>
To: (recipient list suppressed)
Message-Id: <w45qxz23-34ls5@unwilling.intermedia.com>
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???

這個郵件頭和以前的不同之處可能會令你認為這是一封垃圾郵件,但是這裡引起你的懷疑的是"Received:"頭。

從"Received:"頭看來,郵件是來自linuxaid.com.cn,然後從這裡傳輸給unwilling.intermedia.com,然後從這裡再次傳輸到最終目的位址:

mail.zky.ac.cn。從"Received:"頭看來事情就是這樣的,但是中間為什麼會出現unwilling.intermedia.com呢?因為它和傳送者和接收者都沒有直接的關係。

要理解原因需要對SMTP傳輸協定進行一些瞭解。本質上來講,傳輸程序是這樣的:linuxaid.com.cn連接unwilling.intermedia.com的SMTP連接埠。

告訴它「請傳送這封郵件到rth@zky.ac.cn。

它可能是以最直接的方法來實現:
RCPT TO: rth@zky.ac.cn。到現在為止,unwilling.intermedia.com接管對該郵件的處理。


因為它被告知將該郵件轉發給其他一個域:zky.ac.cn,它就搜尋對於域名zky.ac.cn的郵件伺服器然後將郵件轉發給zky.ac.cn。這個程序通常被稱作郵件中繼(mail relaying)。

出現郵件中繼是由於歷史的原因,使用郵件中繼是有它的好處的。到八十年代末期,很多網路中的電腦都不是直接通信來傳輸郵件。而是通過郵件路由來傳遞郵件,通過郵件路由伺服器一步一步地進行郵件傳輸。這樣做是非常麻煩的,傳送者往往需要手工指定一封郵件需要經過哪些郵件路由伺服器,比如需要從San Francisco傳送一封郵件到New York,則需要在信封中增加如下內容:

San Francisco, Sacramento, Reno, Salt Lake City, Rock Springs, 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的郵局只需要知道如何和臨近的郵局Chicago和Elkhart通信,而無需消耗資源計算如何將郵件傳送到New York(這時候就很清楚為什麼這種模式對於郵件傳送者來說非常糟糕,為什麼這種方法被拋棄了)。但是這就是郵件被傳輸的程序。


因此伺服器具有這樣的中繼的能力在那時是很重要的。

而現在中繼通常被用作不道德的廣告商用來隱藏它們的原始位址,將埋怨轉嫁給被用來中繼的伺服器而不是其所在ISP的技術。


同樣通過中繼可以實現將傳送郵件的負載轉移到中繼伺服器上,從而實現盜用中繼伺服器的服務資源。

在這裡最重要的一點是理解郵件內容是在傳送點linuxaid.com.cn被編輯。中間的伺服器unwilling.intermedia.com只是參加了中間的傳輸工作,它並不能對傳送者有任何的約束力。

在上面的例子中應該注意的另外一點是"Message-Id:"並不是由傳送者伺服器(linuxaid.com.cn)而是中繼電腦(unwilling.intermedia.com)填寫的。這是被中繼的郵件的一個典型特性,該特性反映了傳送伺服器並沒有提供Message-Id的事實。

信封頭

上面關於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 accepted 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: (your address suppressed for stealth mailing and annoyance)
注意到"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:"頭一般都很明顯地是偽造的垃圾。
psac 目前離線  
送花文章: 3, 收花文章: 1630 篇, 收花: 3204 次
舊 2004-01-23, 01:06 PM   #2 (permalink)
長老會員
榮譽勳章
UID - 91337
在線等級: 級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時
註冊日期: 2003-08-10
住址: taipei
文章: 16
精華: 0
現金: 15562 金幣
資產: 20562 金幣
預設

謝謝詳細解說,正需要此資訊
billyu 目前離線  
送花文章: 111, 收花文章: 0 篇, 收花: 0 次
舊 2004-05-30, 03:30 PM   #3 (permalink)
長老會員
榮譽勳章
UID - 91337
在線等級: 級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時級別:17 | 在線時長:385小時 | 升級還需:11小時
註冊日期: 2003-08-10
住址: taipei
文章: 16
精華: 0
現金: 15562 金幣
資產: 20562 金幣
預設

謝謝大大解說
billyu 目前離線  
送花文章: 111, 收花文章: 0 篇, 收花: 0 次
舊 2004-05-30, 08:42 PM   #4 (permalink)
註冊會員
榮譽勳章
UID - 14476
在線等級: 級別:8 | 在線時長:115小時 | 升級還需:2小時級別:8 | 在線時長:115小時 | 升級還需:2小時級別:8 | 在線時長:115小時 | 升級還需:2小時
註冊日期: 2002-12-19
VIP期限: 2011-06
住址: 美女主播群親衛隊
文章: 243
精華: 0
現金: 1061 金幣
資產: 930274 金幣
預設

嗯,感謝大大的解說。
joexyz 目前離線  
送花文章: 1, 收花文章: 4 篇, 收花: 4 次
 


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 12:00 PM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2020, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1