带有内部/客户托管 SMTP 中继的 Google Apps -(不使用 smtp-relay.gmail.com 服务)

带有内部/客户托管 SMTP 中继的 Google Apps -(不使用 smtp-relay.gmail.com 服务)

我们正在使用 Google Apps 作为我们的电子邮件服务,并且每天从我们的内部中继服务器(仅出站,无开放中继)向客户发送大量约 15,000 封电子邮件。

最近,我们最终获得了 CBL 黑名单上列出的三个出站 IP 地址,而没有其他任何内容。

它提到的第一个原因是它检测到类似于僵尸网络的邮件,但后来检查后,确切原因变为:This IP address is HELO'ing as "localhost.localdomain" which violates the relevant standards (specifically: RFC5321).

这似乎是正确的 - 我们的内部邮件中继使用 IIS 6.0 SMTP 虚拟服务器,并在内部中继来自一堆系统的邮件以供我们向客户通知以及供内部使用的服务器/系统通知。

SMTP 虚拟服务器的 FQDN 是本地服务器名称,我们只能说是 mail.company.local(是的,我们的内部域是.local- 唉)。我将 FQDN 更改为company.com- 然后检查节目原件,我发现 SPF 记录列为= pass,而不是= neutral。我以为这样就解决了问题。

我看到的另一个问题是反向 DNS 记录。目前我们没有反向 DNS 记录,CBL 向我们指出反向 DNS 记录不是必需的 - 但我仍然怀疑设置它是否不是一个坏主意。问题是我们的配置设置起来会很混乱。我们的主要网站company.com(也是我们发送电子邮件的电子邮件域 - company.com)不是由我们托管的,并且 IP 范围与我们发送邮件的内部系统出站 IP 地址完全不同。如果我在我们的出站 IP 地址上为 company.com 设置反向 DNS 记录,反向查找将与 company.com 解析的 IP 不匹配 - 对于我们公司的网站,它不是由我们托管的。令人困惑 - 可能不是必需的......但这是我试图考虑修复的问题,以防它是其中的一个变量。CBL 是我们现在的主要优先事项,除非这与之相关(CBL 说他们不关心 rDNS),否则我现在宁愿担心 CBL。

第二天又被重新列出,我真的不知道接下来该怎么办。这是我们唯一通过这些 IP 发出的 25 端口流量,但有些东西不匹配。我找不到任何最佳实践文档或项目来检查 Google Apps + 内部 SMTP 中继,只有 Google Apps + 使用内部服务器进行智能主机中继的最佳实践smtp-relay.gmail.com- 这很好,但他们每天在每个客户端的托管中继上只接受 10k 封电子邮件。

我主要是想看看是否有人有任何类型的通用/最佳实践配置或项目,用于检查使用 Google Apps 和内部 SMTP 中继的人。它不必是 IIS SMTP - 老实说,我并不反对将其切换到 Postfix 或其他(理想情况下是免费的)服务器,我可以运行它来进行内部邮件中继。只是想把这个抛出来。我很感激任何帮助或需要提前检查的事情 - 谢谢!

答案1

您当然可以配置 Google Apps 以使用内部 SMTP 中继 - 但是,正如您所发现的,运行电子邮件服务器充满了注意事项。通常,我建议将 SMTP 服务卸载到您的外部提供商。

您至少需要设置:

  • 有效主机名
  • 反向 DNS(ARPA 区域中的 PTR 记录)
  • DKIM(域名密钥识别邮件)DNS 记录
  • SPF DNS 记录
  • 客户端需要 TLS -> 您的内部 SMTP 服务器
  • 在您的 SMTP 服务器和主要电子邮件提供商(如 gmail、yahoo 等)之间强制使用 TLS,这是一个不错的功能

听起来您只需创建一个第三级域名即可解决 DNS 问题 - 例如smtp.whatever.com而不是普通的 company.com 您必须与您的 ISP 合作才能将 PTR 记录委托给您的 DNS 提供商或通过 ISP 的支持进行更新。

请注意,Google 的 smtp 中继服务每天接受超过 10,000 封电子邮件;但其收件人数量限制为 10,000 名。

如果您每天向超过 10,000 名收件人发送邮件,我建议您使用第三方邮件托管服务提供商,如 mailchimp、mailgun 等等。最后,由于如今托管服务提供商的低成本,内部 SMTP 中继的麻烦通常是不合理的。

相关内容