Sender ID

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
互聯網安全協議（英語：Internet security）
密鑰管理
應用層
域名系統
網絡層

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,pra 或 spf2.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的缺點是，轉發器和郵件列表只能通過修改郵件頭來支持它，例如插入一個Sender或Resent-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）. 

外部連結[編輯]

取自「https://zh.wikipedia.org/w/index.php?title=Sender_ID&oldid=68867172」