为了在 DMZ 中进行邮件中继，我最近将 Fedora Core 3 服务器替换为运行 CentOS 5 的服务器。
我的问题是，当服务器向某个远程组织发送消息时，大于 500KB 的消息无法正确发送。它们似乎在传输过程中被卡在了某个地方，超时了，然后在可预测的重试之后，在队列中过期了。
Sendmail 将该问题描述为：MDeferred：与 [site] 的连接超时。
大型（或更大）邮件已成功发送到我们测试过的所有其他远程系统。只有这个组织遇到了问题。同样，只要我们的 CentOS 5 中继不参与，我们就可以向该组织发送大型或更大的邮件。
我们花了很多时间进行数据包跟踪，但没有什么帮助。看来，在传输一定深度后，对方开始请求数据包重传，我们照做了，但重传的数据包似乎从未到达对方。
弄乱 iptables（即将其完全关闭）也无济于事。
今天，我们将 XP 系统放在 DMZ 中作为中继的对等体，它可以顺利地向远程组织发送邮件，而中继却无法发送邮件。在我看来，这排除了我们与远程组织之间的所有防火墙和网络路径，并将问题直接归咎于邮件中继。
鉴于我在为 Fedora Core 3 设置此 sendmail 后重新访问它，我在设置此系统时是否可能做错了什么，以至于会以这种方式表现出来？
答案1
遇到此问题时，大多数情况下，我都会禁用 TCP 窗口缩放，这样问题就解决了。在/etc/sysctl.conf底部添加以下几行：
net.ipv4.tcp_rmem = 4096 87380 174760
net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_window_scaling = 0
然后以 root 身份执行sysctl -p并查看会发生什么。请注意，这不是解决问题的办法，只是一种绕过方法。我发现触发此行为的因素包括您的机器所连接的交换机、实际电缆、中间某些设备的软件版本以及 tg3 以太网驱动程序和芯片组的各种组合。您甚至可能会发现，如果您在同一台机器上安装另一个操作系统（例如 OpenBSD），问题就会消失。
我还看到其他人将 MTU 设置为 500 以解决此问题。
但就像我说的，我提供的是可能的绕过方法，而不是解决问题的方法。