由于 DNS 配置，收不到某些发件人的邮件

Question

我注意到我的 google 应用程序域的一个特殊行为。大多数邮件都按您的预期通过，但经过一段时间后，我得出的结论是，某些发件人的邮件不会通过。在确定了一个这样的发件人后，他的邮件不会通过，我让他尝试给我发送一封电子邮件，并将“投递失败”的回复转发到我的常规 gmail。

传递失败响应包含以下代码段：

----- 会话记录如下 -----
<myusername@GHS.L.GOOGLE.COM>... 延迟：与 ghs.l.google.com 的连接超时。

这帮助我通过快速搜索确定了问题，这将我带到了 Google Apps 帮助论坛上的这个页面。事实上，我检查了我的域的 DNS 记录，并将@其设置为 ghs.google.com。(CNAME)，它不应该是。将其更改为@ 74.125.93.121 (A)* 解决了问题。

我知道在邮件无法通过的情况下，我的域名通过 CNAME 查找替换为其规范名称，因此邮件被发送到myusername@ghs.l.google.com而不是myusername@mydomain.com. 但为什么它对绝大多数发件人有效？邮件无法通过的发件人是否使用了某种不同类型的邮件协议、一些奇怪的 DNS 设置，或者可能是什么？

从我在谷歌上研究这个问题所看到的，这似乎是一个普遍存在的问题（很多人抱怨来自战网的电子邮件无法通过，这将是一个流行的例子），只是人们似乎没有请注意，问题在于他们自己的 DNS 设置，而不是发件人一侧。

那么如何解释呢？

^{* 我使用这个 IP 是因为我在这里读到的，但我认为任何 IP 都可以。任何人都可以证实这一点吗？请注意，简单地删除@记录并不能解决问题，必须对其进行更改。}

Answer 1

来自 RFC 2821“简单邮件传输协议”，第 5 节“地址解析和邮件处理”：

查找首先尝试定位与名称关联的 MX 记录。如果改为找到 CNAME 记录，则将结果名称作为初始名称进行处理。

通常，这就是 CNAME 的工作方式。它们经常被误用、误读和误用。:-)

如果您的域是 example.com，则您可能有指向常用 Google Apps 主机的现有 MX 记录。

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

听起来您也有这样的条目：

example.com. CNAME ghs.l.google.com.

RFC 1034“域概念和设施”在第 3.6.2 节“别名和规范名称”中指出，建议不要使用此配置：

如果节点上存在 CNAME RR，则不应存在其他数据；这可确保规范名称及其别名的数据不能不同。

在您粘贴的错误的情况下，发送端的邮件服务器和/或 DNS 服务器尝试查找您的域 example.com 的 MX 记录，并找到指向 ghs.l.google 的 CNAME。 com。然后它尝试查找 ghs.l.google.com 的 MX 记录。该域当前没有任何 MX 记录，因此邮件服务器将落入 ghs.l.google.com 的 A 记录。该 IP 地址未在 SMTP 端口上侦听，因此结果是错误“与 ghs.l.google.com 的连接超时”。

通过删除 CNAME 记录，您已经解决了邮件问题。如果您在其位置定义的 IP 地址在 Google 端发生更改，您可能会遇到问题。

您可以改为为 www.example.com 定义 cname：

www.example.com. CNAME ghs.l.google.com.

并在您指向 example.com 的任何 IP 上运行一个小型网络服务器，它只是将 HTTP 重定向到http://www.example.com/

它的效果和它一样好，这有点令人惊讶。我相信 Postel 定律在那里得到了一些赞誉。:-)

回到 RFC 1034 2.6.2：

CNAME RR 会导致 DNS 软件中的特殊操作。当名称服务器未能在与域名关联的资源集中找到所需的 RR 时，它会检查资源集是否包含具有匹配类的 CNAME 记录。如果是，名称服务器在响应中包含 CNAME 记录，并在 CNAME 记录的数据字段中指定的域名处重新启动查询。此规则的一个例外是匹配 CNAME 类型的查询不会重新启动。

因此，在这种情况下，除非没有找到 MX 记录，否则可能会认为 DNS 服务器不会/不应该在 MX 查找中遵循 CNAME。

发送邮件时，Sendmail 和 qmail（可能还有其他人）默认会尝试将电子邮件地址右侧使用的任何 CNAME 重写为规范名称。

事实上，一些网站依赖于这种行为。djb 在他的“邮件中的 CNAME 记录”文档中详细说明了为什么他认为人们应该停止依赖它。