[ SPF ]

SPF permerror :區分過多的查找和格式錯誤的策略

在提出更正建議之前,將SPF語法和記錄選擇失敗與過多的評估預算分開。

由EmailAuth研究團隊提供 · 7 分鐘閱讀

[ 重點 ]

  • Permerror 是一個結果類別,而不是完整的根本原因。
  • 畸形的政策和超支的預算需要不同的證據。
  • 修復最早支援的錯誤並保留路由授權。
在此頁面上

結果標籤不是診斷

佩默錯誤 表示永久錯誤 SPF 評估,但它沒有識別出獨特的缺陷。所選策略格式錯誤,多個適用 SPF記錄、缺失的遞歸策略或超出的評估限制可以透過不同的規則產生此結果。將每個permerror轉換為「太多DNS查找」的支援回應可能會導致管理員進行錯誤修復,並可能損害有效的寄件者授權。

首先保留用於評估的身份和輸入。記錄連接地址, HELO 或者 郵件來自 上下文、評估域、發送者參數和時間。然後保留實際的DNS響應和選擇的SPF策略。如果沒有這些輸入,兩份不同的報告可能涉及不同的身分或不同的快照,而不是對同一政策有分歧。 RFC 7208 ,第 2.3、2.4 和 8.7 節

首先檢查記錄選擇和語法

SPF策略的選擇有特定的規則。多個選擇的SPF記錄會導致permerror ;它們沒有合併到更大的政策中,也不應該被視為劃分供應商的便捷方式。一筆記錄中的TXT字串與多個獨立記錄是不同的。保留記錄邊界,以便審閱者可以區分演示細節和實際選擇問題。

文法還需要進行全面的策略審查。 RFC 7208要求在機制評估之前進行語法檢查;因此,即使有人期望早期的機制能夠匹配,無效的機制也可能很重要。無法辨識的機制和忽略的無法辨識的修飾符不是可以互換的類別。避免使用模糊的指導來刪除每個不熟悉的標記。在決定它是否是錯誤之前,先確定它的語法角色和標準的處理方式。 RFC 7208 ,第 3.2、4.5、4.6 和 6 節

然後將評估-預算失敗進行分類

對於總體 DNS 導致項目預算,請在評估期間包含 a、mx、ptr、exists 和重定向計數。這個限制是十,超過它一定會產生permerror 。這不僅僅是DNS資料包的數量、頂級包含的數量或唯一供應商的數量。遞歸共享預算,且快取不會刪除邏輯評估的術語。

其他限制需要有自己的標籤。無效回應的「應該」等級限制為 2,允許配置,並且在可設定時建議預設為 2;超過適用的限制會產生permerror 。 MX處理具有額外的強制約束。 「記錄只有九個包含」的聲明並不排除這些其他原因,而高原始資料包計數本身並不能證明超出了總體十項限制。 RFC 7208 ,第 4.6.4 節

將錯誤結果與授權結果分開

失敗斷言客戶端無權使用所評估的身份。 Permerror 意味著由於永久性錯誤,評估無法產生預期的授權結果。 溫度錯誤 代表暫時性錯誤。 None 也是一個不同的結果,當透過包含或重定向遇到時具有特殊的映射。在解釋糾正措施時,這些標籤不應折疊到單一「 SPF失敗」桶中。

接收方仍然會根據自己的策略決定如何處理結果。被拒絕的郵件無法確定哪個SPF缺陷導致了拒絕,除非有證據支持連結。同樣,接受的郵件並不能證明該政策是有效的。將身份驗證診斷和交付配置放在不同的欄位中,並避免承諾一次DNS修復即可解決所有交付問題。 RFC 7208 ,第 5.2、6.1 和 8 節

具有明確停止原因的分類工作表

使用分為選擇、解析和評估的工作表。選擇時,保留查詢名稱、回應、 TXT記錄 所選SPF所記錄的邊界和計數。在解析時,保留準確的串聯記錄文字、解析器版本、違規標記(如果有)以及違反的規則。在保留原始證據之前,不要將錯誤歸一化。

在評估中,記錄每個達到的機製或修飾符、當前域、擴展目標、累積術語計數、反應分類、遞歸子結果和繼續決策。保持無效總數和補充限制不同。標記第一個支援的停止原因。如果解析器在評估之前拒絕了策略,請勿僅僅為了證明另一個可能的問題而發明評估器從未執行過的路徑。

擬議的更正應列出其解決的缺陷、確認預期授權的所有者以及必須仍然有效的路線。單獨記錄未解決的次要發現。格式錯誤的策略也可能包含過多的依賴圖,但調查人員應解釋觀察到的結論以及在有效評估之前仍存在靜態問題。

虛構診斷:兩個相同的標籤,不同的修復

