SPF 是傳送方策略框架 (Sender Policy Framework) 的縮寫，希望能成為一個防偽標準，來防止偽造郵件地址。這篇文章對 SPF 進行了簡單介紹，並介紹了它的一些優點和不足。
SPF 誕生於2003年，它的締造者 Meng Weng Wong 結合了反向 MX 域名解析(Reverse MX) 和 DMP (Designated Mailer Protocol) 的優點而付予了 SPF 生命。
SPF 使用電子郵件頭部信息中的 return-path (或 MAIL FROM) 欄位，因為所有的 MTA 都可以處理包含這些欄位的郵件。不過微軟也提出了一種叫做 PRA (Purported Responsible Address)的方法。PRA 對應於 MUA (比如 thunderbird) 使用的終端用戶的地址。
這樣，當我們把 SPF 和 PRA 結合起來的時候，就可以得到所謂的“Sender ID”了。Sender ID 允許電子郵件的接收者通過檢查 MAIL FROM 和 PRA 來驗證郵件的合法性。有的說法認為，MAIL FROM 檢查由 MTA 進行，而 PRA 檢查由 MUA 來完成。
基本介紹
- 中文名：傳送方策略框架
- 外文名：Sender Policy Framework
- 屬性：一個防偽標準
- 用途：防止偽造郵件地址
簡介,需求,
簡介
事實上，SPF 需要 DNS 以某種特定的方式來工作。也就是必須提供所謂的“反向 MX 解析”記錄，這些記錄用來解析來自給定域名的郵件對應的傳送主機。這和目前使用的 MX 記錄不同，後者是用來解析給定域名對應的接收郵件的主機的。
需求
SPF 有哪些需求？
要想用 SPF 來保護你的系統，你必須：
配置 DNS，添加 TXT 記錄，用於容納 SPF 問詢的信息。
配置你的電子郵件系統(qmail, sendmail)使用 SPF，也就是說對伺服器上每封進入的郵件進行驗證。
上述第一步要在郵件伺服器所屬的域名伺服器上進行調整，下一節中，我們將討論這個記錄的細節內容。你首先需要確定的一點是你的域名伺服器(bind，djbdns)所使用的語法。但別擔心，SPF 的官方網站提供了一個很好用的嚮導來指導你如何添加記錄。
SPF 的 TXT 記錄
SPF 記錄包含在一個 TXT 記錄之中，格式如下：
v=spf1 [[pre]type [ext] ] ... [mod]
每個參數的含義如下表所示： 參數 描述
v=spf1 SPF 的版本。如果使用 Sender ID 的話，這個欄位就應該是 v=spf2
pre 定義匹配時的返回值。
可能的返回值包括： 返回值 描述
+ 預設值。在測試完成的時候表示通過。
- 表示測試失敗。這個值通常是 -all，表示沒有其他任何匹配發生。
~ 表示軟失敗，通常表示測試沒有完成。
? 表示不置可否。這個值也通常在測試沒有完成的時候使用。
type 定義使用的確認測試的類型。
可能的值包括： 候選值 描述
include 包含一個給定的域名的測試
以 include:domain 的形式書寫。
all 終止測試序列。
比如，如果選項是 -all，那么到達這條記錄也就意味著測試失敗了。但是如果無法確定，可以使用"?all"來表示，這樣，測試將被接受。
ip4 使用 IPv4 進行驗證。
這個可以以 ip4:ipv4 或 ip4:ipv4/cidr 的形式使用。建議使用這個參數，以減少域名伺服器的負荷。
ip6 使用 IPv6 進行驗證。
a 使用一個域名進行驗證。
這將引起對域名伺服器進行一次 A RR 查詢。
可以按照 a:domain, a:domain/cidr 或 a/cidr 的形式來使用。
mx 使用 DNS MX RR 進行驗證。
MX RR 定義了收信的 MTA，這可能和發信的 MTA 是不同的，這種情況基於 mx 的測試將會失敗。
可以用 mx:domain, mx:domain/cidr 或 mx/cidr 這些形式進行 mx 驗證。
ptr 使用域名伺服器的 PTR RR 進行驗證。
這時，SPF 使用 PTR RR 和反向圖進行查詢。如果返回的主機名位於同一個域名之內，就驗證通過了。
這個參數的寫法是 ptr:domain
有什麼需要擔心的?
SPF 是一個對於欺騙的完美保護。但它有一個局限：傳統的郵件轉發方式不再有效了。你不能僅僅從你的 MTA 接受郵件並簡單地重新傳送它了。你必須重寫傳送地址。常見的 MTA 的補丁可以在 SPF 的網站找到。換句話說，如果你把 SPF 記錄加入到了域名伺服器，你就必須更新你的 MTA 來進行傳送地址改寫，即使你還沒有對 SPF 記錄進行檢查。
exist 驗證域名的存在性。
可以寫成 exist:domain 的形式。
ext 定義對 type 的可選擴展。如果沒有這個欄位，那么僅使用單個記錄進行問詢。
mod 這是最後的類型指示，作為記錄的一個修正值。
修正值 描述
redirect 重定向查詢，使用給出的域名的 SPF 記錄。
以 redirect=domain 的方式使用。
exp 這條記錄必須是最後一條，允許給出一條定製的失敗訊息。
IN TXT "v=spf1 mx -all exp=getlost.example.com"
getlost IN TXT "You are not authorized to send mail for the domain"
嘿！我是 ISP
ISP 實施 SPF 可能對於他們處於漫遊狀態(roaming)的用戶帶來一些麻煩，當這些用戶習慣使用 POP-before-Relay 這樣的方式處理郵件，而不是 SASL SMTP 的時候問題就會出現。
嗯，如果你是一個被垃圾郵件、地址欺騙所困擾的 ISP 的話，你就必須考慮你的郵件策略、開始使用 SPF 了。
這裡是你可以考慮的幾個步驟。
首先設定你的 MTA 使用 SASL，比如，你可以在連線埠 25 和 587 使用它。
告訴你的用戶你已經使用了這個策略(spf.pobox.com 給出了一個通知的例子，參見參考文獻)。
給你的用戶一個寬限期，也就是說，把你的 SPF 記錄加入到域名伺服器之中，但使用“軟失敗”(~all)而不是“失敗”(-all)。
這樣，你就保護了你的伺服器、你的客戶和整個世界免受垃圾郵件之類的困擾了。
SPF 的官方站點上有很多信息，還等什麼呢？
有什麼需要擔心的?
SPF 是一個對於欺騙的完美保護。但它有一個局限：傳統的郵件轉發方式不再有效了。你不能僅僅從你的 MTA 接受郵件並簡單地重新傳送它了。你必須重寫傳送地址。常見的 MTA 的補丁可以在 SPF 的網站找到。換句話說，如果你把 SPF 記錄加入到了域名伺服器，你就必須更新你的 MTA 來進行傳送地址改寫，即使你還沒有對 SPF 記錄進行檢查。
結論
你可能覺得 SPF 的實施有點難以理解。不過這確實不算複雜，而且還有一個不錯的嚮導來幫你完成這個轉換(參見參考文獻)。
SPF 的優點有很多。不過，像我對一些人所說的，這不是一夜之間就可以達到的，SPF 的好處將通過日積月累來表現出來，當其他人都使用它的時候就能明顯地看到了。
我也提到了 Sender ID，這和 SPF 有關，但我沒有去解釋它。可能你已經知道原因了，微軟的策略一向如此---軟體專利。在參考文獻中，你可以看到 openspf.org 對於 Sender ID 的立場聲明。
