在过去的六个月里，我一直在与 Spamhaus CSS SBL 斗争，必须定期检查我的 Exim4 服务器的 IPv6 地址是否已列出，如果已列出，则手动将其除名。上周我终于承认失败，并将我的 SAAS 应用程序从使用自我管理（且配置良好）的 Exim4 服务器切换到 Mailgun。“配置良好”是指它具有 SPF、DKIM 和 DMARC 记录，发送格式良好的多部分电子邮件，具有列表取消订阅标头等。所有所谓的“最佳实践”。
CSS SBL 应该列出“showshoe”垃圾邮件发送者，这意味着运营商从多个 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 块中的人发送的，而您也被阻止。
如果它列出了较小的块，则列表将是
使用/64块的选择大致跟踪了当今行业中的常见情况——一个/64通常是一个客户。这个等式在 5 年前并非总是如此——但现在afaik已成为行业标准。
有关该决定的更详细和权衡的讨论，在 spamhaus 网站上有一篇关于它的冗长声明：“Spamhaus IPv6 阻止列表策略声明”
您的情况可能的解决方案：
a) 询问您的托管服务提供商
您的托管服务提供商可能会也可能不会毫不费力地为您分配一个更大的（至少 /64）块（Linode常见问题中提到添加 IP），因为分配您的（较小）块很可能只有历史原因——（到目前为止） ，仍然只是粗略的）关于每个客户使用 /64 的共识只有 2 年，在此之前，许多托管服务提供商只是分配了他们认为合适的任何东西 - 结果大相径庭。我的经验：许多托管服务提供商在没有我询问的情况下（几年前）就向我提供了前缀大小的更改。
b) 更改您的托管服务提供商
如果您的托管服务提供商无法遵循行业标准 - 并且无法证明这样做的合理性（我认为没有很好的解释，IPv6 地址空间并不完全稀缺），请质疑他们的动机。如果托管服务提供商故意分配小的 IPv6 块——例如确保合法邮件和垃圾邮件混在一起（这是Spamhaus人在使用“雪鞋操作”等术语时所关心的问题）——是时候运行了。