Sender ID是曾經加入發件人策略框架(SPF)和Caller ID的前MARID英語MARID IETF工作群組的一項反欺騙英語E-mail spoofing協定。 Sender ID主要定義在實驗性RFC 4406,而其餘部分在RFC 4405、RFC 4407和RFC 4408中定義。

操作原理

編輯

Sender ID脫胎於SPF,只增加了部分內容。下面討論兩者的差異:

Sender ID試圖改進SPF中的主要缺陷:SPF不驗證表示傳送方的電子郵件頭位址。此類位址通常是顯示給使用者並作為回覆位址,因而,此類報頭位址可以與SPF嘗試驗證的位址不同。也就是說,SPF僅驗證了郵件來自(MAIL FROM)位址,也稱郵件傳送人。

然而,還有許多類似的電子郵件報頭欄位包含傳送方的資訊。因此,在RFC 4407中定義的Sender ID定義了一個「聲稱負責位址」(Purported Responsible Address,縮寫PRA)以及一組啟發式規則,用於從電子郵件的許多典型報頭中建立此位址。

在語法上,Sender ID與SPF相差無幾,除了v=spf1被替換為下列之一:

  • spf2.0/mfrom - 表示同SPF那樣驗證郵件傳送人。
  • spf2.0/mfrom,praspf2.0/pra,mfrom - 表示驗證郵件傳送人和聲稱負責位址。
  • spf2.0/pra - 表示只驗證聲稱負責位址。

Sender ID的另一項語法差異是,它提供SPF不支援的定位(positional)修飾詞特性。但實際上,到目前為止,還沒有任何Sender ID的實現指定定位修飾詞。

在實踐中,pra(聲稱負責位址)方案通常只在電子郵件合法時提供保護,而在垃圾郵件網路釣魚的情況下不提供真正的保護。最合法的電子郵件pra是熟悉的From:頭欄位,或者郵寄清單中的Sender:頭欄位。但在網路釣魚或垃圾郵件中,pra可能基於通常不向使用者顯示的Resent-*頭欄位。要成為有效的反釣魚工具,需要修改MUA(「郵件代理人」或「郵件客戶端」)以顯示用於Sender ID的pra,或者用於SPF的Return-Path:。

pra嘗試抵制的是網路釣魚問題,而SPF或mfrom嘗試解決的是垃圾郵件退回和其他自動回覆到偽造的回覆位址(Return-Path)的問題。兩個不同的問題要使用不同的解決方案。

標準化問題

編輯

pra的缺點是,轉發器和郵寄清單只能通過修改郵件頭來支援它,例如插入一個SenderResent-Sender。而後者違背RFC 2822並可能與RFC 822不相容。

在使用SPF時,郵寄清單能繼續運作。希望支援SPF的轉發器只需要修改SMTP MAIL FROM(郵件來自)和RCPT TO(回覆至),而不是郵件。這不是新的概念,原始的RFC 821 SMTP轉發器始終將其主機名添加到MAIL FROM中的反向路徑。

最大的問題是,核心Sender ID規範推薦解釋v=spf1策略為如同spf2.0/mfrom,pra而不是spf2.0/mfrom。這在2003年以來發布的所有SPF草案中從未考慮,並且對於未知的大量v=spf1策略、同時有pra和mfrom且不同的許多情況,對pra的評估可能導致錯誤的結果。此問題是向網際網路架構委員會英語Internet Architecture Board(IAB)呼籲的基礎。為回應另一個先前的呼籲,IESG英語IESG已註明Sender ID不能在IETF標準軌道上繼續前進,必須先解決與RFC 2822的不相容。

智慧財產權

編輯

Sender ID提案也是一個涉及智慧財產權授權的話題:微軟持有Sender ID關鍵部分的專利[1][2],並以不相容GNU通用公共許可證的條款許可這些專利,這在一些自由軟體實現英語Implementation中被認為是有問題的。2006年10月23日,微軟將這些專利放置到開放標準承諾英語Open Specification Promise下,這與自由和開源許可證相容,但與GPL許可證3.x版本不相容。

參見

編輯

參考資料

編輯
  1. ^ 存档副本. [2011-12-20]. (原始內容存檔於2012-04-14). 
  2. ^ 存档副本. [2017-02-16]. (原始內容存檔於2017-04-01). 

外部連結

編輯