當 IP 最近沒有發送電子郵件時，為什麼 Spamhaus 會繼續向 CSS 添加 IP？
在過去的六個月裡，我一直在與 Spamhaus CSS SBL 進行鬥爭，不得不定期檢查我的 Exim4 伺服器的 IPv6 地址是否已列出，如果有，則手動將其刪除。上週我終於承認失敗，並將我的 SAAS 應用程序從使用自我管理（且配置良好）的 Exim4 伺服器切換到 Mailgun。“配置良好”是指它具有 SPF、DKIM 和 DMARC 記錄，發送格式良好的多部分電子郵件，具有列表取消訂閱標頭等。所有所謂的“最佳實踐”事物。
CSS SBL 應該列出“雪鞋式”垃圾郵件發送者，這意味著運營商從多個 IP 地址發送少量電子郵件。好吧，首先，SAAS 域的電子郵件只來自這個地址，所以我不確定他們的算法如何斷定這是一次雪鞋式垃圾郵件操作，但無論如何……
雖然 SAAS 應用程序現在通過 Mailgun 發送所有電子郵件，但我讓 Exim4 執行，以防機器上的其他服務需要向我的支持電子郵件地址發送電子郵件。從那時起，Exim4 伺服器向我的支持電子郵件地址發送了大約五封非常溫和的電子郵件，該地址託管在執行 Postfix 的自我管理的 Ubuntu 機器上，並且沒有安裝任何反垃圾郵件模組（所以我知道它不是與 Spamhaus 交談）。
儘管如此，Exim4 伺服器的 IP 幾乎每天都繼續在 CSS SBL 中列出。更令人困惑的是，即使沒有發送電子郵件，IP 地址也會被列出！例如，我昨天刪除了該 IP 地址，今天早上（大約 20 小時後）檢查時，它已被重新列出。我檢查了 Exim4 日誌，在那段時間裡沒有發出一封電子郵件。
那麼有人知道為什麼 IP 地址會繼續列在 CSS SBL 中，即使基本上沒有從該地址發送電子郵件？
我應該補充一點，IP 地址已在該伺服器上使用了三年多，DNS 在 Linode 上，域名在 GoDaddy 註冊，具有可公開訪問的真實 whois 記錄（即沒有隱私保護）。
提前警告遇到類似問題的人： 在弄清楚發生了什麼之前，切勿在任何垃圾郵件阻止列表中請求解除阻止。那些垃圾郵件阻止列表幾乎總是足夠聰明，不會隨機阻止您。他們甚至可能會告訴您，如果您取消阻止然後再次上架，額外的取消阻止請求將產生費用或根本不可能。
有許多關於 CSS 阻止列表的規則未發布 - 故意 - 他們不希望垃圾郵件發送者通過繞過規則來避免被阻止。
然而，眾所周知並發布的一件事是，該列表至少包含 IPv6 的 /64 塊。 這意味著，它們永遠不會阻塞單個 /128 地址，它們總是會一次命中一個完整的塊。反過來，這意味著與您在同一 /64 塊中的人發送的垃圾郵件也會使您被阻止。
如果它列出較小的塊，則列表將是
- 非常大（想像一下要跟踪的可能 ipv6 地址的數量）和
- 垃圾郵件發送者很容易繞過（他們每次被阻止時都可以使用新的 IP）。
使用 /64 塊的選擇大致跟踪了當今行業中的常見情況——一個 /64 通常是一個客戶。5 年前，這個等式遠非總是如此——但afaik現在是行業標準。
有關該決定的更詳細和權衡的討論，在 spamhaus 網站上有一個關於它的冗長聲明：“Spamhaus IPv6 Blocklists Strategy Statement”
您的情況可能的解決方案：
a) 詢問您的託管服務提供商
您的託管服務提供商可能會或可能不會毫不費力地為您分配更大（至少 /64）塊（Linode常見問題解答提到添加 IP），因為您的（較小）塊的分配很可能僅具有歷史原因 - （到目前為止，仍然只是粗略的）對每個客戶使用 /64 的共識只有 2 年之久，在此之前，許多託管服務提供商只是分配了他們認為合適的任何東西——結果大相徑庭。我的經驗：許多託管服務提供商在我沒有詢問的情況下就向我提供了前綴大小的更改（幾年前）。
b) 更改您的託管服務提供商
如果您的託管服務提供商無法遵循行業標準 - 並且也無法證明這樣做是合理的（我不認為有一個很好的解釋，IPv6 地址空間並不完全稀缺），請質疑他們的動機。如果託管服務提供商故意分配小的 IPv6 塊——例如，確保合法郵件和垃圾郵件混淆（這是Spamhaus人員在使用“雪鞋式操作”之類的術語時所關心的）——就該執行了。