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

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

他们被拒绝，因为" Helo命令被拒绝：找不到主机；"通过我的postfix邮件服务器。我可能对在后缀中的UCE检查非常严格，因此我将其(在我看来，配置错误)服务器列入白名单，但现在我想弄清楚它们实际配置错误的程度，以及我是否过于苛刻在我接受的

因此，然后我检查了RFC RFC 821说：" HELO接收者可以验证HELO参数确实与发送者的IP地址相对应。但是，即使发送者的HELO命令验证失败，接收者也必须拒绝接受消息。 "这向我暗示了我实际上是违反RFC的人。

我能指出的是RFC 821的这一部分是否被将来的RFC所取代？还是邮件服务器必须接受带有伪造的HELO的邮件？我是否可以指出这一点受到尊敬的权威，说明HELO主机名应该有效，以作为联系其邮件管理员的参考？

解决方案

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

正如我们所引用的那样，RFC 822标准将行为保留给MTA。如今，如果无法解析该名称，则在HELO阶段拒绝连接(并将其与黑名单(例如spamhaus)进行比较)是MTA与僵尸网络产生的大量垃圾邮件保持一致的唯一方法。

因此，没有任何标准可以说明我们必须这样做，但是如果我们不这样做，那么电子邮件就不会走得太远。

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

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

恩，我不同意。如果需要，它可以在EHLO / HELO中提供全部垃圾。只要它说了什么，只要我能解析它的IP地址，我就很高兴。

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

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

注意的部分是：

The sender-SMTP MUST ensure that the  parameter in a HELO command is a valid principal host domain name for the client host.

和

The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

由于垃圾邮件的泛滥，如今的邮件服务器比RFC规定的要严格得多，而且经常会找到各种专有检查和拒绝原因。

但是，他们在HELO字符串中使用不正确的主机名根本没有给自己任何好处。尽管邮件服务器可能会运行良好，但它们的邮件服务器可能会在从许多系统发送和接收电子邮件时遇到麻烦。

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