我们使用 Office 365 作为主要邮件提供商。我们有一个内部邮件服务器，用于中继来自 SSRS 的报告、旧扫描仪的扫描到收件箱等。它是服务器 2008R2 上的 IIS SMTP。此服务器不会通过防火墙暴露任何服务，当然也不会暴露 SMTP，并且连接和中继仅限于我们网络上使用它作为中继的少数内部 IP 地址。我们之所以使用它，是因为并非我们使用的每台设备都能直接使用 Office 365 服务（我们是非营利组织，我们的一些旧设备确实相当老旧），以及我们制造过程中的过程控制设备，这些东西不允许使用经过身份验证/TLS SMTP，长话短说，该系统为本地网络提供了一些基本便利，我们没有理由不能使用这些便利。我们采取了所有预防措施，我们有正确的服务器 DNS 条目。我为其 IP 设置了 SPF 记录，服务器在交付时公布的名称解析为其公共 IP。在这种配置下，一切都运行良好超过 1.5 年（自迁移到 Office 365 以来），没有任何问题。
突然有一天，所有来自它的邮件开始被拒绝，通过代理列入 spamhaus 和 CBL.abuseat，spamhaus 表示他们通过 CBL 条目的代理列出，CBL 表示我们因发送“大量垃圾邮件”而被列入名单，他们引用该服务器的 DNS 名称作为来源。除非使用心灵感应协议，否则我们平均每天发送约 60 封电子邮件，从未超过 100 封，而且我现在已经捕获了超过三个月的流量，其中没有一条消息不是来自已知来源，也不是发往我们通常发送的地址（其中 99% 都是内部地址！）所以除了“帮助页面”对所有潜在原因的长篇大论之外，我们可能如何受到攻击，如何扫描我们甚至没有运行的服务中的感染，等等……我们毫无疑问地证实了这一说法是错误的，我们已使用 Wireshark 从镜像交换机端口监控了往返于该机器的所有网络流量，我们已在边界防火墙监控了所有流量，我们的 ISP 也已从他们那边确认了这一点，我们根本没有发送任何我们明确希望发送的邮件。从那台机器或这个 IP 地址。然而，这已经是我必须向他们处理的第四次删除请求了。我设法从他们的系统收到了两封电子邮件，因为我正在请求他们声称由我们发送的邮件样本，一封是他们“帮助页面”的逐字副本和对相关 IP 的请求，另一封是一些措辞像机器人一样的简短回复，署名为“Murray”，毫无帮助。似乎其中一个是对第一个 IP 请求的预设回复，说明它已提交删除。
我们联系了微软，发现他们的连接过滤发生在我们的管理员控制之前，这意味着如果 IP 信誉过滤器在达到该级别之前断开我们的连接，设置“批准发件人”是没有意义的。所以我们不能将自己列入白名单。他们声称对使用该服务不负任何责任，或者它以我们都无法修改的方式控制我们的付费服务和我们的业务网络之间的邮件流。我们唯一能想到的是或许扫描到收件箱的邮件之一被转发到某个过分热心的垃圾邮件过滤器，而我们被标记为链条中的传输方法。所以我陷入了困境，无计可施，我无法让 abuseat 采取行动，我无法让微软让步，我有证据表明我们被错误列出，并且没有相反的证据可以进一步调查，除了开始更改我的公共 IP 和所有依赖于它的服务之外，我完全不知道该做什么。我过去曾处理过开放中继保护，并清理了其后果，但这一次绝对是假的，没有人接受它。但他们抓住了我们的短发。