拒绝来自没有 RDNS 的邮件服务器的邮件是好的做法还是太严厉了

Question 1

我尝试了多种方法使用 HELO/EHLO 检查，客户群规模相当大，大概在 10 万到 20 万之间，最终我选择了以下解决方案：

检查 HELO/EHLO 是否包含域名。——这主要归结为名称中是否有点。检查名称上的 DNS 导致许多服务器失败，因为服务器显示内部名称或您无法正确解析的内容并不罕见。
检查 IP 是否有反向 DNS 记录。——这又是一个松懈的设置，因为我们没有根据 HELO/EHLO 进行检查。根据 HELO/EHLO 进行检查会产生如此多的票据，这个设置甚至连一天都撑不了。
检查发件人的域名是否有效。——这是一个基本检查，以确保如果我们确实需要退回邮件，至少有某种方法可以找到它的服务器。

这是我们用于这些检查的 Postfix 块：

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient

Answer

我尝试了多种方法使用 HELO/EHLO 检查，客户群规模相当大，大概在 10 万到 20 万之间，最终我选择了以下解决方案：

检查 HELO/EHLO 是否包含域名。——这主要归结为名称中是否有点。检查名称上的 DNS 导致许多服务器失败，因为服务器显示内部名称或您无法正确解析的内容并不罕见。
检查 IP 是否有反向 DNS 记录。——这又是一个松懈的设置，因为我们没有根据 HELO/EHLO 进行检查。根据 HELO/EHLO 进行检查会产生如此多的票据，这个设置甚至连一天都撑不了。
检查发件人的域名是否有效。——这是一个基本检查，以确保如果我们确实需要退回邮件，至少有某种方法可以找到它的服务器。

这是我们用于这些检查的 Postfix 块：

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient

Question 2

阻止不具备以下基本功能的 SMTP 服务器的情况极为常见：

HELO 转发中的主机名解析为连接来源的 IP。
连接原始 IP 反转为 HELO 中声明的主机名。
如果存在 SPF、DKIM 或 DMARC 策略，请验证。

任何抱怨因为其中一种原因而被屏蔽的人都应该受到严厉惩罚。对于那些
最终因为其他原因而被屏蔽的人，尤其是在“异常”情况下依赖 RFC 一致性的情况，我会表示同情。垃圾邮件是一个如此大的问题，以至于没有理由不遵守基本规定。

Answer

阻止不具备以下基本功能的 SMTP 服务器的情况极为常见：

HELO 转发中的主机名解析为连接来源的 IP。
连接原始 IP 反转为 HELO 中声明的主机名。
如果存在 SPF、DKIM 或 DMARC 策略，请验证。

任何抱怨因为其中一种原因而被屏蔽的人都应该受到严厉惩罚。对于那些
最终因为其他原因而被屏蔽的人，尤其是在“异常”情况下依赖 RFC 一致性的情况，我会表示同情。垃圾邮件是一个如此大的问题，以至于没有理由不遵守基本规定。

Question 3

我希望发送 MTA 具有有效的 RDNS，但坚持匹配 EHLO 取决于“客户”是谁。您可以在以下位置找到一些有趣的指南RFC5321：

2.3.5.

(...) EHLO 命令中给出的域名必须是主主机名（解析为地址 RR 的域名），或者如果主机没有名称，则必须是地址文字 (...)

4.1.4.

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

但在 7.9 中。

一个公认的原则是，SMTP 服务器可能会因任何对于提供服务器的站点而言合理的操作或技术原因而拒绝接受邮件。(...)

Answer

我希望发送 MTA 具有有效的 RDNS，但坚持匹配 EHLO 取决于“客户”是谁。您可以在以下位置找到一些有趣的指南RFC5321：

2.3.5.

(...) EHLO 命令中给出的域名必须是主主机名（解析为地址 RR 的域名），或者如果主机没有名称，则必须是地址文字 (...)

4.1.4.

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

但在 7.9 中。

一个公认的原则是，SMTP 服务器可能会因任何对于提供服务器的站点而言合理的操作或技术原因而拒绝接受邮件。(...)

Question 4

我想知道是否还应该阻止没有与 EHLO 匹配的有效 RDNS 的主机？

不，你不应该这么做。仅根据一个标准阻止整封电子邮件是一种不好的做法。

如果我这样做，是否会给许多合法邮件带来麻烦并让我的客户感到不满？

更有可能的是，你会丢失合法的邮件

我还想知道我是否可以通过检查 RDNS 是否至少设置为某个值来妥协，但不尝试将其与 EHLO 匹配。Postfix 可以做到这一点吗（并且有用吗）？

是的，这是可能的。您可以使用reject_unknown_reverse_client_hostname 代替reject_unknown_client_hostname

不幸的是，postfix 没有灵活的“复杂决策”选项。在 exim 中，您可以为此类邮件添加一些点，例如

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

等等。所有检查完成后，如果分数 > 100，您可以拒绝邮件。实际上您可以获得这样的行为，但您需要编写自己的政策服务

Answer