複製鏈接
請複製以下鏈接發送給好友
https://baike.baidu.hk/item/發送方策略框架/381991
複製
複製成功

發送方策略框架

鎖定
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
屬    性
一個防偽標準
用    途
防止偽造郵件地址

目錄

  1. 1 簡介
  2. 2 需求

發送方策略框架簡介

事實上，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 的優點有很多。不過，像我對一些人所説的，這不是一夜之間就可以達到的，SPF 的好處將通過日積月累來表現出來，當其他人都使用它的時候就能明顯地看到了。
我也提到了 Sender ID，這和 SPF 有關，但我沒有去解釋它。可能你已經知道原因了，微軟的策略一向如此---軟件專利。在參考文獻中，你可以看到 openspf.org 對於 Sender ID 的立場聲明。