主页 / server / 问题 / 1145110
Accepted
x-yuri
Asked: 2023-10-04 20:50:58 +0800 CST

HELO、MAILFROM 和 From 应该使用相同的域吗？

  • 772

我之前配置过邮件服务器几次，我相信当时我认为答案是“是”。

但我正要配置另一台，看来我错了。假设顶级域 ( example.com) 和（唯一的）MX 记录指向同一服务器 ( mail.example.com)。然后我可以做：

  • example.com指向服务器 IP ( aa.aaa.aa.aaa) 并将其返回 (PTR) 到example.com
  • 邮件服务器 ( postfix, exim, ...) 响应example.com( HELO, MAILFROM)

那么 SPF、DKIM 和 DMARC 记录名称为：@、mail._domainkey（如果选择器为mail）和_dmarc。或者简单地说：

@  A  aa.aaa.aa.aaa
@  MX  10  mail
mail  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  @

@  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

但是如果我有 2 条 MX 记录（mail1和mail2）怎么办？那么我就不能example.com指向 2 个不同的 IP 并将它们指向example.com，可以吗？但即使我可以，我也可以看到 Gmail 不gmail.com使用HELO, MAILFROM。每个服务器用自己的名称响应似乎更明智，不是吗？但那又怎么样，我应该有 2 条 SPF 记录吗？毕竟：

当前版本的 SPF（称为 SPFv1 或 SPF Classic）可保护信封发件人地址

http://www.open-spf.org/Introduction/

@  A  (whatever)

@  MX  10  mail1
mail1  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  mail1

@  MX  20  mail2
mail2  A  bb.bbb.bb.bbb
bb.bbb.bb.bbb  PTR  mail2

mail1  TXT  (SPF)
mail2  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

坦白说，在阅读有关配置邮件服务器的不同文章和答案后，我感到很困惑。什么是正确或更好的设置？

email

1 个回答

  1. Best Answer

    HELO 主机名可以与发件人不同

    主机名HELO应该有一个匹配的A& PTR，但它们不必与RFC 5321 MAIL FROM和RFC 5322 发起者字段 From标头中使用的域匹配，甚至不必共享组织域。

    例如，mail1.example.com&mail2.example.com可以为example.com, example.net&发送邮件example.org。否则，每个域都需要一个自己的 IP 地址和匹配的PTR记录。想想大型电子邮件服务提供商正在处理的域数量，他们当然为所有域使用通用的基础设施。

    MX 记录用于传入邮件

    这些MX记录与发送邮件无关，而是与接收邮件有关。在你的问题范围内，它们之间没有任何关系。入站邮件可以完全由一组不同的服务器处理。例如，来自域的新闻通讯可以使用 SendGrid 或 MailChimp 发送，而传入邮件则由 M365 或 Gmail 处理。

    HELO/DNS 不匹配的根源

    使用HELO//不匹配作为垃圾邮件的指示是很常见A的PTR，如 MXToolBox 中所述：

    • SMTP 横幅检查：

      一些接收邮件服务器可能会使用不匹配或屏蔽的横幅作为评分系统中可能的垃圾邮件源的指示，但大多数服务器不会仅以此为基础拒绝传入的邮件。

    • SMTP 反向 DNS 不匹配：

      一些接收邮件服务器可能会使用它作为评分系统中可能的垃圾邮件源的指示。大多数人不会仅仅以此为由拒绝收到的邮件。我们建议您联系您的 ISP，并要求他们设置与您的邮件服务器主机名相匹配的反向记录 (PTR)。

    这种做法可能来自对RFC 5321, 2.3.5的解释：

    命令中给出的域名EHLO必须是主主机名（解析为地址 RR 的域名），或者如果主机没有名称，则为地址文字，如第 4.1.3 节中所述，并在第 4.1.3 节中进一步 讨论。第 4.1.4 节EHLO的讨论 。

    然而，正如4.1.4进一步定义的那样，这并不是硬性要求：

    如果可能的话，SMTP 客户端必须确保命令的域参数是第 2.3.5 节EHLO中为此命令指定的主要主机名。如果这是不可能的（例如，当客户端的地址是动态分配的并且客户端没有明显的名称时），则应该用地址文字来替换域名。

    SMTP 服务器可以验证命令中的域名参数EHLO 是否确实对应于客户端的 IP 地址。但是，如果验证失败，服务器不得据此拒绝接受消息。

    在这里，SMTP协议似乎遵循稳健性原则，即“对你所做的事情保持保守，对你从别人那里接受的事情保持自由”。

    SPF

    发件人策略框架(SPF) 实施必须保护MAIL FROM身份（RFC 7208, 2.4），并且也可以选择保护HELO身份（RFC 7208, 2.3）：

    建议 SPF 验证者不仅检查身份MAIL FROM ，而且还HELO通过将check_host()函数（第 4 节）应用于HELO身份来 单独检查身份<sender>。检查HELO可以提高结果的一致性，并可以减少 DNS 资源的使用。如果可以基于 的检查做出有关消息的结论性确定，则可以避免HELO使用 DNS 资源来处理通常更复杂的处理。MAIL FROM

    由于这是独立完成的，SPF 也不要求它们匹配。

    SPF 保护主机名不被未经许可用作信封发件人，并且它不会被子域继承。A因此，您应该使用相应的 SPF 记录来保护您拥有的每条记录TXT，而不仅仅是用于发送电子邮件的记录。

    DMARC

    基于域的消息身份验证、报告和一致性(DMARC) 需要RFC5322.From与RFC 7439, 3.1中定义的标识符对齐之间的匹配。这些标识符可以是 DKIM 验证(3.1.1 ) 或 SPF 验证 ( 3.1.2 )，并且根据模式，可能需要完全匹配或共享组织域( 3.2 )。与 SPF 不同，DMARC 是继承的；域顶端的 DMARC 策略From也可以保护所有子域免于在标头中使用。

    SPF对齐需要匹配MAIL FROM，但DKIM对齐不需要；拥有有效且授权的 DKIM 签名以及匹配的签名域标识符(SDID)（d=字段）就足够了。最重要的是，这些都不需要匹配的HELO/EHLO主机名。

    • 2

相关问题