基本介紹
- 外文名：Sender ID
- 性質：反欺騙協定
- 定義：主要定義在實驗性RFC 4406
- 來源：SPF
- 領域：網路安全
操作原理,標準化問題,智慧財產權,
操作原理
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中的反向路徑。
