📬 Repeated Postfix warnings and connections after valid_recipients implementation

Product Support

AI-generated summary

Ethsim2 reports repeated Postfix warnings and inbound connection attempts every ~6 minutes after implementing valid_recipients filtering via /etc/postfix/valid_recipients, with logs showing malformed lines (“expected format: key whitespace value”). These warnings coincide with repeated unauthenticated connections from 198.55.98.3. Legitimate mail (e.g., from Microsoft 365) still delivers successfully. Ethsim2 asks whether the warnings trigger the connections, if Postfix loops on malformed entries, whether to disable check_recipient_access temporarily, and for a working valid_recipients example. In post 2, Ethsim2 confirms they manually edited main.cf, which Discourse’s AI helper advises against — instead recommending using environment variables like POSTCONF_smtpd_recipient_restrictions in mail-receiver.yml to avoid conflicts and overwrites. The AI also notes the warnings stem from incorrect file formatting, not necessarily causing the connection loops. In post 3, Ethsim2 confirms reply-by-email now works, implying the legacy valid_recipients setup was blocking it. The core issue appears to be misconfigured recipient file format and improper Postfix configuration via direct main.cf edits rather than Discourse’s recommended env-variable method.

1

Continuing the discussion from Email receive issue:

I implemented valid_recipients filtering via postfix/valid_recipients and populated /etc/postfix/valid_recipients. Since then, I’m seeing repeated warnings and inbound connection attempts every ~6 minutes. Here’s a sanitized segment of my log.

:warning: Exact log output

Jul 23 05:13:40 ubuntu-mail-receiver postfix/smtpd[2265]: warning: /etc/postfix/valid_recipients, line 1: expected format: key whitespace value -- ignoring this line
Jul 23 05:13:40 ubuntu-mail-receiver postfix/smtpd[2265]: warning: /etc/postfix/valid_recipients, line 2: expected format: key whitespace value -- ignoring this line
...
Jul 23 05:13:40 ubuntu-mail-receiver postfix/smtpd[2265]: warning: /etc/postfix/valid_recipients, line 16: expected format: key whitespace value -- ignoring this line

These warnings appear every few minutes, aligned with repeated unauthenticated connection attempts like:

Jul 23 05:13:40 ubuntu-mail-receiver postfix/smtpd[2265]: warning: hostname unassigned.quadranet.com does not resolve to address 198.55.98.3
Jul 23 05:13:40 ubuntu-mail-receiver postfix/smtpd[2265]: connect from unknown[198.55.98.3]
Jul 23 05:13:40 ubuntu-mail-receiver postfix/smtpd[2265]: disconnect from unknown[198.55.98.3] ehlo=1 auth=0/1 quit=1 commands=2/3

This same pattern repeats from 198.55.98.3 over dozens of cycles throughout the hour.

:white_check_mark: Legitimate mail passes through

Just to confirm, legitimate deliveries (e.g. from Microsoft 365) are working:

Jul 23 05:46:53 ubuntu-mail-receiver postfix/smtpd[2290]: connect from mail-uksouthazon11020141.outbound.protection.outlook.com[52.101.196.141]
Jul 23 05:46:54 opendkim[25]: D3D4A1BF983: DKIM verification successful
Jul 23 05:46:54 opendmarc[40]: D3D4A1BF983: MYDOMAINNAME.com pass
Jul 23 05:46:54 ubuntu-mail-receiver postfix/pipe[2296]: to=<person.REDACTED@discourse.MYDOMAINNAME.com>, relay=discourse, status=sent (delivered via discourse service)

:red_question_mark:Questions

  1. Are the /etc/postfix/valid_recipients warnings responsible for triggering the repeated connections?
  2. Should I expect Postfix to loop on these entries if the file is misformatted?
  3. Would you recommend temporarily disabling check_recipient_access to test stability?
  4. Is there a preferred example of a valid_recipients file used with the mail-receiver container for Discourse?

:puzzle_piece: My main.cf line (for reference)

smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/valid_recipients, reject

Would really appreciate some guidance here — thanks in advance!

2
How to Reload Postfix with Discourse AI

Ethsim2:

is it correct that i did modify main.cf

DiscourseHelper:

