最近我的 Exchange 2003 服务器出现了问题。我无法接收来自某些域的电子邮件。具体来说只有 2 个域名（每个域中只有一个用户尝试向我们的域发送电子邮件）。
我关闭了过滤器以测试这是否是过滤问题，但无济于事。我还查看了邮件跟踪日志，但发现发件人说他们已经向我们发送了多封测试邮件，但两个域都没有发来邮件。我可以通过 telnet 进入服务器并获取适当的 EHLO 和 HELO 响应，我们没有被列入黑名单，其他一切看起来都正常。
我想知道是否有人对我下一步可以检查或调查的内容有任何建议。如果我忘记了关键信息（抱歉），请告诉我，我会发布更多信息。提前致谢。
答案1
我假设您是通过指向您的 Exchange Server 计算机的 MX 记录直接从 Internet 接收电子邮件（基于您关于使用 TELNET“手动”运行 SMTP 的陈述）。如果您已安装任何反垃圾邮件/反病毒过滤系统，则在开始向第三方系统管理员投诉之前，您应该仔细检查一遍。
话虽如此，接下来排除故障的最佳地点是发件人端。如果你无法从他们那里获得动力来监控他们的出站电子邮件流量，那么你可以尝试捕获你这边的流量，但你很可能会遇到一个巨大的难题。
发件人应该查看 SMTP 协议日志或他们的电子邮件系统具有的与 Exchange“消息跟踪”等同的东西（/var/log/mail.log 等），以了解他们的服务器如何处理失败的消息（发送用户应该能够帮助他们在日志中识别）。假设他们“丢失”了消息、被策略阻止等，他们的服务器没有向发送用户发送 NDR 是愚蠢的。将出站电子邮件黑洞化永远不是答案。（可以说，在入站电子邮件上发送 NDR 可能不是一个好主意。是的，是的——我知道几个 RFC 说你应该……>叹息<）
如果发件人无法帮助您，那么您唯一的希望很可能就是捕获您边界的流量并尝试识别来自其出站服务器的连接尝试（或缺乏连接）。假设您可以让某人按命令发送消息（例如，在电话通话期间），并且假设他们的出站服务器基础设施不需要很长时间来处理该消息，您应该能够捕获与发件人服务器的 SMTP 对话（或者什么也得不到，如果它永远无法到达您）。
说实话，从技术角度来看，这真的不是你的问题。不幸的是，用户和管理层不了解互联网电子邮件的“狂野西部”性质，经常将其视为一种可靠的通信方式。当事实证明并非如此时，他们通常会责怪最近的电子邮件系统管理员，而不是接受与邮政邮件一样，它不是一个可靠的系统。
答案2
这个问题可能在三个地方出错：
- 发件人。发件人站点的邮件服务器是否正常工作？
- 接收者。换句话说：你
- 中间有很多地方。
对于 1)，您显然需要发件人站点管理邮件的人员的帮助。除了询问他们是否阻止了特定邮件（例如，阻止所有超过一定大小的邮件以及发送大型 iso 文件的人）之外，您实际上能做的不多
2) 接收者：好吧，你似乎已经检查了终端上的大部分内容。你收到了所有其他邮件（好吧，除了另一个发件人）。剩下唯一需要检查的是，你是直接收到邮件还是通过第三方收到邮件。
3) 如果发件人的邮件服务器不直接联系您的邮件服务器，而是使用间接路由，那么您将面临一些可能出错的地方。所有这些都不在您的控制范围内。
就我个人而言，当垃圾邮件发送者开始将垃圾邮件放入 PDF 文件中时，我也遇到了类似的问题。所有邮件都通过垃圾邮件过滤机构接收，他们认定所有 PDF 都没有可疑之处。这些邮件被隔离，最终收件人每周收到一次邮件，说明他已隔离邮件。（每周一次的设置是由用户明确设置的，但很快就忘记了）。情况可能类似。
答案3
呃，你需要做的是告诉这些域的邮件管理员（以及你的用户，如果适用的话），你只能递送实际到达的邮件。如果邮件没有到达你的系统，你就无能为力了。
作为 Domino 或 Exchange 管理员，我曾多次遇到这种“问题”，而答案总是相同的。问题出在发送方（我见过一些这种性质的弱智者）或您与他们之间的某个地方。无论哪种情况，这都超出了您的控制范围，您对此无能为力。
“嘿，[其他邮件管理员]，你的系统坏了。快修好它”每当想到这一点，我都会尖叫着说出我最想做出的预设回应。
答案4
尝试对每个 MX 记录进行 telnet 测试。我以前遇到过类似的情况，结果发现这是由于发送系统始终使用优先级较低的 MX 记录和只接受主服务器上的交付的系统组合造成的。辅助服务器只是吞下消息，既不传递也不反弹。
在那个特定情况下，有缺陷的系统是 MessageLabs，这是 Symantec 拥有的垃圾邮件过滤服务，其运营商声称他们的系统之所以如此运行，是因为“只有垃圾邮件发送者才会使用次要记录”。我唯一能想到的解决方案是删除除主要 MX 记录之外的所有记录，因为客户希望继续使用 MessageLabs 进行过滤。