[ 地區要求 ]

衡量MTA-STS採用率和策略主機可用性

使用可重現的資料集和錯誤統計量分別測量MTA-STS發現、策略有效性和 HTTPS 可用性。

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

[ 重點 ]

  • 在計算域之前定義採用類別。
  • 保留DNS發現、HTTPS 擷取和MX相容性作為單獨的證據。
  • 探測中斷不會建立每個發送方的快取策略行為。
在此頁面上

將採用率和可用性定義為單獨的衡量標準

MTA-STS 採用可以指DNS發現、語法上有效的策略檢索、強制模式的發佈或觀察到的與域接收MX路由的兼容性。策略主機可用性是另一個屬性:它涉及 HTTPS 端點在觀察時是否可存取且有效。研究應該單獨定義這些措施,而不是將一次成功的獲取視為完整的傳輸安全採用。

RFC 8461 定義MTA-STS發現、策略檢索、驗證和快取。它支援可重複的測量設計,而不是資料集存在的斷言。本文不包含網域掃描、可用性百分比、連線測試或縱向調查結果。所有範例均明確為假設。

建立接收域人口

MTA-STS涉及接收域的郵件路由。網站、出站寄件者品牌或客戶組織的清單不會自動成為適當的接收域清單。收集前明確單位、選擇方法及排除情況。記錄範例是否包含沒有可用郵件路由的網域以及這些情況如何影響每個指標,而不是默默地刪除它們。

凍結輸入清單並保留其來源、日期、規範化規則和雜湊值。如果清單在運行之間發生變化,請保留成員資格歷史記錄。進入或離開樣本的網域可以改變明顯的採用情況,而無需對其策略進行任何更改。除非抽樣設計支持該推論,否則不要將便利樣本稱為全域估計。本手稿沒有提供這樣的估計。

將DNS發現與 HTTPS 檢索分開

RFC 8461定義了_mta-sts擁有者處的發現記錄以及 mta-sts 主機下眾所周知路徑的策略檢索位置。發現標識符表示策略發生變化;它不是證書指紋或端點當前工作的證明。記錄DNS答案、擁有者、解析器和時間,與後續 HTTPS 觀察值無關。

此標準要求 HTTP 200 OK 進行策略檢索,並規定寄件者不得在該檢索過程中遵循 HTTP 重定向。它也表示傳送者不得使用 HTTP 快取進行策略檢索,這與MTA-STS策略快取不同。該方法應該保留回應狀態和重定向行為,而不是接受任何看起來成功的瀏覽器目標。在此工作期間未取得端點或遵循重定向。

根據規定的規則驗證策略和連接

此策略包含RFC 8461語法下的版本、模式、 MX模式和最大期限。保留實際位元組和解析器版本。使用測試模式的策略與強制模式不是同一測量類別。無策略是另一種應該被命名而不是歸入通用採用計數的狀態。使用標準的要求強度報告內容類型處理:發送者應該驗證文本/純文本,而不是發明一個通用的更強的要求。

HTTPS 憑證驗證是一個單獨的觀察。記錄請求的主機名稱、端點、時間和實際驗證結果。網路故障、憑證故障、意外狀態和格式錯誤的策略具有不同的意義,應在錯誤日誌中單獨保留。不要因為一個觀察位置無法到達某項策略而推斷該策略不存在,也不要忽略連接錯誤以產生更大的採用分子。

將策略模式與預期MX路由進行比較

語法上有效的策略仍然可以描述錯誤的接收主機。 RFC 8461定義了MX主機名稱和通配符模式的精確匹配。通配符並不是名稱中任意位置的不受限制的通配符。此方法必須實現標準定義的語法和匹配。保留測量範圍內每個主機的MX觀測值和匹配決策。

單獨的 HTTPS 取得並不能確定每個MX端點都提供與政策相符的有效TLS服務。如果研究未執行授權的SMTP觀察,請說明未測量路由相容性。如果稍後的測試獲得批准,請將其連接證據和人口與策略主機可用性分開。不要僅透過DNS和 HTTP 來實現端到端執行。

考慮快取的策略行為

寄件者可以在協議規定的最長期限內保留MTA-STS策略。因此,臨時策略主機中斷對具有可用快取策略的寄件者的影響可能與首次發現網域的寄件者的影響不同。外部測量探針通常不知道每個發送器的快取狀態。該研究不得將端點停機時間直接轉化為普遍的未受保護郵件時期。

類似地,發現標識符和觀察到的策略版本需要臨時記錄。如果策略在收集過程中發生變化,請保留序列,而不是在沒有解釋的情況下將舊的DNS觀察值加入新的主體。重複測量應記錄探針狀態和任何有意的快取處理。該方法必須將其測量行為與完整發送區分開來 MTA 執行。

收集前設計可用性時間表

提前定義探測位置、節奏、逾時、重試策略和分類規則。失敗一次並重試成功的端點不應從錯誤記錄中消失。使用明確的分母報告嘗試的觀察、成功的觀察和失敗類別。如果排除維護時段或無法到達的有利點,請保留原因並說明排除如何改變結果。

本文並未普遍強加節奏或服務水準目標。選擇適合研究問題和授權的時間表,避免負擔過重。記錄工具版本和依賴項,以便其他分析師可以重現方法。實際可用性結論需要收集數據;建議的時間表並不能證明服務達到或未達到任何目標。