Searching

Searching for: Is it necessary or recommended to manually modify postfix main.cf when implementing a valid_recipients file for recipient restrictions in a Discourse mail-receiver container? Should main.cf be edited directly, or are all recommended changes handled by docker environment variables or launcher yml settings for Discourse mail-receiver setups?

Reading

Read: 📬 Repeated Postfix warnings and connections after valid_recipients implementation

No, it is not necessary or recommended to manually modify main.cf in the mail-receiver container for valid recipient filtering when following Discourse’s standard setup.

Correct Approach:
Discourse’s official mail-receiver guide and container setup is designed so you do not edit main.cf by hand. Instead:

  • You should use the mail-receiver.yml’s env section to set Postfix parameters—specifically, using an environment variable like:

    POSTCONF_smtpd_recipient_restrictions: texthash:/etc/postfix/valid_recipients

    or, if you use the older config style:

    POSTCONF_smtpd_recipient_restrictions: check_recipient_access hash:/etc/postfix/valid_recipients, reject

  • Docker/launcher correctly applies these settings on container startup, injecting them into Postfix without needing to directly edit files.

Editing main.cf directly can cause conflicts or be overwritten on container rebuilds. It’s also easy to break things (such as file format or recipient mapping) this way.

About Your Error:
The warnings you see:

warning: /etc/postfix/valid_recipients, line 1: expected format: key whitespace value -- ignoring this line

are caused by a misformatted valid_recipients file—not by how the config is set (env vs main.cf). Make sure your entries are like:

alloweduser@yourdomain.com OK
another@yourdomain.com OK
default REJECT

No colons, equals, or commas—just the address, whitespace, and OK (or REJECT).

Do not edit main.cf unless you have a highly advanced, fully custom configuration and understand exactly what you are doing.
All normal instructions (including valid recipient and sender filtering) are performed by setting environment variables in mail-receiver.yml.

References:

Summary:
You should not need to touch main.cf for standard Discourse mail-receiver setups. Environment variables in the yml are the recommended, supported way. For recipient maps, always use proper hash/texthash formats and correct file syntax.

actually i’ve removed the custom configuration entirely, the configuration described here, and my mail test worked fine.

x86_64 arch detected.
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 600 mail-receiver
mail-receiver
release: Pulling from discourse/mail-receiver
Digest: sha256:2a0d45bb92a783c846a821e635413764eeadb3441ef6190085545a4[9 digits redacted]
Status: Image is up to date for discourse/mail-receiver:release
docker.io/discourse/mail-receiver:release
ERROR:  Can't find Ruby library file or shared library pups
cd /pups && /pups/bin/pups --stdin
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
sha256:[6 digits redacted]69734d779a95ec83c7103dc2fc04f1d690ebde62[18 digits redacted]
[64 character API Key? Redacted]
Removing old container
+ /usr/bin/docker rm mail-receiver
mail-receiver

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e MAIL_DOMAIN=discourse. MYDOMAINNAME.com -e DISCOURSE_BASE_URL=https:// MYDOMAINNAME.com -e DISCOURSE_API_KEY=[64 digit API key redacted] -e DISCOURSE_API_USERNAME=system -h ubuntu-mail-receiver -e DOCKER_HOST_IP=172.17.0.1 --name mail-receiver -t -p 25:25 -v /var/discourse/shared/mail-receiver/postfix-spool:/var/spool/postfix --mac-address [redacacted mac address] local_discourse/mail-receiver /sbin/boot
[64 digit API key? Redacted]
root@ubuntu:/var/discourse# ./launcher logs mail-receiver
x86_64 arch detected.
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Operating environment:
HOSTNAME=ubuntu-mail-receiver
LANGUAGE=en_US.UTF-8
MAIL_DOMAIN=discourse.MYDOMAINNAME.com
DOCKER_HOST_IP=172.17.0.1
PWD=/
DISCOURSE_BASE_URL=https:// MYDOMAINNAME.com
HOME=/root
LANG=en_US.UTF-8
TERM=xterm
SHLVL=1
DISCOURSE_API_USERNAME=system
LC_ALL=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
INCLUDE_DMARC=true
DISCOURSE_API_KEY=[64 digit API key redacted]
_=/usr/bin/env
Delivering mail sent to discourse. MYDOMAINNAME.com to Discourse
Starting OpenDKIM...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US.UTF-8",
        LC_ALL = "en_US.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Adding user `postfix' to group `opendkim' ...
