efa-project.org

Posted: **21 Jun 2023 06:55**

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

Posted: **21 Jun 2023 09:32**

This is a good change.

Posted: **04 Jan 2025 06:32**

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

Posted: **04 Jan 2025 15:38**

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

Posted: **17 Jan 2025 23:04**

Thank you for bringing this to my attention. I will drop this configuration from postfix for new installations since it is not recommended. For existing installations I'll see if I can add the return code range to the definition.

Posted: **23 Jan 2025 19:57**

Aryfir wrote: 04 Jan 2025 15:38 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

It sounds like you're diving into the nuances of email filtering with Postfix and Spamhaus. You’re absolutely right that SpamAssassin and Rspamd should ideally handle the filtering, as they need full email context to function properly, including auto-learning. The Spamhaus recommendations about not blocking at the SMTP level make sense for more dynamic filtering and avoiding false positives.

Also, using DQS (Data Query Service) is a solid solution, especially since it allows flexibility in releasing emails and adapting to potential updates or changes from Spamhaus. The integration with Efa Project is a nice touch for fine-tuning your setup.

Posted: **07 Feb 2025 14:18**

I have tried to change my setup (eFav5) towards DQS Service according this guide:
https://docs.spamhaus.com/datasets/docs ... stfix.html

However, the blocklist-tester shows no filtering results, i.e. the test e-mails are coming in...

Has anybody a hint for me what I could check:

Part of /etc/postix/main.cf:

Code: Select all

relay_domains = hash:/etc/postfix/transport
transport_maps = hash:/etc/postfix/transport
rbl_reply_maps = hash:/etc/postfix/dnsbl-reply-map
smtpd_recipient_restrictions =
    reject_rbl_client my_key.zen.dq.spamhaus.net=127.0.0.[2..11],
    reject_rhsbl_sender my_key.dbl.dq.spamhaus.net=127.0.1.[2..99],
    reject_rhsbl_helo my_key.dbl.dq.spamhaus.net=127.0.1.[2..99],
    reject_rhsbl_reverse_client my_key.dbl.dq.spamhaus.net=127.0.1.[2..99],
    reject_rhsbl_sender my_key.zrd.dq.spamhaus.net=127.0.2.[2..24],
    reject_rhsbl_helo my_key.zrd.dq.spamhaus.net=127.0.2.[2..24],
    reject_rhsbl_reverse_client my_key.zrd.dq.spamhaus.net=127.0.2.[2..24],
    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,
    permit

Posted: **11 Feb 2025 06:53**

Your method above is blocking at smtp level, although it is not recommended because eFa has a spamassassin (please read from the page you provided).

But i assume that you already got registered DQS key, remove the comma at the end of each record (except if you put it all in one line)

BR

Posted: **12 Feb 2025 10:22**

Aryfir wrote: 11 Feb 2025 06:53 Your method above is blocking at smtp level, although it is not recommended because eFa has a spamassassin (please read from the page you provided).

Yes, you're right. However, I am asking myself what would fit better for my setup. Deny to enter my eFa appliance and to kept processing and storage clean or to follow the guideline you have mentioned?

The reason for not filtering on smtp side was a simple reason: I was toogling greylisting with eFa-configure and as a result the a.m. filters were automatically removed/ deleted from the main.cf.

Finally I have decided to follow the recommendation not to filter on the smtp level and use the spamassassin DQS service as mentioned and linked above. Thank you for your helpful advise!

efa-project.org

EFA's incorrect handling of zen.spamhaus.org

EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org

Re: EFA's incorrect handling of zen.spamhaus.org