SPF HELO Identity 有什麼好處

我試圖了解 RFC7208 (SPF) 中定義的 HELO 身份的好處。

有一個郵件伺服器，比如說mail.example.com。該伺服器用作不同域的中繼。

在第 2.4 節中：

如果“HELO”檢查尚未執行或未通過將 check_host() 函式應用於“MAIL FROM”身份作為 <sender>，SPF 驗證者必須檢查“MAIL FROM”身份。

我了解，如果 HELO 已通過，則無需查看 MAIL FROM。

2.3 節類似：

選中“HELO”可以提高結果的一致性，並可以減少 DNS 資源的使用。如果可以基於對“HELO”的檢查做出關於消息的最終確定，則可以避免使用 DNS 資源來處理通常更複雜的“MAIL FROM”。

這不會導致未經檢查的 MAIL FROM 身份嗎？

問候，亞歷克斯

一些可能的用途：

• 您可以提前拒絕失敗的 HELO 身份。由於HELOSMTP 命令發生在對話的早期，您可以拒絕fail立即評估為的 HELO 身份。（我在我自己的郵件主機上使用它，看到很多聲稱自己是這個郵件主機的客戶很早就被拒絕了。）
• 您可以同時評估 HELO 身份和 MAIL FROM 身份，並使用兩者來貢獻一些合法性“分數”。例如，您可以為 HELO和MAIL FROM 身份評估為的發件人分配更多信任pass。
• 如果您對 HELO 身份感到滿意，您可以決定跳過對 MAIL FROM 身份的評估，或者pass作為快捷方式，可以這麼說：如果您對 MAIL FROM 不感興趣，則不必檢查它*。但是請注意，HELO 身份很容易被偽造，就像 MAIL FROM 身份一樣（發件人可以發送他們喜歡的任何內容），因此通常您會對*MAIL FROM 身份感興趣（並可能將其輸入 DMARC 組件）。fail``softfail

這一切都取決於您的要求。它還取決於您的 SPF 實現允許什麼（我自己的實現SPF Milter支持以上所有內容）。

在實踐中，將 HELO 身份視為主要對負面結果有用（fail, softfail, permerror）而不是正面結果（pass）可能會有所幫助。當郵件伺服器檢查 HELO 身份並遇到否定結果時，它可以立即結束對話或將否定的 HELO 結果作為最終的 SPF 結果記錄在標頭中。在這樣的策略下，MAIL FROM 身份確實不需要在這些情況下進行評估。這樣的政策確實會導致上述 DNS 資源的減少，因此我看到了提供和檢查 SPF HELO 身份的直接實際好處。

引用自：https://serverfault.com/questions/1062518