[ SPF ]

嵌套SPF包括:新增服務之前計算依賴關係

使用評估的路徑評估嵌套SPF依賴關係,而不是僅計算客戶記錄中可見的包含項。

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

[ 重點 ]

  • 共享預算遵循遞歸,而不僅僅是頂級記錄。
  • 早期匹配和不匹配分支會更改評估路徑。
  • 供應商依賴性需要當前的證據和所有權審查。
在此頁面上

短記錄可以隱藏長依賴路徑

僅包含少數包含項目的客戶策略可能依賴它們下面的更多 DNS 引發術語。包括遞歸觸發器 SPF 評估;它不會向每個供應商授予新的獨立津貼。相關限制適用於整個評估。因此,計算客戶的可見包含令牌所回答的問題與確定特定寄件者路徑是否保持在SPF預算之內不同。

本文建議在添加發送服務之前進行依賴性審查。它不建議複製提供者記錄、在不進行維護的情況下扁平化地址或基於假設圖表更改DNS 。首先確定實際發送路由和用於SPF的域。供應商的行銷品牌可能包含多種產品和特定於帳戶的配置。只有適用的受支持指令和當前依賴性證據才應輸入提議的策略。 RFC 7208 ,第 4.6.4 和 5.2 節

計算術語,而不是資料包或唯一供應商

RFC 7208將 include、a、mx、ptr、exists 和 redirect 標識為在評估期間引起DNS查詢的術語,並規定了 10 個的限制。超過該限制必須產生 permerror。 all、ip4 和 ip6 機制以及 exp 修飾符不受此特定限制。這並不意味著策略的所有其他方面都不受限制: MX和PTR處理有額外的規則,無效回應有單獨的指導。

解釋快取行為時請保持語言準確。快取的DNS答案可以減少網路流量,但不會從邏輯預算中刪除評估的機制。計算唯一網域還可以掩蓋重複評估。相反,靜態依賴關係圖可以包括從未到達給定發送方的分支。有用的審查將完整的發現圖與通過它的每個評估路徑區分開來。 RFC 7208 ,第 4.6.4 節

對每個包含的返回進行建模

子傳遞使包含匹配,包含的限定符確定父結果。子失敗、 softfail和中立意味著包含不匹配,因此父級可以繼續。孩子 temperror 和permerror作為錯誤傳播,並且 child none 映射到permerror 。這些映射決定了是否可以達到以後的客戶級服務,從而確定它們的術語是否進入觀察路徑。

不要假設供應商的終端-all不符合整個客戶政策。它可能只是在沒有匹配的情況下結束子評估,並將控制權傳回給父級。同樣,不要因為稍後出現另一個供應商而認為受傷的孩子是無害的。在考慮後面的供應商之前,錯誤可能會終止路徑。在每個依賴邊旁邊顯示子結果和封閉決策。 RFC 7208 ,第 5.2 節

建立特定於路線的依賴關係工作表

從路由清單開始:企業擁有者、應用程式、產品、信封網域、連接位址系列和支援的設定來源。然後為每個評估的策略建立一個節點,並為每個包含或重定向建立一個有序邊。保留準確的TXT邊界和收集時間。沒有底層策略文本的圖表不足以解釋為什麼存在特定邊緣或其順序很重要。

對於每個代表性寄件人,記錄步驟編號、目前領域、機制、擴展目標、累積術語計數、子結果和下一步。識別先前匹配排除的分支。將逾時和無效資訊保留在單獨的列中。將實際觀察到的痕跡與靜態可能性區分開來。兩者都不應該被錯誤地標記為每個接收者行為的完整枚舉。

新增建議變更列,顯示新服務將進入的位置。評估放置的業務原因以及對現有路徑的影響。重新排序可以更改達到的條款,但不能取代消除過時的依賴項或取得受支援的提供者配置。在尋求編輯DNS的授權之前保留回滾所有者和證據計劃。

虛構診斷:後期交易路線

虛構的客戶策略會先檢查供應商 A,然後再檢查供應商 B。對於假設的交易寄件人,A 不會授權該地址。假設 A 的評估分支除了客戶對 A 的包含之外還消耗了 4 個計數項。評估然後達到客戶對 B 的包含,使運行總數達到 6。假設 B 需要進一步計算 5 個術語才能建立配對。提議的路徑將嘗試第十一個計數任期並超過十個任期限制。

