Exim 4.69由于语法上无效的EHLO（奇怪的伪MAC FQDN）而拒绝出站邮件，

从昨天开始（我怀疑是新的路由器是根本原因），客户端在发送电子邮件时遇到了麻烦。 接收是好的，只是出站不断失败。

尾巴Exim的主要日志，这是EHLO被提出，并且Exim踢它的原因：

2013-03-09 15:07:00 SMTP connection from host109-155-115-197.range109-155.btcentralplus.com (unknown-68:a8:6d:03:cf:6e.home) [109.155.115.197]:52877 

其次是

 rejected EHLO from host109-155-115-197.range109-155.btcentralplus.com [109.155.115.197]:52848 I=[213.229.88.78]:587: syntactically invalid argument(s): unknown-68:a8:6d:03:cf:6e.home 

在helo_allowed_chars中添加一个冒号到helo_allowed_chars ，邮件按预期stream动：

• 后缀：弹跳邮件（反向DNS问题）
• 每月/每天发送邮件的后缀限制数量
• 邮件中继是否会被列入黑名单，如果它接受邮件中继请求，然后发送NDR？
• 如果本地交付失败，请将外发邮件转发给互联网
• mx服务器：一个IP上的多个域

收到：从主机109-155-115-197.range109-155.btcentralplus.com（[109.155.115.197]：52913 helo = unknown-68：a8：6d：03：cf：6e.home）

有问题的邮件客户端是Mail.app，

 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) 

我想我的问题是三重的：

1. 为什么英国电信主页集线器产生这些明显无意义的本地FQDN？
2. 为什么OSX一味地接受任何古怪的，不兼容的本地主机名？
3. 为什么Mail.app在发送出站电子邮件时盲目地接受这个奇怪的，不兼容的本地主机名 – 尽pipe这显然是非法的，并且会通过RFC检查？
4. 为什么我不经常看到这个问题呢？ 这是我第一次有人说他们的出站电子邮件不工作，我已经使用Mail.app在许多Mac电脑上设置了电子邮件，所有这些都在我打字时愉快地发送和接收。 （我可以在Exim的mainlog看到他们）

寻找其他BT Home Hubstream量，我可以看到一个使用EHLO看起来更加标准化的连接：

 2013-03-07 20:04:17 H=host81-156-4-96.range81-156.btcentralplus.com (BThomehub.home) 

不知道这是一个Mac或PC产生它，但它是从外面来的 。

我正在更新此服务器到最新的稳定版本，包括Exim（目前运行4.69）。 我不想在Exim conf中保留这个RFC hack，如果用户提供了有效的证书，就必须有一个更好的方法来解决这个问题。

每个使用Mac的英国电信宽带客户实际上遇到了与Exim促成的电子邮件相同的问题 – 他们只是没有意识到这一点？ 在与Mac环境合作之前，我不得不使用家庭集线器，而且我从来没有见过像分配给networking设备的unknown-68:a8:6d:03:cf:6e.home这样的伪MAC地址。通常只有主机名被映射到路由器局域网部分的设备上，在那里它不能检测到设备types或主机名，所以只显示了MAC地址，并且默认的gunk已经被预置和附加了。

更迫切的是试图找出为什么这个数据甚至应该呈现给一个邮件服务器，我不希望支持这个黑客更长的时间。 我甚至不能保证它会在Exim更新后生效，但我不打算推​​迟服务器升级来支持不符合要求的客户端。