Mail-receiver loses IP to hostname resolution after recent upgrade and prevents anti-spam measures from working

It seems that latest Self-hosted mail-receiver update following Let's Encrypt root certificate change mail-receiver update doesn’t resolve IPs to hostnames any more. This causes issues with previously working postfix client access restrictions, enabled by adding the following line to mail-receiver.yml:

  POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'

This is a snippet from the mail-receiver log, showing an inbound connection:

Oct 01 17:38:11 discourse-mail-receiver postfix/master[1]: reload -- version 3.5.6, configuration /etc/postfix
Oct 01 17:41:58 discourse-mail-receiver postfix/smtpd[151]: connect from unknown[167.71.160.115]
Oct 01 17:41:59 discourse-mail-receiver postfix/smtpd[151]: disconnect from unknown[167.71.160.115] ehlo=2 starttls=1 mail=1 quit=1 commands=5

What used to resolve to the hostname of the originating client www11-do.checktls.com[167.71.160.115] is now unresolved and marked unknown[167.71.160.115].

This causes conflict with the regex entries in the client_access_regex file, which is designed to reject all hosts without a valid PTR record (these are basically all spam relays) as well as all hosts from dynamic IP ranges (mostly virtual hosts, and basically all spam relays too).

Since no IP is resolved to hostname, none of the rules work any more, and even worse, the /unknown/ REJECT line now blocks all inbound email. I had to temporarily disable the rule to make the inbound connections possible at all, and all other rules are rendered inactive by the resolving issue, so this now exposes the server to spam again (my forum was flooded by spam before implementing these rules, and after they were implemented I don’t remember receiving any).

I cannot go back to the old version as a workaround (because of the letsencrypt issues), and the new version opens the spam floodgates again, so I’d be very grateful for a fix (I tried to figure out how to manually enable DNS resolution inside the docker image, but to no avail).

Here is a client_access_regex file for reference, if someone is having the same recurring spam issues and wishes to try it out (use Customising direct-delivery Postfix configuration to configure /etc/postfix/shared and mail-receiver.yml):

#  regex dns: ([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\.)+[a-zA-Z]{2,}
#  regex ip: ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
#
#  dyn-ip-dns:
/((\.|-|x)(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}((\.|-)[a-zA-Z0-9]+)+\.[a-zA-Z]{2,}/        REJECT
/unknown/                               REJECT
/sample-spam\.domain\.com/              REJECT

I did solve that for a different container. You comment out the bad cert and you’re good to go, but I’m not clear how to crank up the old container.

The solution is to go into the new container and solve the problem.

1 Like