<86>Jul 23 13:27:19 usermod[16]: add 'postfix' to group 'opendkim'<86>Jul 23 13:27:19 usermod[16]: add 'postfix' to shadow group 'opendkim'Done.
Starting OpenDMARC...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US.UTF-8",
        LC_ALL = "en_US.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
<22>Jul 23 13:27:19 opendkim[24]: OpenDKIM Filter v2.11.0 starting (args: -x /etc/opendkim.conf)Adding user `postfix' to group `opendmarc' ...
<86>Jul 23 13:27:19 usermod[31]: add 'postfix' to group 'opendmarc'<86>Jul 23 13:27:19 usermod[31]: add 'postfix' to shadow group 'opendmarc'Done.
<22>Jul 23 13:27:19 opendmarc[39]: OpenDMARC Filter v1.4.2 starting (args: -c /etc/opendmarc.conf)<22>Jul 23 13:27:19 opendmarc[39]: additional trusted authentication services: (none)postfix: Postfix is using backwards-compatible default settings
Jul 23 13:27:19 ubuntu-mail-receiver postfix[51]: Postfix is using backwards-compatible default settings
postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
Jul 23 13:27:19 ubuntu-mail-receiver postfix[51]: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
Jul 23 13:27:19 ubuntu-mail-receiver postfix[51]: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
Starting Postfix
Jul 23 13:27:19 ubuntu-mail-receiver postfix/master[1]: daemon started -- version 3.7.11, configuration /etc/postfix
Jul 23 13:27:53 ubuntu-mail-receiver postfix/smtpd[122]: connect from mail-il1-f180.google.com[209.85.166.180]
<22>Jul 23 13:27:54 policyd-spf[129]: : prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.166.180; helo=mail-il1-f180.google.com; envelope-from= person@gmail.com; receiver=discourse. MYDOMAINNAME.com Jul 23 13:27:54 ubuntu-mail-receiver postfix/smtpd[122]: BC6D71BF9C8: client=mail-il1-f180.google.com[209.85.166.180]
Jul 23 13:27:54 ubuntu-mail-receiver postfix/cleanup[130]: BC6D71BF9C8: message-id=<CWXP1[redacted 8 digits]81B627937FA7F4B2CE65A15FA@CWXP123MB2918.GBRP123.PROD.OUTLOOK.COM>
<22>Jul 23 13:27:55 opendkim[24]: BC6D71BF9C8: DKIM verification successful<22>Jul 23 13:27:55 opendkim[24]: BC6D71BF9C8: s=20230601 d=gmail.com a=rsa-sha256 SSL <22>Jul 23 13:27:55 opendmarc[39]: implicit authentication service: ubuntu-mail-receiver.localdomain<22>Jul 23 13:27:55 opendmarc[39]: BC6D71BF9C8: gmail.com passJul 23 13:27:55 ubuntu-mail-receiver postfix/qmgr[120]: BC6D71BF9C8: from=<person@gmail.com>, size=75533, nrcpt=1 (queue active)
Jul 23 13:27:55 ubuntu-mail-receiver postfix/smtpd[122]: disconnect from mail-il1-f180.google.com[209.85.166.180] ehlo=1 mail=1 rcpt=1 bdat=2 quit=1 commands=6
<23>Jul 23 13:27:55 receive-mail[133]: Recipient: person.REDACTED@discourse. MYDOMAINNAME.comJul 23 13:27:55 ubuntu-mail-receiver postfix/pipe[132]: BC6D71BF9C8: to=< person.REDACTED@discourse. MYDOMAINNAME.com>, relay=discourse, delay=1.8, delays=1.6/0.01/0/0.22, dsn=2.0.0, status=sent (delivered via discourse service)
Jul 23 13:27:55 ubuntu-mail-receiver postfix/qmgr[120]: BC6D71BF9C8: removed
3

reply by email now works on my forum, the legacy valid_recipients thing would have blocked that