版本化資料集工作表

建立範例版本、接收網域、觀察時間、 DNS發現結果、策略標識符、HTTPS 端點、狀態、憑證結果、內容類型的字段, 正文哈希、解析模式、 MX模式和最大年齡。新增MX觀察參考、配對結果、錯誤類別、重試歷史記錄和排除原因。將原始證據與標準化分類分開保存。

RFC 8460 定義了SMTP TLS報告,當合法可用時可以提供另一個觀點。此類報告並不等同於外部可用性探測,並且不會自動覆蓋每個發送者。如果包含,請分別記錄其來源和範圍。該草案既沒有收集調查,也沒有收集報告,並不意味著它們之間存在確切的相關性。

虛構診斷:端點中斷成為強制執行聲明

一項虛構的研究觀察到一次失敗的 HTTPS 檢索,並將接收域標記為一整天沒有MTA-STS保護。擬議的審查確定了缺失的證據:觀察涵蓋了一個時間和有利位置,並且寄件者可能快取了策略。正確的結論範圍較窄,描述了失敗的檢索及其在測量計劃內的錯誤類別。

該團隊將保留後續觀察結果並報告分母,而不是消除故障或將其推斷為通用郵件行為。這是一個虛構的方法範例,而不是觀察到的中斷或有關命名域的聲明。未執行網路偵測或電子郵件傳送測試。

僅發布可重複的結果

該目錄需要其他分析師可以重現的版本化資料集、查詢方法和錯誤/排除日誌。這些原始文物仍然開放。人類專家審查、來源適用性、生產路線、可訪問性和所有者發布也保持開放。該草案提供了研究設計和虛構的診斷,而不是採用計數、可用性結果或端到端傳輸安全評估。

[ 外帶 ]

在其時間表和範圍內報告政策東道國的觀察結果,而不將其轉化為普遍的運輸保護主張。

[ 按角色 ]

這對您意味著什麼

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

測量工程師

實現定義的檢索

瀏覽器的成功可以隱藏重定向或快取差異。

後續步驟

  1. 需要記錄的 HTTP 結果。
  2. 保留失敗和主體哈希值。

郵件安全分析師

單獨的路線準備

策略語法並不能證明每個MX端點都有效。

後續步驟

  1. 保留MX匹配範圍。
  2. 區分外部探測器和發送者快取。

研究評審員

審核分母

排除和重試可能會改變明顯的可用性結果。

後續步驟

  1. 版本人口和方法。
  2. 保留錯誤和排除日誌。

[ 常見問題解答 ]

常見問題

什麼算MTA-STS採用?

研究必須定義它是否意味著發現、有效策略、執行模式或路由相容性;這些是不同的屬性。

RFC 8461 : SMTP MTA 嚴格傳輸安全

任何 HTTP 成功狀態都足夠嗎?

不可以。 RFC RFC 8461需要 HTTP 200 OK 才能進行政策檢索。

RFC 8461 : SMTP MTA 嚴格傳輸安全

定義的檢索可以遵循重定向嗎?

不可以。此標準規定寄件者不得遵循 HTTP 重定向進行策略檢索。

RFC 8461 : SMTP MTA 嚴格傳輸安全

HTTP 快取與MTA-STS策略快取相同嗎?

不可以。此標準禁止使用 HTTP 快取進行檢索,同時單獨定義保留的策略行為。

RFC 8461 : SMTP MTA 嚴格傳輸安全

text/plain 是否具有通用的 MUST 驗證強度?

RFC 規定發送者應該驗證媒體類型。在方法中保留該要求強度。

RFC 8461 : SMTP MTA 嚴格傳輸安全

一次失敗的提取是否證明所有郵件都不受保護?

不會。觀察是有範圍的,發送者可以使用自己的狀態快取策略。

RFC 8461 : SMTP MTA 嚴格傳輸安全

TLS報告會取代外部偵測器嗎?

不會。 RFC RFC 8460報告是一個不同的觀察源,具有自己的覆蓋範圍和語義。

RFC 8460 : SMTP TLS報告

是否衡量了採用率或可用性結果?

不會。版本化資料集、查詢方法和錯誤/排除日誌保持開啟狀態。

[ 來源 ]

來源

  1. RFC 8461 : SMTP MTA 嚴格傳輸安全

    部分 §3.1 MTA-STS TXT記錄 · §3.2 MTA-STS策略 · §3.3 HTTPS 策略取得 · §4.1 MX主機驗證 · §5 策略應用 · §8.1 策略更新

  2. RFC 8460 : SMTP TLS報告

    部分 §3 報告政策 · §4 報告架構 · §5 報告交付

[ 詞彙表 ]

詞彙表

策略主機可用性
在聲明的時間表下觀察到的 HTTPS 策略端點的可及性和有效性。
發現標識符
用於表示策略變更的MTA-STS DNS標識符,而不是證書指紋。

RFC 8461 : SMTP MTA 嚴格傳輸安全

策略緩存
發送方保留的MTA-STS策略狀態由協定管理。

RFC 8461 : SMTP MTA 嚴格傳輸安全

錯誤/排除日誌
保留對失敗觀察和遺漏案例的核算並註明原因。

企業出處

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

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

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

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

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

知識庫