代码之家  ›  专栏  ›  技术社区  ›  Daniel Papasian

smtp客户机必须在helo中提供一个全局可解析的主机名吗?[关闭]

  •  3
  • Daniel Papasian  · 技术社区  · 16 年前

    简而言之:我想知道我是否应该告诉一个朋友雇主的邮件管理员他们的邮件配置是否应该被修改,或者我是否应该修改我自己的政策,使我接受的内容更加自由,或者两者都不接受。

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

    它们被我的邮箱服务器以“helo command rejected:host not found;”拒绝。我可能对后缀中的UCE检查很严格,所以我将他们的(在我看来,配置错误)服务器列入了白名单,但现在我正试图弄清楚他们实际上配置错误的程度,而不是我接受的内容是否过于苛刻。

    所以我检查了RFC-RFC821,说“helo接收器可以验证helo参数是否真的与发送者的IP地址对应。但是,即使发送方的helo命令验证失败,接收者也不能拒绝接受消息。”这意味着我实际上是违反RFC的人。

    我可以指出,这部分RFC821曾经被未来的RFC所取代吗?还是邮件服务器必须接受假helos邮件?是否有任何值得尊敬的权威机构可以指出,helo主机名应该是有效的,作为联系邮件管理员的参考?

    5 回复  |  直到 16 年前
        1
  •  2
  •   moonshadow    16 年前

    SMTP RFC不需要它,但是许多流行的系统会拒绝使用假helos的邮件。请注意,RFC1033和RFC1912都要求所有可连接到Internet的主机都有一个有效的名称;只需在helo中列出该名称就可以解决许多问题。不幸的是,有些垃圾邮件过滤器还拒绝来自主机名的邮件,这些主机名包含的字符串意味着它们位于动态地址池中(如“dynamic”、“dsl”或短划线分隔的IP地址,这与许多ISP相同)。

    如果您的朋友无法控制他们的反向DNS,则可以选择使用合适的计算机作为发送邮件的智能主机;例如,他们的ISP的邮件服务器。

        2
  •  6
  •   Dan Aditi    16 年前

    严格来说,你是 二者都 违反了RFC。

    注释部分包括:

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

    HELO接收器可以验证HELO参数是否确实与发送方的IP地址对应。但是,即使发送方的helo命令验证失败,接收方也不能拒绝接受消息。

    由于垃圾邮件的普遍存在,最近的邮件服务器 相当地 比RFC所说的更严格,通常会发现各种专有检查和拒绝原因。

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

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

        3
  •  4
  •   Andrew M. Greene    16 年前

    正如您所引用的,RFC822标准将行为留给MTA。如今,如果无法解析名称,那么拒绝helo阶段的连接(并对照黑名单(如spamhaus)进行检查)是MTA跟上僵尸网络产生的大量垃圾邮件的唯一方法。

    所以没有标准规定你必须这样做,但是如果你不这样做,你的电子邮件就不会走得太远。

        4
  •  1
  •   Chris    16 年前

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

        5
  •  0
  •   JBB    16 年前

    嗯,我不同意。如果愿意,它可以在ehlo/helo内提供全部垃圾。只要它说了什么, 只要我能解析它来自的IP地址,我就很高兴。

    ehlo内部通常是一个短的主机名,而不是一个fqdn。