我们有一个SMTP问题。 我们的设置是一个内部Exchange服务器和一个带有DNS条目和MXlogging的外部邮件网关（exim）。 这个网关接受我们域的所有邮件，并接受来自我们内部服务器和外部员工的中继邮件（TLS和用户authentication）。 这是设置描述和简短的话，它的工作正常多年。
不，我们最重要的客户之一（员工> 15k）有问题。 他们拒绝来自我们外部员工的电子邮件！ 不是因为我们的邮件网关黑名单，这是因为在Received E-Mail Header黑名单IP。 电子邮件不是直接发送到目标SMTP，当然它是由我们的SMTP（这是不列入黑名单）中继。
SenderX: IP (blacklisted at http://www.barracudacentral.org) --> Our SMTP Gateway: official IP, (not blacklisted) --> Target SMTP: accepts mail from our SMTP, but not from SenderX
在我看来，由于检查“收到”IP地址，拒绝邮件是非常不寻常的。 RFC的状态，他们必须被添加。
RFC 5432：3.7.2。 网关中接收的线路
- 打开UFW停止我的电子邮件客户端function（包括imap和smtp），即使他们被允许？
- 稍微扭曲更改Exchange 2003中的传出SMTP端口
- debuggingsendmail – dsn = 5.0.0
- Postfix作为hostname.domain.com而不是domain.com发送
- Port25.com SPFtesting失败，gmail SPF通过
在将消息转发到Internet环境或从Internet环境转发出去时，网关务必预先安排一个Received：行，但绝不能以任何方式改变已经在标题部分的Received：行。
我应该build议我们的客户的邮局主pipe？
我应该build议我们的客户的邮局主pipe？
最重要的build议是修复破碎的过滤configuration。 世界上有一半的人发送的邮件内容（大部分是RFC-1918）在Received:标题中，根据这些标准阻止邮件是一个非常糟糕的主意。
不过，你的问题并不新鲜。 时不时的一些过分热情的邮差pipe理员拧filter，所以人们已经find了解决方法，只需重新编写标题。 有了后缀，你可以使用header_checks来做到这一点 – 如本文所述 。 我几乎没有看到exim，但我希望它有一些类似的function。
为什么您的外部用户没有直接连接到Exchange服务器（通过RPC over HTTP，POP或IMAP）？ 如果他们是你不会有这些问题。 我的build议是configuration外部客户端直接连接到Exchange服务器，然后照常发送电子邮件到网关服务器。