在虛構的案例 A 中,網域發布了兩筆單獨的TXT記錄,它們都符合SPF策略的資格。有用的診斷是記錄選擇錯誤,而不是過多的查找計數。建議的修復需要在確認所有合法路由後將預期授權調整為一項支援的策略。刪除任意記錄可能會默默刪除所需的服務。對於這種情況,沒有收集到真正的DNS回應或更正。

在虛構的情況 B 中,語法上有效的策略遵循一個嵌套路由,該路由在任何匹配之前嘗試第十一個計數的 DNS 引發術語。有用的診斷是超出了總體預算。組合TXT字串無法解決該問題,因為該策略已經是選定的記錄。相反,審查需要準確的依賴路徑和支援的重新設計以保留寄件者覆蓋範圍。

第三份虛構報告只說“ permerror ”,不包含任何記錄快照或追蹤。正確的結果是證據不足,而不是A和B之間的猜測。透過授權管道要求最小化診斷包,排除私人訊息內容和不必要的地址。這些場景是概念比較,而不是執行的固定裝置、接收器​​結果或指定提供程序配置錯誤的證據。

接受和發布標準

修復索賠的範圍應小於「 SPF已修復」。說明記錄選擇、語法、特定評估路徑或特定供應商依賴性是否已更正,以及支持該聲明的證據。驗證提議的變更不會授權非預期寄件者或排除合法寄件者。除非單獨觀察,否則將收件人的最終交付結果保留在索賠之外。

對於此草案,顯示每個計數術語和確切失敗分支的所需註釋路徑仍然懸而未決。如果實際問題是解析或選擇,也請保留主要證據,並對其如何滿足文章的預期範圍進行人工審查。不要為在處理機制之前停止的錯誤建立評估路徑。

這裡沒有執行掃描、解析器執行、 DNS修改或訊息測試。原始證據、人工審查、來源適用性、生產路線、視覺可及性和所有者發布仍然開放。這份手稿提供了一個分類框架和虛構的推理範例,同時明確拒絕任何完整的操作診斷的主張。

[ 外帶 ]

在呼叫SPF permerror修復之前附加確切的失敗分支或解析證據。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

支援工程師

處方前分診

僅憑結果標籤無法辨識修復情況。

後續步驟

  1. 請求記錄邊界和準確輸入。
  2. 單獨的語法和路徑證據。

DNS擁有者

保留授權

消除缺陷不能盲目地消除合法服務。

後續步驟

  1. 確認預期的寄件者覆蓋範圍。
  2. 審查建議的更改和回滾。

獨立評審員

驗證因果關係

一條路線的綠色結果並不是普遍正確的。

後續步驟

  1. 檢查第一個支援的停止原因。
  2. 單獨證明交付結果。

[ 常見問題解答 ]

常見問題

每個permerror是否都代表過多的尋找?

不會。選擇、語法、遞歸策略和評估限制錯誤可能會產生permerror 。

RFC 7208 :寄件者策略框架

接收者可以合併兩筆SPF記錄嗎?

不會。選擇多個SPF記錄會導致permerror 。

RFC 7208 :寄件者策略框架

TXT區塊是否獨立於SPF記錄?

未必。一筆TXT記錄中的多個字串與多筆記錄不同。

RFC 7208 :寄件者策略框架

可以忽略預期匹配後的語法錯誤嗎?

不可以。該標準要求在評估之前進行語法檢查。

RFC 7208 :寄件者策略框架

未知的機制和修飾符的處理方式是否相同?

不能。無法辨識的機制會導致錯誤,而根據指定的規則會忽略無法辨識的修飾符。

RFC 7208 :寄件者策略框架

permerror是否意味著寄件者未經明確授權?

否。失敗是明確的未經授權的結果; permerror是一個獨特的評估錯誤。

RFC 7208 :寄件者策略框架

比較案例是否執行?

不。它們是虛構的解釋性案例,沒有原始查詢或測試記錄。

什麼支持已完成的維修索賠?

仍需要原始錯誤證據、批准的更正和範圍驗證;這裡沒有提供任何執行結果。

[ 來源 ]

來源

  1. RFC 7208 :寄件者策略框架

    部分 §2.3 HELO身分 · §2.4 來自身分的郵件 · §3.2 多個DNS記錄 · §3.3 單一DNS記錄中的多個字串 · §4.5 選擇記錄 · §4.6 記錄評估 · §4.6.4 DNS限制 · §5.1 「全部」 · §6.1 重定向:重定向查詢 · §8 結果處理 · §8.4 失敗 · §8.7 權限錯誤 · §10 對基礎設施的影響

[ 詞彙表 ]

詞彙表

佩默錯誤
SPF永久錯誤結果,需要進一步的證據來確定其原因。

RFC 7208 :寄件者策略框架

選擇失敗
確定適用的SPF記錄時發生錯誤,例如多個選定的策略。

RFC 7208 :寄件者策略框架

文法證據
保留的原始策略和精確的語法錯誤支援解析診斷。
停止原因
第一個支持的終止正在檢查的評估的條件。

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