專利名稱：在通信網(wǎng)絡中鑒權電子郵件消息的方法和裝置的制作方法
技術領域：
本發(fā)明一般涉及電信領域，尤其涉及因特網(wǎng)消息安全。
背景技術：
隨著因特網(wǎng)的發(fā)展，電子郵件系統(tǒng)的濫用正在成為日益增長的問題。這些濫用包括欺騙始發(fā)點(例如哄騙或試圖制造看起來與特定的可接收的始發(fā)點相似的始發(fā)點)以創(chuàng)建電子郵件垃圾郵件、病毒發(fā)布、以及電子郵件的其他濫用。特別地，尤其危險的問題是通過聲稱從朋友、同事、以及聲譽好的組織發(fā)送的電子郵件發(fā)布計算機病毒。
迄今為止，還沒有任何方案有效地解決以上問題，盡管現(xiàn)存的因特網(wǎng)標準確實提供了核對在電子郵件的“From”字段中所指示的域中是否存在電子郵件的聲稱的發(fā)送者的選項。但是，很少使用這個選項，這可能是因為當前的作惡者在其配置中確實具有合法的地址，因此，只核對地址有效是不夠的。
現(xiàn)存的電子郵件標準(RFC 2821)和軟件允許任何人發(fā)送具有在From字段中指示的任何始發(fā)點的電子郵件消息。廣告客戶已經(jīng)利用這個特征(確切地說是弱點)來生成電子郵件垃圾郵件。更險惡的應用(現(xiàn)在越來越普遍)是在從看似是其朋友和同事的地方發(fā)送到接收者的消息中發(fā)布計算機病毒。
現(xiàn)存的電子郵件標準確實允許核實發(fā)件人，但是這個特征只核實在存在的域中地址是正確的(即存在)。它不核實這個具體消息是否已經(jīng)從具體地址發(fā)送。很多郵件服務器正好忽略這個特征，這是因為它已經(jīng)變?yōu)闊o用的例如，列在因特網(wǎng)上的大量有效電子郵件地址、多個電子郵件列表上被存檔的交換、以及其他來源(例如被侵入的計算機的地址簿中的信息)為垃圾郵件發(fā)送者或犯罪作惡者提供了足夠多的地址來使用。另外，搜索引擎幫助獲得潛在目標通信者的列表，因此攻擊變的更集中。
解決問題的一種方式是證明和數(shù)字簽名每一個消息，但是因為其很昂貴和復雜，所以還沒有實現(xiàn)。更重要地，它不是可協(xié)同工作的，直到它在每個地方都被使用，但是費用和復雜性使其很難廣泛地使用。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的原理，對現(xiàn)有技術進行了改進，其中本發(fā)明涉及與安全字段、垃圾郵件預防、AAA、Radius、以及因特網(wǎng)消息發(fā)送協(xié)議相關的方法。本發(fā)明解決了欺騙始發(fā)點以創(chuàng)建電子郵件垃圾郵件、病毒發(fā)布、和電子郵件的其他濫用的問題。特別地，它解決了通過聲稱從朋友、同事、和聲譽好的組織發(fā)送的電子郵件發(fā)布計算機病毒這個尤其危險的問題。
本發(fā)明定義了一組全面的機制和裝置，以適度地確保電子郵件消息-當被電子郵件網(wǎng)關、電子郵件中繼服務器、或目的地電子郵件服務器接收時-已經(jīng)在位置上發(fā)起，并由其“From”字段中所指定的個人(或程序)發(fā)送。
本發(fā)明確保了在到電子郵件消息終點接收者的中繼鏈中的任何電子郵件服務器(即網(wǎng)關、中繼、或目的地服務器)能夠完全確定消息是否已經(jīng)由在From字段中所指示的個人(或程序)發(fā)送。
本發(fā)明通過以下方式工作a)直接發(fā)送查詢到聲稱的發(fā)起服務器，或者b)使用AAA服務器(例如Lucent Navis Radius服務器)來執(zhí)行這個功能。如果對查詢的響應是否定的，則消息被丟棄，并且如果需要，則產(chǎn)生適當?shù)陌踩罩颈砟俊?br> 這個機制新在它以多種方式鑒權消息(不僅是聲稱的發(fā)件者)，其中每種方式都容易實現(xiàn)。它還避免了前面提出的(但發(fā)現(xiàn)很難實現(xiàn)的)、使用證書和可能依賴于復雜的密鑰發(fā)布、密碼術等的其他復雜的安全機制(例如電子簽名)的機制。最后，它避免了昂貴的PKI實現(xiàn)和外部信任中心的證書的集成。