這些數字是虛構的教學範例,而不是指定供應商的測量結果。重要的一點是共享運行總計。報告「包含兩個客戶」的儀表板會錯過該問題,而匯總每個可能分支的圖表可能會誇大與 A 內部早期匹配的另一個發件人的路徑。這兩個視圖都需要標籤和上下文。

提議的修復不會自動先移動 B。這可能有助於這條路線,同時將 A 的合法流量轉移到更長的路徑。合理的下一步是識別未使用的依賴項,取得提供者確認的可用替代方案,並比較擬議設計下受影響的路線。這裡沒有聲明更換記錄或成功的重新評估。

制定變革計劃,但沒有承諾永久空間

供應商管理的記錄在審核後可能會發生變化。記錄快照時間和所有權邊界,而不是聲明依賴項計數永久安全。如果存在記錄的變更流程,請追蹤負責的供應商和客戶路線所有者。監控提案應該定義哪些變更是重要的、由誰來審查它們以及何時需要回溯決策,而不是假裝已經部署了監控。

避免簡單化的扁平化建議。以位址複製清單取代維護的依賴關係會改變負責保持授權最新的人員。過時的地址可能會破壞合法郵件或保留授權的時間超過預期。任何替代方案都需要有支援的維護設計、實際路線證據以及對其安全後果的審查。較小的可見記錄並不一定是更安全的策略。

驗收應至少涵蓋受更改影響的路由以及到達後續機制的有意義的不匹配路徑。將不受支援的路由記錄為未解決。目的不是製造綠色分數;而是製造綠色分數。這是為了表明為什麼擬議的政策在適用的評估限制範圍內授權預期的寄件者。

證據和發布狀態

本手稿不包含執行的解析器查詢、提供者帳戶變更或發送的訊息。它的依賴範例是虛構的。所需的原始證據是一條註釋的路徑,顯示每個計數的術語和確切的失敗分支,並且保持開放狀態。沒有實際的提供者確認本文的替換配置。

在發布作業之前,合格的審閱者應驗證目前來源的適用性、路線清單、記錄完整性和建議的變更範圍。原始證據、人工審查、生產路線、視覺可訪問性和所有者發布與來源適用性一起保持開放。將工作表視為授權調查的準備,而不是證明任何真實客戶超出預算的證據。

[ 外帶 ]

在新增服務之前,請檢查代表評估的路徑並為依賴性變更保留空間。

[ 按角色 ]

這對您意味著什麼

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

整合所有者

評估完整路線

新服務可以改變現有的評估路徑。

後續步驟

  1. 確定實際產品和信封域。
  2. 取得支援的配置值。

DNS審核者

遞迴計數

可見include計數不足。

後續步驟

  1. 保留有序的痕跡。
  2. 將邏輯術語與DNS資料包分開。

營運主管

自己的依賴變化

快照不能保證未來的空間。

後續步驟

  1. 為供應商依賴項指派一個擁有者。
  2. 準備經過審查的回滾流程。

[ 常見問題解答 ]

常見問題

嵌套包含是否會獲得單獨的十個期限津貼?

不可以。此限制適用於整個SPF評估,包括遞歸處理。

RFC 7208 :寄件者策略框架

快取查找是否免費?

不會。網路快取不會從邏輯預算中刪除已評估的 DNS 引發項目。

RFC 7208 :寄件者策略框架

ip4和ip6消耗這個預算嗎?

它們不受十個 DNS 造成的期限限制。

RFC 7208 :寄件者策略框架

每個發現的分支都會執行嗎?

不可以。較早的匹配或錯誤可能會停止評估。

RFC 7208 :寄件者策略框架

孩子失敗了怎麼辦?

它使包含不符;家長可以繼續。

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 :寄件者策略框架

子結果
映射到的遞歸結果包括匹配或錯誤處理。

RFC 7208 :寄件者策略框架

航線庫存
選擇進行策略審查的擁有的發送工作流程。

企業出處

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

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

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

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

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

知識庫