拒绝没有RDNS的邮件服务器的邮件是好的做法还是过于严厉


20

我最近删除了SpamAssassin,现在基于DNSRBL,灰名单和其他基本测试来拒绝垃圾邮件,我想知道是否也应该阻止没有与EHLO匹配的有效RDNS的主机?

如果这样做,我是否会为很多合法邮件惹上麻烦并使我的客户不安?我听说有人抱怨AOL会这样做,这使我认为这样做对我来说太罕见了。

我也想知道我是否可以通过检查RDNS是否至少设置为某种值而不让它与EHLO匹配来妥协。Postfix可以做到这一点吗(有用)?


4
是的,即使很少有人对此有疑问,也很常见。请参阅反垃圾邮件-作为管理员,我可以做什么:电子邮件管理员,域所有者或用户?有待进一步讨论。
迈克尔·汉普顿


许多个月前,在Red Hat中全新安装sendmail的反向查找是默认的...我认为rDNS虽然不是邮件服务器的正式标准,但实际上是事实上的标准。它用动态IP地址(即具有消费级ISP连接的家庭)将人们搞砸了,但是曾经很久以前,那些带有连接的动态IP大部分是僵尸网络...如今不知所措。
艾利·佩恩

Answers:


10

我尝试了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

1
另一个好的方法是对照与ISP动态分配的各种名称(例如xxxx.dynamic.yyy.com或)匹配的正则表达式列表检查主机名12-34-56-78.dsl.zzz.com。所有此类主机均应通过ISP的中继而不是直接将其邮件发送到收件人的MX。这些主机主要是僵尸网络节点及其用于学习贝叶斯的消息。
Kondybas 2013年

看来这可能是我的解决方案。有没有一种方法可以运行SpamAssassin,并且让所有人绕开它,除了那些HELO与RDNS匹配失败的邮件之外,我们只退回一定分数以上的邮件?其他邮件继续完全绕过此步骤。
彼得·斯诺

使用exim MTA,我可以按顺序进行操作:对照白名单检查发件人的地址/主机。如果匹配-立即接受,否则对照黑名单进行检查。如果匹配-可变标志引发“ Gotcha!” 并且消息也被接受。如果消息已通过列表传递-它将传递到充当守护程序的SA。如果返回值足够高,则标记“ Gotcha!”。提出并接受消息。然后消息传递到路由器。
Kondybas 2013年

1
如果未提高标志,则照常传递消息。否则,将产生盲目副本。原始消息再次照常传递,而BC传递给具有sa学习功能的特殊路由器。这种方案允许将邮件流划分为学习SA-Bayes的绝对垃圾邮件分支,并对由SA-Bayes检查的其余部分进行怀疑。带有标志的邮件还具有一个附加的标头,可以将其分类为“垃圾”
Kondybas 2013年

我对照我的邮箱检查了这些规则,并且由于非域HELO或缺少反向DNS记录,有一些电子邮件将被拒绝。诚然,它们很少(邮箱中只有几个发件人,包含40 000封电子邮件),但是那里有重要的内容。特别是,如果我使用过,那么不会reject_unknown_reverse_client_hostname收到包含我到特定东南亚国家的签证申请结果的电子邮件。我建议不要使用reject_invalid_helo_hostnamereject_unknown_reverse_client_hostname
michau

12

阻止不具备这些基本知识的SMTP服务器是非常普遍的:

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

任何因这些原因之一而被阻塞的人都应该涂上柏油和羽毛。
最终由于其他原因而被阻止的人,特别是在“异常”情况下依赖RFC一致性的情况,我将表示同情。垃圾邮件是一个问题,尽管缺少基本知识,但没有任何借口。


2
完全不需要反向搜索名称即可匹配HELO。主机可以操作许多域,而反向查找仅返回一个主名称。
Kondybas 2013年

1
当然,您可以做任何您想做的事。您的服务器511 Your rDNS doesn't match your HELO将从我的服务器以及其他许多服务器上获得。垃圾邮件是一个主要问题,SMTP RFC的设计人员无需处理。实际要求与RFC几乎没有什么不同。
克里斯S

正确配置MTA后,垃圾邮件不是问题。我的经验表明(rDNS OR匹配短本地正则表达式列表贝叶匹配失败OR)检测到99.99%的垃圾邮件。没有DNSBL,没有灰名单,没有DKIM,没有SPF。每月超过200k的传入消息。1-2次false-p,每月10-20次false-n。
Kondybas 2013年

5

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

2.3.5。

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

4.1.4。

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

但随后是7.9。

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


1
这可能被禁止,因为在现实世界中,随EHLO发送的字符串通常不符合RFC。我看到了内部主机名,localhost以及许多其他错误的消息,即使使用完全合法的邮件也是如此。
迈克尔·汉普顿

3

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

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


1
“很明显,两个FQDN都是不同的-这是完全可以接受的。” 不能。您只能配置一个PTR记录,并且邮件服务器只能在HELO中声明一个主机名。因此很明显,两者可以匹配。
克里斯S

2

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

不,你不应该。仅根据一个条件阻止整个电子邮件,这是一种不良做法。

如果这样做,我是否会为很多合法邮件惹上麻烦并使我的客户不安?

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

我也想知道我是否可以通过检查RDNS是否至少设置为某种值而不让它与EHLO匹配来妥协。Postfix可以做到这一点吗(有用)?

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

不幸的是,后缀没有用于“复杂决策”的灵活选项。在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,则可以拒绝邮件。实际上您可以得到这种行为,但是您需要编写自己的策略服务

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.