通過聯(lián)系附圖考慮以下詳細的描述，能夠很容易地理解本發(fā)明的示教，在附圖中圖1表示用于實現(xiàn)本發(fā)明方法的、簡化的框圖形狀單元；以及圖2是根據(jù)本發(fā)明的服務器設備的示例性框圖。
具體實施例方式
現(xiàn)在將參考附圖介紹本發(fā)明的示例性實施例，在以下描述中可能同時參考多個附圖。
本發(fā)明很簡單，并且它消除了使用任何類型的密碼術(包括數(shù)字簽名)、證書、或公開密鑰發(fā)布機制的花費和復雜性。
本發(fā)明確保在到電子郵件消息終點接收者的中繼鏈路中任何電子郵件服務器(即網(wǎng)關、中繼、或目的地服務器)能夠適當?shù)卮_定消息是否已經(jīng)由在From字段中所指示的個人(或程序)發(fā)送。
本發(fā)明通過以下方式工作a)直接發(fā)送查詢到聲稱的始發(fā)服務器，或b)使用AAA服務器(例如Lucent Navis Radius服務器)來執(zhí)行這個功能。如果對查詢的響應是否定的，則消息被丟棄，并且，如果需要，產(chǎn)生適當?shù)陌踩罩颈砟俊?br> 機制新在其以多種方式鑒權消息(不僅是聲稱的發(fā)件人)，每種方式都很容易實現(xiàn)。它還避免了前面提出的(但發(fā)現(xiàn)很難實現(xiàn)的)機制，即使用證書和可能依賴于復雜的密鑰發(fā)布、密碼術等的其他復雜的安全機制(例如電子簽名)。最后，它避免了昂貴地PKI實現(xiàn)和外部信任中心證書的集成。
圖1表示用于描述本發(fā)明的、介紹典型電子郵件路徑的網(wǎng)絡10的示例性部分。這里，客戶端12通過其服務器14發(fā)送消息，消息穿過域網(wǎng)關16和其他代理服務器18，每個代理服務器(從始發(fā)服務器14開始)使用RFC 2821中描述的簡單郵件傳送協(xié)議(SMTP)。當消息到達目的地服務器20時，它被發(fā)送到適當?shù)氖占?未標出)。注意，始發(fā)服務器14、目的地服務器20、代理服務器18和網(wǎng)關16都執(zhí)行RFC 2821中所定義的郵件傳送主體的作用。
參考圖1，本發(fā)明的一個示例性實施例工作如下1.只要始發(fā)服務器14接收轉發(fā)來自始發(fā)客戶端12的電子郵件的請求，則它執(zhí)行以下步驟a.檢查電子郵件首標中From字段是否指向服務器上的郵箱。如果是，則它轉發(fā)郵件。否則，它用例如經(jīng)RFC 2821的永久的、否定完成答復來拒絕郵件。
b.本發(fā)明還記錄被成功轉發(fā)的電子郵件(或者，可能地，它的某個部分，或者甚至由本地選擇的散列算法所確定的它的散列)。日志中的表目被維持一定時間長度(典型地，例如不超過10分鐘)。
2.在本發(fā)明的示例性實施例中，鏈中的任何其他服務器都可以執(zhí)行下述步驟。目的地服務器20必須執(zhí)行這些步驟。這些步驟能夠以本領域技術人員理解的多種可選方式實現(xiàn)a.(選項1)當消息傳送開始(如箭頭標記(1)所示)，并且已知消息聲稱的始發(fā)點(在SMTP的From字段中傳遞的)時，服務器20通過發(fā)送標記為(2)的查詢來啟動與始發(fā)服務器14的短的會話(例如TCP會話)或者啟動到始發(fā)服務器14的事務。這個查詢詢問由一組參數(shù)(這些參數(shù)可以包括但不限于From字段、時間、長度、主題、被選擇的內(nèi)容、或包括以上所有的任何其他特定于消息的參數(shù)組)的一個或多個所識別的始發(fā)消息實際上是否已經(jīng)被所指定的用戶發(fā)送。以下介紹可能的查詢格式(其中根據(jù)SMTP對語法進行建模)。查詢包括由自變量跟隨的命令CONFIRM<Message-ID><message-specific-parameters>。其中CONFIRM是命令名，<Message-ID>自變量包括消息唯一的標識符，而<message-specific-parameters>自變量包含能夠被用于消息識別的上述參數(shù)的列表。接收到查詢后，使用唯一Message-ID的始發(fā)服務器檢查其日志，以核實在查詢Message-ID中所接收的消息是否已經(jīng)被發(fā)送。如果沒有，則發(fā)送相應的答復到接收服務器。在這個示例性實施例中，如果Message-ID所識別的消息已經(jīng)被記錄，則始發(fā)服務器將能夠通過比較被記錄的消息中的信息和在查詢的<message-specific-parameters>自變量中所接收的信息而確定消息的確實性。響應于查詢將發(fā)送那個判定。
以下是查詢的例子CONFIRM<406C9526.2060307@agere.com><Fromabc@agere.com>。在接收到這個查詢以后，始發(fā)服務器將能夠檢索由406C9526.2060307@agere.com所涉及的消息，并檢查“abc”是否在與消息發(fā)送者相關的別名中。始發(fā)服務器應該了解發(fā)送者的標識符，這是因為在消息被始發(fā)時，它被作為被執(zhí)行的SMTP命令MAILFROM<reverse-path>[RFC 2821]的自變量被提供。
所提出的查詢應該對具有RFC 822中所描述的唯一Message-ID的絕大多數(shù)消息有效。盡管這個標準將Message-ID字段指定為可選的，但是多數(shù)SMTP服務器將這個字段包括到其電子郵件消息中。如果缺少這個字段，則接收服務器能夠根據(jù)本地策略(例如終止消息、發(fā)送警告到收件人等)工作。
b.在接收查詢以后，始發(fā)服務器14檢查其日志22，并用具有關于被發(fā)起的消息是否是由所指定的用戶發(fā)送的信息的消息(3)來響應。
c.如果它作出肯定的響應，則接收(目的地)服務器20繼續(xù)處理和轉發(fā)電子郵件消息。否者，可能立即終止處理。終止的結果是消息不被存儲或轉發(fā)。終止能夠以多種不同的方式執(zhí)行。例如，執(zhí)行終止的一種方式是導致超時，或者創(chuàng)建和發(fā)送一個消息，例如“收件人不存在”。這里也可以想到中斷通信的其他這樣的方式，以便阻止任何進一步的攻擊。如能夠理解的那樣，任何有關的服務器還可以產(chǎn)生其安全策略所指定的適當?shù)陌踩罩颈砟?，或者采取任何其他與安全相關的操作，例如到適當?shù)膹娭拼淼耐ㄖ?br> d.(選項2)在另一個可選實施例中，目的地服務器20要求適當?shù)蔫b權、授權、以及計費(AAA)服務器24鑒權消息，并授權其接收(消息2’)。然后，AAA服務器24執(zhí)行其自己與始發(fā)服務器14的交換(消息2”和3’)，進行適當?shù)呐卸?，并用消?”將這個判定作為響應發(fā)送到查詢服務器。
e.如果始發(fā)服務器14(和AAA服務器)肯定地響應，則目的地服務器20繼續(xù)處理和轉發(fā)電子郵件消息。否則，目的地服務器立即終止處理。任何有關的服務器還可以產(chǎn)生如其安全策略所描述的適當?shù)陌踩罩颈砟?，或者采取任何其他與安全相關的操作。還應該理解，一旦AAA服務器詢問始發(fā)服務器關于始發(fā)服務器是否也能夠直接對目的地服務器作出響應，則AAA能夠只在通信的響應階段被涉及。
圖2表示根據(jù)本發(fā)明的服務器設備110的示例性框圖。通常，設備包括與處理器120連同工作的至少兩個功能塊。第一個塊130是記錄表，被接收的傳輸如已經(jīng)解釋的那樣被存儲在那里。下一個塊140是存儲設備，用于例如在軟件中存儲指令，以便執(zhí)行本發(fā)明的方法。應該理解，記錄表也可以是設備的整體存儲器的部分。服務器設備還包括輸入和輸出端150、160。另外，盡管結合服務器描述了本發(fā)明的功能，但是應該理解，本發(fā)明也可以存在于代理設備或與服務器相關的其他類似設備中。
為了解釋清楚，已經(jīng)將本發(fā)明的示例性實施例描述為包括單獨功能塊和/或框?？梢酝ㄟ^使用共享的或專用的硬件(包括但不限于能夠執(zhí)行軟件的硬件)來提供這些塊和/或框所表示的功能。術語“處理器”的使用不應該被解釋為只指能夠執(zhí)行軟件的硬件。另外，示例性實施例可以包括數(shù)字信號處理器(DSP)硬件、用于存儲執(zhí)行下述操作的軟件的只讀存儲器(ROM)、以及用于存儲DSP結果的隨機存取存儲器(RAM)。也可以提供超大規(guī)模集成電路(VLSI)硬件實現(xiàn)，以及與通用DSP電路結合的定制的VLSI電路。
雖然已經(jīng)在優(yōu)選實施例的語境中詳細地表示和描述了本發(fā)明，但是，本領域的技術人員將明白，變化和修改是可能的，并且不會背離由后面的權利要求書的范圍單獨限定的本發(fā)明的寬的原則和精神。
前面的描述只是表示了本發(fā)明的原則。因此，應該理解，本領域技術人員將能夠設計不同的裝置，這些不同的裝置盡管沒有在這里被顯式地描述或表示，但是它們實現(xiàn)了本發(fā)明的原則并被包括在其精神和范圍內(nèi)。另外，所敘述的所有例子和條件語言主要是只為了示教的目的，以便幫助讀者理解本發(fā)明的原則和發(fā)明人所提出的擴展現(xiàn)有技術的改良，并且不被解釋為對這些具體引用的例子和條件的限制。而且，這里敘述本發(fā)明的原理、方面、和實施例、以及其具體例子的所有陳述都包括其等價物的結構和功能。另外，這些等價物包括當前已知的等價物以及將來開發(fā)的等價物，即開發(fā)的執(zhí)行相同功能的單元，而不管結構。
在權利要求書中，被表述為用于執(zhí)行具體功能的裝置的任何單元包括執(zhí)行那個功能的任何方式，包括例如，a)執(zhí)行那個功能的電路單元的組合，或者b)任何形式的軟件，因此包括與用于執(zhí)行那個軟件以實現(xiàn)功能的適當?shù)碾娐方Y合的固件、微碼等。這樣的權利要求書所限定的發(fā)明存在與這樣的事實，即描述的多種裝置所提供的功能被組合，并被以權利要求所要求的方式集合。因此，申請人將能夠提供那些功能的任何裝置視為這里所表示的那些裝置的等價物。對本發(fā)明原則的很多其他修改和應用對于本領域技術人員是顯然的，并且通過這里的教導而被預料到。因此，本發(fā)明的范圍只由權利要求書限定。
權利要求
1.一種在通信網(wǎng)絡中鑒權電子郵件消息的方法，所述方法包括以下步驟在始發(fā)服務器中接收查詢，以確定電子郵件消息是否由指定的用戶發(fā)送；在所述始發(fā)服務器中檢查被記錄的數(shù)據(jù)，以確定所述電子郵件消息是否對應于從所述始發(fā)服務器所發(fā)送的消息；以及響應所述查詢，鑒權所述電子郵件消息。
2.根據(jù)權利要求1的方法，還包括以下步驟當所述始發(fā)服務器接收用以轉發(fā)電子郵件的請求時，檢查電子郵件消息首標中的“From”字段是否對應于由始發(fā)服務器所服務的郵箱；以及如果所述電子郵件消息成功地對應于所述始發(fā)服務器，則記錄用以識別所述電子郵件消息的數(shù)據(jù)。
3.根據(jù)權利要求1的方法，其中從目的地服務器接收所述查詢。
4.根據(jù)權利要求1的方法，其中從鑒權服務器接收所述查詢。
5.根據(jù)權利要求1的方法，其中用從包括以下要素的組中選擇出的一組參數(shù)中的一個或多個來識別始發(fā)消息From字段、時間、長度、主題行、被選內(nèi)容、以及其他特定于消息的參數(shù)。
6.一種在通信網(wǎng)絡的目的地服務器中鑒權電子郵件消息的方法，其中當始發(fā)服務器接收用以轉發(fā)電子郵件的請求時，所述始發(fā)服務器檢查電子郵件消息首標中的“From”字段是否對應于由始發(fā)服務器所服務的郵箱，并且如果所述電子郵件消息成功地對應于所述始發(fā)服務器，則所述始發(fā)服務器記錄用于識別所述電子郵件消息的數(shù)據(jù)，所述方法包括以下步驟發(fā)送查詢，以確定所述電子郵件消息是否由指定的用戶發(fā)送；接收對所述查詢的響應，以確定所述消息是否被鑒權，所述響應包括關于所述電子郵件消息是否對應于所述被記錄的數(shù)據(jù)以及所述始發(fā)服務器的信息。
7.一種在通信網(wǎng)絡中鑒權電子郵件消息的方法，所述方法包括以下步驟當始發(fā)服務器接收用于轉發(fā)電子郵件的請求時，檢查電子郵件消息首標中的“From”字段是否對應于所述始發(fā)服務器所服務的郵箱；如果所述電子郵件消息成功地對應于所述始發(fā)服務器，則記錄用以識別所述電子郵件消息的數(shù)據(jù)；從目的地服務器發(fā)送查詢，以確定所述電子郵件消息是否由指定的用戶發(fā)送；在所述始發(fā)服務器處檢查所述被記錄的數(shù)據(jù)，以確定所述電子郵件消息是否對應于所述始發(fā)服務器；響應于所述查詢，鑒權所述電子郵件消息；以及在所述目的地服務器中接收所述響應。
8.一種用于在通信網(wǎng)絡中鑒權電子郵件消息的裝置，所述裝置包括用于在始發(fā)服務器中接收查詢，以確定所述電子郵件消息是否由指定的用戶發(fā)送的裝置；用于檢查所述始發(fā)服務器中被記錄的數(shù)據(jù)，以確定所述電子郵件消息是否對應于從所述始發(fā)服務器所發(fā)送的消息的裝置；以及用于響應于所述查詢，鑒權所述電子郵件消息的裝置。
9.根據(jù)權利要求8的裝置，還包括用于當始發(fā)服務器接收用以轉發(fā)(始發(fā)客戶端的？)電子郵件的請求時，檢查電子郵件消息首標中的“From”字段是否對應于所述始發(fā)服務器所服務的郵箱的裝置；用于如果電子郵件消息成功地對應于所述始發(fā)服務器，則記錄識別所述電子郵件消息的數(shù)據(jù)的裝置。
10.一種用于在通信網(wǎng)絡的目的地服務器中鑒權電子郵件消息的裝置，其中當始發(fā)服務器接收用以轉發(fā)電子郵件的請求時，所述始發(fā)服務器檢查電子郵件消息首標中的“From”字段是否對應于由始發(fā)服務器所服務的郵箱，并且如果所述電子郵件消息成功地對應于所述始發(fā)服務器，則所述始發(fā)服務器記錄用以識別所述電子郵件消息的數(shù)據(jù)，所述裝置包括用于發(fā)送查詢，以確定所述電子郵件消息是否由指定的用戶發(fā)送的裝置；用于接收對于所述查詢的響應，以確定所述消息是否被鑒權的裝置，所述響應包括關于所述電子郵件消息是否對應于所述被記錄的數(shù)據(jù)以及所述始發(fā)服務器的信息。
全文摘要
本發(fā)明解決了欺騙始發(fā)點以創(chuàng)建電子郵件垃圾郵件、病毒發(fā)布、以及電子郵件的其他濫用的問題。特別地，它解決了通過聲稱從朋友、同事、以及聲譽好的組織發(fā)送的電子郵件發(fā)布病毒這個尤其危險的問題。本發(fā)明定義了一組完整的機制和裝置，以合理地確保了電子郵件消息在被電子郵件網(wǎng)關、電子郵件中繼服務器、或目的地電子郵件服務器接收時已經(jīng)在位置上啟動，并且由其“From”字段中所指定的個人(或程序)發(fā)送。
文檔編號H04L12/58GK1668040SQ20051005307
公開日2005年9月14日 申請日期2005年3月7日 優(yōu)先權日2004年3月9日
發(fā)明者伊戈爾·凡博格, 盧慧蘭, 理查德·佩爾曼, 扎卡里·澤爾策安 申請人:朗迅科技公司