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

Product Support

AI-generated summary

md-misko reports that after upgrading the self-hosted mail-receiver (due to Let’s Encrypt root certificate changes), IP-to-hostname resolution has stopped working, causing Postfix client restrictions to fail. This breaks anti-spam rules configured via client_access_regex, which rely on resolving hostnames to reject spam sources — including dynamic IPs and hosts without PTR records. The log now shows connections as unknown[IP] instead of resolving to hostnames like www11-do.checktls.com[IP], rendering rules ineffective and even blocking all mail due to the /unknown/ REJECT line. Temporarily disabling the rule restores inbound mail but leaves the server vulnerable to spam. Rolling back is not viable due to certificate issues. pfaffman suggests workarounds for the cert issue but confirms the core fix must be applied inside the new container. md-misko submitted a pull request (#12) to resolve the issue by removing Postfix from the chroot jail, asking for security review — noting that Postfix is already isolated in Docker, so the change should be safe.

1

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 Customize 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
2

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.

3

https://github.com/discourse/mail-receiver/pull/12

@david This should fix both issues mentioned in Self-hosted mail-receiver update following Let's Encrypt root certificate change - #6 by md-misko

Please evaluate whether removing postfix from the chroot jail introduces any security issues (IMO it shouldn’t, as postfix is already isolated inside a dedicated docker image).