我最近遇到了Exchange 2003服务器的问题。 我无法接收来自某些域名的电子邮件。 特别是只有两个域名（每个域名只有一个用户尝试发送邮件到我们的域名）。
我已经filter来testing，如果这是一个过滤问题无济于事。 我还查看了邮件跟踪日志，但发件人说他们向我们发送了多个testing电子邮件时，请注意来自任一域的任何电子邮件。 我可以远程login到服务器，并得到适当的EHLO和HELO响应，我们不被列入黑名单，其他一切看起来都是正确的。
我想知道是否有人有什么build议，我可以检查下一步或看看。 如果我忘记了关键信息，请告诉我，我将发布更多信息。 提前致谢。
我假设你是通过引用你的Exchange Server计算机的MXlogging直接从互联网接收电子邮件（根据你的语句：使用TELNET手动运行SMTP）。 如果您有任何反垃圾邮件/防病毒过滤function，那么在您开始向第三方系统pipe理员投诉之前，您必须对其进行双倍/三重检查。
话虽如此，接下来的最佳解决scheme就是发件人。 如果你无法从他们那里获得监控他们的出境电子邮件stream量的牵引力，那么你可以尝试捕捉stream量，但很可能你会有一个巨大的干草堆来梳理。
发件人应该寻找SMTP协议日志，或者他们的电子邮件系统等同于Exchange“邮件追踪”（/var/log/mail.log等），以了解他们的服务器如何处置失败的邮件（发送用户应该能够帮助他们识别他们的日志）。 假设他们正在“丢失”信息，被策略阻止等等，他们的服务器没有将NDR发送回发送用户是愚蠢的。 黑洞出站电子邮件从来就不是答案。 （发送NDR的入站电子邮件，可以说，可能不是一个好主意。是的，是的 – 我知道几个RFC的说你应该…叹气<）
如果发送者不能帮助你，那么你唯一的希望就是很可能在你的边界捕获stream量，并尝试从他们的出站服务器中识别连接尝试（或缺less连接）。 假设你可以让某人根据命令发送一条消息（比如说，在一个电话中），假设他们的出站服务器基础结构不需要很长时间来处理这个消息，你应该能够捕获与发送者的服务器的SMTP对话或者什么也不是，如果它从来没有得到你）。
事实上，从技术angular度讲，这不是你的问题。 不幸的是，用户和pipe理层不理解互联网电子邮件的“狂野西部”性质，并经常将其视为可靠的沟通forms。 当事实certificate，否则他们往往责怪最接近的邮件系统pipe理员，而不是接受邮政邮件，这不是一个可靠的系统。
这是一个在三个地方可能出错的问题：
对于1）你显然需要在发件人站点pipe理邮件的人的帮助。 除了询问他们是否阻止了特定的邮件（例如，阻止所有超过一定大小的邮件，以及如果发送给您巨大的iso文件的人）
2）接收者：好吧，你似乎已经检查了大多数东西在你的终点。 而你收到所有其他邮件（好吧，另外一个发件人）。 剩下的唯一要检查的是如果你直接或通过第三方收到你的邮件。
3）如果发件人的邮件服务器不直接联系你的邮件服务器，而是使用一个间接的路由，那么你有一些额外的地方可能出现问题。 全部在你的控制之外。
就我个人而言，当垃圾邮件发送者开始将他们的垃圾邮件放入PDF文件时，我遇到了类似的问题。 所有或邮件通过垃圾邮件过滤机构收到，他们决定所有的PDF文件，不怀疑。 那些邮件得到了保证，最终的收件人每周都会收到一封邮件，说明他有邮件保证。 （每周一次的设置是由用户明确设置的，并立即被遗忘）。 类似的事情可能是这样的。
呃，你需要做的是告诉邮件pipe理员在这些域（和你的用户，如果适用的话），你只能发送实际到达的邮件。 如果它没有到达你的系统，那么你就没有办法做到这一点。
作为一个Domino或Exchangepipe理员，我曾经多次强调过这个“问题”，答案总是一样的。 发件人的问题（我曾经见过一些这种性质的智力迟钝者），或者你和他们之间的某个地方。 无论哪种方式，它都是你无法控制的，对此你不能做任何事情。
“嘿，[其他邮件pipe理员]，你的狗屎坏了，修正它”就像尖叫声一样，每次出现这个消息时我都会回应。
这是发生在特定域的所有邮件吗？ 如果您联系他们的IT，他们将从哪个IP地址发送？
如果他们总是失败，他们应该有一个失败的通知，为什么。 让他们将失败转发给您的公共邮件帐户，以便您可以看到拒绝通知。
您可以validation是否甚至在IIS日志中尝试连接有SMTP日志。 打开日志级别，如果需要的话。 寻找他们的IP。
这也可能是您的防火墙问题。 如果可以，请尝试查看是否可以查看日志。 确保你有最新的更新。
我也看到糟糕的互联网连接导致这个问题。 连续ping 10分钟到您的ISP或一些不介意testing的网站。 高延迟或失败的数据包意味着您需要与您的ISP讨论该线路。
最后，如果你有资源build立一个垃圾邮件过滤Linux服务器。 运行在将电子邮件转发到Exchange服务器的另一台计算机上的虚拟机将会很好。 如果它仍然发生，那么你知道这不是你的邮件服务器，你会得到一个额外的过滤层…
尝试在每个MXlogging上进行telnettesting。 我以前遇到类似的情况，原因是总是使用低优先级MXlogging的发送系统和只接受主要发送的系统的组合。 次要人员只是吞下了信息而没有传递，也没有反弹回来。
在这个特定的例子中，有缺陷的系统是MessageLabs，这是一个赛门铁克公司拥有的垃圾邮件过滤服务，运营商声称他们的系统是这样行事的，因为我引用了“只有垃圾邮件发送者每次使用辅助邮件”。 唯一可用的解决scheme是消除除主MXlogging之外的所有内容，因为客户希望继续使用MessageLabs进行过滤。
邮件跟踪日志仅用于发送到Exchange的电子邮件，更具体地说，用于发送到信息存储的邮件。 收件人或发件人筛选阻止的电子邮件不会显示在邮件跟踪日志中，但会显示在SMTP日志中。 您需要启用Exchange服务器上SMTP服务的日志logging，因为这是到达Exchange服务器的电子邮件的“入口”点。 被连接筛选阻止的电子邮件将不会显示在SMTP日志中，因此您需要启用防火墙或路由器上的日志logging，因为这是到达您的networking的电子邮件的“入口”点。 如果邮件跟踪日志，SMTP日志或防火墙/路由器日志中没有条目，那么您可以确信有问题的邮件没有到达您的networking和/或Exchange服务器。
接下来，您需要确保您的公共DNS是正确的，并且您的NS，MX和关联的Alogging是正确的，并且正确parsing。 如果您的DNS中存在configuration错误，那么外部电子邮件服务器尝试向您的域发送电子邮件可能会导致失败。 如果您的公共DNS有问题，那就是您的问题，您需要修复它。
如果上述日志显示没有条目，并且您的公共DNS已configuration并正常工作，那么只有这样，才能肯定地说，问题不在您的尽头。