MX 优先级数字越小越优先吗?一个域完全不收邮件该怎么声明?
RFC 5321 第 5.1 节(Locating the Target Host)规定:客户端确定目的域后必须做 DNS 解析,查找先尝试定位 MX 记录;若查到 CNAME,则把结果名字当作初始名字重新处理;若返回域不存在错误,必须作为错误报告;若返回临时错误,邮件必须入队重试;若返回空的 MX 列表,则该地址被视为关联着一条前置值为 0、指向该主机自身的「隐式 MX」记录;若存在 MX 记录但都不可用,或隐式 MX 不可用,同样必须作为错误报告。同节还有一条常被忽视的强约束:一旦为某名字找到了一条或多条 MX 记录,SMTP 系统就不得再使用该名字上的地址记录,除非这些地址是经由 MX 记录定位到的——隐式 MX 规则只在完全没有 MX 记录时才适用。
第 5.1 节明确:MX 记录含有一个前置(preference)指示,当出现多条时必须用于排序,数字更小者更优先。若多个目的地前置值相同且没有明显理由偏向某一个,发送方必须把它们随机化,以便把负载分摊到该组织的多台邮件交换主机上。当解析结果是一组备选投递地址时,客户端必须能够按顺序逐个尝试与重试直至成功,可以对可尝试的备选地址数量设置上限,但无论如何应当至少尝试两个地址。若目的主机是多宿主的,解析器返回的多个 IP 地址由解析器接口负责按优先级降序排列,发送方必须按给出的顺序尝试。
同节规定:查询某条 MX 记录关联的域名时,其数据字段必须包含一个域名,而该域名被查询时必须至少返回一条地址记录(A 或 AAAA),给出 SMTP 服务器的 IP 地址;任何其他响应,特别是查询后返回 CNAME 记录的取值,都在本标准范围之外,相关讨论见 RFC 2181 第 10.3 节。这条是配置审计中最常见的违规项之一。
第 5.1 节还规定:若某 SMTP 服务器判定应当在不改写地址的情况下中继该邮件,它必须对 MX 记录排序以确定候选投递目标;随后中继主机必须检查列表中是否存在自己在邮件事务中可能被称呼的任何名字或地址;若找到匹配记录,则该优先级层级及所有更高数字的记录都必须被排除;若此时已无记录可用,则属错误条件,邮件必须被退回。这就是备份 MX 不会把邮件投回自己的机制来源。
RFC 7505 第 3 节规定:要表明某域不接收邮件,该域发布唯一一条 MX 记录,其 RDATA 由前置值 0 与一个零长度标签(在区文件中写作「.」)作为 exchange 域名构成,表示该域不存在邮件交换主机;由于「.」不是合法主机名,null MX 不会与普通 MX 混淆。发布 null MX 的域不得再发布任何其他 MX 记录。第 4.1 节给出配套回复码:投递或中继服务器因收件人域的 null MX 而拒绝该信封收件人时,应当使用 556 回复码与 5.1.10 增强状态码;因 RFC5321.MailFrom 或 RFC5322.From 域存在 null MX 而拒信时,应当使用 550 回复码与 5.7.27 增强状态码。第 4.2 节提醒:邮件系统不应为自己用作 MailFrom 或 From 的域发布 null MX,否则其邮件有被拒的风险;不发信的域可另行发布 SPF 的 -all 策略作出显式声明。
参考:https://www.rfc-editor.org/rfc/rfc5321.txt 与 https://www.rfc-editor.org/rfc/rfc7505.txt
