在过去的六个月里，我一直在与 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 记录（即没有隐私保护）。
答案1
对遇到类似问题的人提前发出警告： 在你弄清楚发生了什么之前，永远不要在任何垃圾邮件阻止列表中请求解除阻止。这些垃圾邮件阻止列表几乎总是足够聪明，不是随机屏蔽你。他们甚至可能会告诉你，如果你解除屏蔽后再次被列入名单，额外的解除屏蔽请求将产生费用，或者根本不可能实现。
关于 CSS 阻止列表的许多规则都没有公布 - 这是故意的 - 他们不希望垃圾邮件发送者通过绕过规则来避免被阻止。
然而，有一件事是众所周知的，那就是该列表至少包含 /64 个 IPv6 地址块。 这意味着，它们永远不会阻止单个 /128 地址，而是总是一次性完全阻止。这反过来意味着，与您位于同一 /64 块中的人们发送的垃圾邮件也会让您被屏蔽。
如果列出的是较小的区块，那么列表将是
- 非常大（想象一下需要跟踪的可能的 IPv6 地址数量）和
- 很容易被垃圾邮件发送者规避（每次被阻止时他们只需使用新的 IP 即可）。
选择使用 /64 块大致符合当今行业中的普遍情况 - 一个 /64 通常对应一个客户。5 年前，这种情况并非总是如此 - 但AFAIK目前已成为行业标准。
有关该决定的更详细、更有分量的讨论，请参阅 spamhaus 网站上的一份长篇声明：“Spamhaus IPv6 阻止列表策略声明”
针对您的情况可能的解决方案：
a) 询问您的托管服务提供商
您的托管服务提供商可能会或不会毫不费力地为您分配更大（至少 /64）的块（利诺德常见问题解答中提到添加 IP)，因为您 (较小) 块的分配很可能仅出于历史原因 - 关于每个客户使用 /64 的 (到目前为止，仍然只是粗略的) 共识只有 2 年的历史，而在此之前，许多托管服务提供商只是分配了他们认为合适的内容 - 结果大相径庭。我的经验：许多托管服务提供商在我没有询问的情况下就向我提供了前缀大小的更改 (几年前)。
b) 更改托管服务提供商
如果您的托管服务提供商无法遵循行业标准 - 而且无法证明这样做的合理性（我不认为有很好的解释，IPv6 地址空间并不稀缺），请质疑他们的动机。如果托管服务提供商故意分配较小的 IPv6 块 - 例如，为了确保合法邮件和垃圾邮件混在一起（这就是垃圾邮件屋人们在使用“雪鞋操作”等术语时很担心）——该跑了。