我的客户在给几个客户发送电子邮件时遇到了间歇性问题。这种情况实际上只在过去五天内发生过一次,到目前为止只发生在六封不同的邮件中,但它们在成功发送和失败发送之间都存在相同的区别。
在下面的屏幕截图中,成功投递和失败投递之间的区别在于它尝试投递的服务器 IP/主机名。我之所以选择这个收件人,是因为他们的域名是通用的。在每周发送数十条消息的其他尝试中,情况看起来非常相似。
由于某种原因,Exchange Server 获取收件人帐户域的 IP,而不是使用 MX 记录中的地址。(即 mindspring.com 而不是 mx3.mindspring.com)
我的客户正在运行带有 Exchange 2010 的 Small Business Server 2011 Standard。他们每天发送的其余约 200 条消息都发送正常。
我迄今为止的研究:
答案1
好吧,如果我尝试 telnet mindspring.com:25,我无法连接,所以我怀疑 ServerHostname 是转移注意力的借口。显然,您正在连接到邮件服务器,但它要求您进行身份验证才能使用端口 25。您收到的 550 错误要么是因为您连接的服务器上启用了 SMTP 身份验证,要么是因为他们试图强制使用 TLS。
如果您转到该服务器上的命令行并输入:
nslookup
set type=mx
mindspring.com
你得到了什么?一切都顺利吗?如果你这样做了,你会得到同样的答案吗?
nslookup
server 8.8.8.8
set type=mx
mindspring.com
或者您为 mindspring 工作而这都是内部的?
答案2
总结:我们使用的两家 ISP 之一会阻止来自其网络之外的 DNS 请求。DNS 请求偶尔会来自另一家 ISP 的网络...
修复:在防火墙上实现静态路由,以便 ISP DNS 服务器使用特定接口,或者使用其他服务(如 OpenDNS 或 Google DNS)。
故事:好吧,我们发现了问题所在。Exchange 服务器基本按照我们的预期运行。我们有一个双 WAN 连接,如果主 WAN 连接出现故障,防火墙会故障转移到该连接。因此,我们在域控制器上添加了 DNS 服务器,以便查询我们的两个 ISP(以及 OpenDNS 作为第三选项)。我们将不得不对这个特定的过程进行更多研究,但我们发现 Exchange 并非始终查询第一个服务器(我们的主要 WAN 连接)。
它似乎一直在所有选项之间循环。这一直没有问题,直到我们的辅助 ISP 更改其 DNS 服务器上的设置以拒绝来自其网络之外的 IP 的连接。数据包捕获显示了此响应,这最终使我们得出结论。当 Exchange 收到拒绝响应时,它回退到仅查询 A 记录并尝试使用该记录建立连接。