dns_blocklists.cf isn't appended to main.cf and therefore ineffective

DocFraggle commented 1 year ago

Contribution guidelines

[X] I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

[X] ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
[X] ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
[X] ... I have understood that answers are voluntary and community-driven, and not commercial support.
[X] ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

Hello, I updated my Mailcow to the latest version two days ago. Yesterday I saw the blog post about Spamhaus and the DQS key, so I created one and added it to mailcow.conf. After restarting I used the Blacklist tester of Spamhaus and was very confused why all test mails where delivered to my inbox.

So I debugged the Postfix container and discovered that the parameter postscreen_dnsbl_sites wasn't shown at all using postconf -n.

I debugged the scripts starting up the container and found that the newly created file dns_blocklists.cf isn't appended to main.cf as it is done with extra.cf in postfix.sh:

https://github.com/mailcow/mailcow-dockerized/blob/020cb21b35723339008d745c479cd039dca7475b/data/Dockerfiles/postfix/postfix.sh#L540

Those currently results in no active DNS blocklists at all!

Logs:

root@18ce9af942be:/# postconf -n | grep postscreen
postscreen_access_list = permit_mynetworks, cidr:/opt/postfix/conf/custom_postscreen_whitelist.cidr, cidr:/opt/postfix/conf/postscreen_access.cidr, tcp:127.0.0.1:10027
postscreen_bare_newline_enable = no
postscreen_blacklist_action = drop
postscreen_cache_cleanup_interval = 24h
postscreen_cache_map = proxy:btree:$data_directory/postscreen_cache
postscreen_discard_ehlo_keywords = silent-discard, dsn
postscreen_dnsbl_action = enforce
postscreen_dnsbl_threshold = 6
postscreen_dnsbl_ttl = 5m
postscreen_greet_action = enforce
postscreen_greet_banner = $smtpd_banner
postscreen_greet_ttl = 2d
postscreen_greet_wait = 3s
postscreen_non_smtp_command_enable = no
postscreen_pipelining_enable = no
root@18ce9af942be:/#

Steps to reproduce:

Just update your Mailcow to the latest version including the Spamhaus DQS fix.
Connect to your Postfix container and have a look at the output of

postconf -n | grep postscreen

Which branch are you using?

master

Operating System:

Rocky 8

Server/VM specifications:

16G, 4 cores

Is Apparmor, SELinux or similar active?

No

Virtualization technology:

Hetzner Cloud VM

Docker version:

24.0.2

docker-compose version or docker compose version:

v2.6.1

mailcow version:

2023-07

Reverse proxy:

N/A

Logs of git diff:

N/A

Logs of iptables -L -vn:

N/A

Logs of ip6tables -L -vn:

N/A

Logs of iptables -L -vn -t nat:

N/A

Logs of ip6tables -L -vn -t nat:

N/A

DNS check:

N/A

DocFraggle commented 1 year ago

If you put the content of dns_blocklists.cf to extra.cf and restart the container postscreen_dnsbl_sites is set looking at the 'postconf -n' output

DocFraggle commented 1 year ago

https://github.com/mailcow/mailcow-dockerized/pull/5342/files should fix this issue

sriccio commented 1 year ago

https://github.com/mailcow/mailcow-dockerized/pull/5342/files should fix this issue

Hello,

Nice one, thanks :)

However shouldn't this be somehow optional. I mean if some admin doesn't want to use DNSBLs to block things at SMTP level, or at least not use all of these ?

Source: https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html

Kind regards

sriccio commented 1 year ago

Oh, I think there's an issue with the generated dns_blocklists.cf.

postscreen_dnsbl_sites has white spaces in front of it.

AFAIK, in postfix configs, it means the line is a continuation of previous line and therefore will cause trouble.

DocFraggle commented 1 year ago

@sriccio you are right, I fixed this yesterday during debugging but forgot to add the change to my PR...

Next is the wrong domain in some of the Spamhaus lines, it's .net, not .org

Unfortunately the whole postscreen setup works only partially on my server... Using the blocklist test of Spamhaus only two of the test emails are actually blocked. After I used the setup proposed by Spamhaus

        reject_rhsbl_sender         XXXXXXXXXX.dbl.dq.spamhaus.net=127.0.1.[2..99],
        reject_rhsbl_helo           XXXXXXXXXX.dbl.dq.spamhaus.net=127.0.1.[2..99],
        reject_rhsbl_reverse_client XXXXXXXXXX.dbl.dq.spamhaus.net=127.0.1.[2..99],
        reject_rhsbl_sender         XXXXXXXXXX.dbl.dq.spamhaus.net=127.0.2.[2..24],
        reject_rhsbl_helo           XXXXXXXXXX.zrd.dq.spamhaus.net=127.0.2.[2..24],
        reject_rhsbl_reverse_client XXXXXXXXXX.zrd.dq.spamhaus.net=127.0.2.[2..24],
        reject_rbl_client           XXXXXXXXXX.zen.dq.spamhaus.net=127.0.0.[2..255]

in the list of smtpd_recipient_restriction all of the test mails were blocked successfully

DocFraggle commented 1 year ago

Ok, the latter may be due to the postscreen cache, while not working properly the test mails may have been added to the allow cache, I have to test this as soon as I'm home

Update. I tested this by setting the cache to 2 seconds. Didn't help only the extra config above worked to block all test mails.

sriccio commented 1 year ago

Ok @DocFraggle :)

Hmm what about to have this as an option and not be forced into the postfix config ? I mean how could I disable it, when I don't want postfix to block this at SMTP level but let it reach rspamd.

Actually, my own opinion though, I think it's better to let rspamd handle this. If you set enough score so rspamd issue a reject for these, it is kinda like having it rejected directly by postfix but with more flexibility ...

There is acutally all what is needed to integrate it with rspamd: https://github.com/spamhaus/rspamd-dqs

mailcow / mailcow-dockerized