3

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

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

他们被拒绝了“Helo command denied: Host not found;” 通过我的后缀邮件服务器。我可能对后缀中的 UCE 检查很严格，所以我将他们的（在我看来，配置错误的）服务器列入白名单，但现在我试图弄清楚它们实际上配置错误的程度，而不是我是否过于苛刻在我接受的。

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

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

4

5 回答 5

6

严格来说，你们都违反了 RFC。

需要注意的部分是：

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

和

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

由于垃圾邮件的盛行，如今的邮件服务器比 RFC 所说的要严格得多，并且通常会发现各种专有检查和拒绝原因。

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

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

于 2008-09-18T21:44:57.497 回答
4

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

所以没有标准说你必须，但如果你不这样做，你的电子邮件就不会走得很远。

于 2008-09-18T21:38:15.483 回答
2

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

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

于 2008-09-18T21:40:04.187 回答
1

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

于 2008-09-18T21:31:55.687 回答
0

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

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

于 2008-09-18T21:40:14.123 回答