EFA's incorrect handling of zen.spamhaus.org

[LBJ]

G'day All,

We've just started testing EFA. It's a great product, but I believe the default inclusion for zen in postfix's main.cf file is such that it can easily lead to the full rejection of all email when spamhaus spits their dummy as they tend to do of late.

EFA correctly provides a solution for local DNS resolution, which is essential for using zen, but the configuration in postfix for lookups in the zen DNSBL is simply included as...

Code: Select all

smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rbl_client zen.spamhaus.org

That will react to *any* return code provided by zen, and that's what leads to great disappointment for email admins when all incoming email starts being rejected due to spamhaus hitting you with their incorrectly named "open resolver" complaint. If they believe you're a commercial operation without a paid account, or non-commercial but hitting their servers too heavily, they'll quickly start returning a 127.255.255.254 or 127.255.255.255 value.

As per the spamhaus documentation, their system isn't limited to the basic return values in the range 127.0.0.[2..11] for listed IPs. They can also return a value of 127.255.255.0/24.

The 127.255.255.0/24 values are used to signify a rejection of the actual request itself for a few different reasons - excessive request rate, perceived public DNS server traits, open resolvers, and more. Rejecting email based on a return value in that range is simply wrong and will result in rejecting all email while spamhaus are returning their 127.255.255.0/24 values.

Point number 1 covers this in the spamhaus documentation at...

https://www.spamhaus.com/product/help-f ... ror-users/

The correct method of inclusion for zen should be along the lines of...

Code: Select all

smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]

Similarly, to protect against future surprises, all DNSBLs should include an appended IP range specification to avoid late night server alerts and client support tickets. If the DNSBL typically returns 127.0.0.2, then it's best to limit rejections to that expected value, so for example...

Code: Select all

... b.barracudacentral.org=127.0.0.2

...rather than just...

Code: Select all

... b.barracudacentral.org

[pdwalker]

This is a good change.

[betsys]

FWIW I just built a new efa5 server and hit this same issue, everything rejected with Service unavailable; Client host [] blocked using zen.spamhaus.org; Error: open resolver; https://check.spamhaus.org/returnc/pub/...

the change mentioned above did the trick

[Aryfir]

I would like to expand this discussion

Based on information from the Spamhaus Project:

NOTE: If you use Postfix with Rspamd or SpamAssassin, you should not configure rejections at the SMTP level. Instead, use a milter and let SpamAssassin or Rspamd do the filtering. We recommended this because both SpamAssassin and Rspamd should be viewed as an anti-spam framework i.e., they need all the relevant information relating to an email to utilize their auto-learning features, so they filter emails effectively.

Postfix main.cf

Code: Select all

smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  reject_non_fqdn_recipient
  reject_unknown_recipient_domain
  check_recipient_access hash:/etc/postfix/recipient_access
  reject_unverified_recipient
  reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
  reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99]
  reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99]
  reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99]
  warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255]

But according to Spamhaus:

Blocking at the SMTP level is only suggested if you have a moderately high email volume (more than 200,000 emails per day), low computing resources, or if you do not use additional anti-spam software.

https://docs.spamhaus.com/datasets/docs ... figuration

BTW, Spamhaus gave us FREE DQS (Data Query Service).

I implemented it and it works great (use Instructions for SpamAssassin 4.0.0+ for Efa Project 5).
The advantage is that I can still release emails that are not spam but have a high spam score (caused by Spamhaus cf instead of reject) in Efa Project, or if Spamhaus makes changes that cause incorrect handling as in the case above.
https://github.com/spamhaus/spamassassin-dqs