拒绝RDNS邮件服务器的邮件是好的做法还是太苛刻了

我最近放弃了SpamAssassin,现在正在将垃圾邮件拒绝列入DNSRBL,灰名单和其他基本testing,我想知道我是否也应该阻止没有有效的RDNS匹配EHLO的主机?

如果我这样做,我会为许多合法的邮件惹麻烦,让我的客户不高兴? 我听说有人抱怨美国在线这样做,这让我觉得这样做可能太less了。

我也想知道,如果我可以通过检查RDNS至less设置某些东西来达成妥协,但不会尝试将其与EHLO相匹配。 这是可能的Postfix(和它是有用的)?

我已经尝试了HELO / EHLO的多种方法,用一个相当体面的大小为10万到20万个用户的客户群进行检查,最终find了一个解决scheme:

  • 检查HELO / EHLO是否包含域名。 – 这大多归结为名称有一个点。 检查名称上的DNS导致许多失败的服务器,因为它很less有服务器提供内部名称或您无法正确parsing的东西。
  • 检查IP是否有反向DNSlogging。 – 再次,这是一个松散的设置,因为我们不检查对HELO / EHLO。 检查HELO / EHLO创造了如此多的门票这个设置不会持续一天。
  • 检查发件人域名是否有效。 – 这是一个基本的检查,以确保如果我们必须反弹消息至less有一些方法来find它的服务器。

这是我们用于这些检查的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 

阻止没有这些基础知识的SMTP服务器是非常常见的:

  1. HELO中的主机名向前parsing为源自于的IP连接。
  2. 连接源IP反转为HELO中声明的主机名。
  3. 如果存在SPF,DKIM或DMARC策略,请进行validation。

任何人因为其中一个而被堵塞,都应该涂柏油和羽毛。
最终由于其他原因而被封锁的人,特别是在“exception”情况下依赖于RFC的情况下,我会同情。 垃圾邮件是一个问题,没有任何借口可以忽略基本知识。

我希望发送MTA有效的RDNS,但坚持匹配EHLO将取决于谁是“客户”。 您可以在RFC5321中find一些有趣的指导:

2.3.5。

(…)EHLO命令中给出的域名必须是主要主机名(parsing为地址RR的域名),或者如果主机没有名称,则地址字符(…)

4.1.4。

(…)SMTP服务器可以validationEHLO命令中的域名参数实际上是否与客户端的IP地址相对应。 但是,如果validation失败,则服务器不得以此为基础拒绝接受消息。

但在7.9。

(…)(…)(…)(…)(…)(…)(…)(…)

反向查找不一定指向HELO中提供的主机名。 有时在同一个主机上托pipe多个域,并且它们都具有相同的IP地址。 但是,当您尝试进行反向查找时,您将获得已放置在PTRlogging中的名称。 很明显,两个FQDN将是不同的 – 这是完全可以接受的。

允许丢弃消息的唯一情况是反向查找失败。 任何成功的查找意味着主机是有效的。 名称不应该匹配。

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

不,你不应该。 阻止整个电子邮件只有一个标准这是一个不好的做法。

如果我这样做,我会为许多合法的邮件惹麻烦,并打乱我的客户?

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

我也想知道,如果我可以通过检查RDNS至less设置某些东西来达成妥协,但不会尝试将其与EHLO相匹配。 这是可能的Postfix(和它是有用的)?

是的,这是可能的。 您可以使用reject_unknown_reverse_client_hostname而不是reject_unknown_client_hostname

不幸的是,postfix没有“复杂决策”的灵活选项。 在进出口,你可以添加一些点这样的邮件,例如

 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 "dddd" 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 ... 

等等。 所有检查完成后,如果您的Score> 100,您可以拒绝邮件。 其实你可以得到这样的行为,但是你需要写自己的政策服务