SMTP 客户端必须在 HELO 中向 MTA 提供全局可解析的主机名吗？[关闭]

Question

简而言之：我试图弄清楚我是否应该告诉朋友雇主的邮件管理员是否应该修复他们的邮件配置，或者我是否应该修改自己的策略以在我接受的内容上更加自由，或者两者都不应该。

一位朋友抱怨无法访问我的邮件服务器上的任何内容。我深入研究了一下，似乎他的邮件服务器在连接到我的邮件服务器时提供的主机名位于 *.local 空间中的某个位置，这意味着它无法全局解析。

他们被拒绝，并显示“Helo 命令被拒绝：未找到主机；”由我的 postfix 邮件服务器发出。我可能对 postfix 中的 UCE 检查很严格，所以我将他们的（在我看来，配置错误的）服务器列入白名单，但现在我试图弄清楚他们实际上配置错误的程度，而不是我是否太严厉了在我接受的情况下。

然后我检查了 RFC - RFC 821 说“HELO 接收方可以验证 HELO 参数是否确实对应于发送方的 IP 地址。然而，即使发送者的 HELO 命令验证失败，接收者也不得拒绝接受消息。”这表明我实际上是违反 RFC 的人。

RFC 821 的这一部分是否已被我可以指出的未来 RFC 所取代？或者邮件服务器必须接受带有伪造 HELO 的邮件吗？是否有任何受人尊敬的权威机构可以指出 HELO 主机名应该有效，作为联系其邮件管理员的参考？

Answer 1

SMTP RFC 不要求它，但许多流行的系统会拒绝带有伪造 HELO 的邮件。请注意，RFC 1033 和 RFC 1912 都要求所有可通过 Internet 访问的主机都具有有效的名称；只需在 HELO 中列出该名称即可解决许多问题。不幸的是，一些垃圾邮件过滤器也会拒绝来自包含暗示它们位于动态地址池中的字符串的主机名的邮件（例如“动态”、“dsl”或用破折号分隔的 IP 地址，这在许多 ISP 中都很常见）。

如果您的朋友无法控制其反向 DNS，一种选择是使用合适的机器作为智能主机来发送邮件；例如他们的 ISP 的邮件服务器。

Answer 2

严格来说，你是 两个都 违反 RFC。

注意的部分是：

发送方 SMTP 必须确保 HELO 命令中的参数是客户端主机的有效主体主机域名。

和

HELO 接收方可以验证 HELO 参数是否确实对应于发送方的 IP 地址。然而，即使发送者的 HELO 命令验证失败，接收者也不得拒绝接受消息。

由于垃圾邮件的盛行，现在的邮件服务器 相当 比 RFC 所说的更严格，并且经常会发现各种专有检查和拒绝原因。

然而，他们的 HELO 字符串中的主机名不正确，这对他们自己没有任何好处。尽管您的邮件服务器可能工作得很好，但他们的邮件服务器可能在从许多系统发送和接收电子邮件时遇到问题。

我会让他们知道的。如果只是因为配置错误，他们可能无法收到应有的全部电子邮件。

Answer 3

正如您所引用的，RFC 822 标准将行为留给了 MTA。如今，如果无法解析名称，则在 HELO 阶段拒绝连接（并根据 spamhaus 等黑名单进行检查）是 MTA 跟上僵尸网络生成的大量垃圾邮件的唯一方法。

因此，没有标准规定您必须这样做，但如果您不这样做，您的电子邮件就不会走得很远。

Answer 4

是的，他们应该这样做。许多其他系统（包括 yahoo）将拒绝来自无法反向映射到连接 IP 或无法解析的主机名的邮件。

Answer 5

呃，我不同意。如果愿意的话，它可以在 EHLO/HELO 内提供全部垃圾。只要它说了什么， 和 只要我能解析它来自的 IP 地址，我就很高兴。

EHLO 内部通常是一个短主机名，而不是 FQDN。