我们使用Exchange 2007的SBS 2008服务器开始在3或4天前开始拒绝一些（大部分）电子邮件。 返回失败消息看起来像这样：
其他服务器返回的错误是：451 451 4.7.0超时等待客户端input（状态18）
我重新启动了我们的Sonicwall TZ-210路由器，这没有任何区别。 我认为这个问题与MTU（包大小）有关，但我不明白为什么这个问题刚刚开始。 我们几周来一直没有对networking基础设施做任何改变。
如果我ping我们的SonicWall（DSL连接，网桥模式）强制不分片的数据包，我开始收到数据包大小为1320左右的丢包。 也许这是完全正常的，我不确定。
我还没有尝试重新启动DSL调制解调器，因为我不在现场。 这是我将尝试的下一件事情之一。
在更多的在线阅读后，我使用-f开关做了一些pingtesting，发现这个特定的DSL连接开始丢弃超过1300字节的数据包。 微软把这称为“黑洞路由器”。 基本上，这个港口有什么问题。
我通过进入SonicWall TZ-210内部的PPoE连接设置并将MTU更改为1250范围内的某个地方（我不记得确切的数字）来解决此问题。 传入的电子邮件立即再次开始stream动，以及使用该特定连接的任何其他stream量。 我将不得不联系SonicWall，看看我们是否可以在保修期内解决这个问题。
UPDATE1
事实certificate，这显然是DSL调制解调器问题，而不是SonicWall问题。 改变路由器PPoE设置中的MTU设置certificate是一个足够的解决方法，直到调制解调器被replace。
UPDATE2
一个新的DSL调制解调器没有解决这个问题。 仍然不确定哪个设备或软件导致此问题。
UPDATE3
我想我没有回到这里，以至于什么是错的。 这家电话公司在他们的一个箱子或办公室里发现了一些坏的硬件，并取而代之。 如果你正在解决这个问题，那么棘手的部分是确定你是自己的硬件还是你的LAN之外的东西。
如果这是一个路由问题（很有可能，给出错误信息），请尝试在SBS的公共接口上设置MTU最大大小。 您可以在registry中为每个单独的tcpip接口设置程序包大小限制。
查看本指南从Microsoft，最后一个build议“方法3”引导您通过设置MTU最大大小： http ： //support.microsoft.com/kb/314825