Sieve redirect broken: inet_protocols=ipv4 + rspamd re-scanning forwards

CaptainPalapa

Note: This is an AI written summary of the issue I experienced this morning. I had it help me fix the issue, and it did, but I’m concerned about editing files that may be overwritten during the next run of the update.sh script.

Begin AI issue summary:
I’m migrating my mailcow-hosted domains from Gmail POP3 fetching to sieve forwarding, since Google is dropping POP3 support. I configured forwarding to Gmail addresses via the mailcow UI. Forwarding was completely non-functional. After debugging, I found two separate issues that had to be fixed independently.

Issue 1: Dovecot cannot reach Postfix on port 588 when inet_protocols = ipv4 is set

Dovecot’s submission_host = postfix:588 resolves to the IPv6 address of the Postfix container when the Docker network has enable_ipv6: true. If Postfix has inet_protocols = ipv4 set (via extra.cf), it only binds on IPv4, and the connection is refused:

smtp-client: conn postfix:588 ([fde4:xxxx:xxxx::xx]:588): connect(postfix:588) failed: Connection refused

sieve: redirect action: failed to redirect message: smtp(postfix:588): RCPT TO failed: Failed to connect to remote server (temporary failure)

smtp-client: conn postfix:588 ([fde4:xxxx:xxxx::xx]:588): connect(postfix:588) failed: Connection refusedsieve: redirect action: failed to redirect message: smtp(postfix:588): RCPT TO failed: Failed to connect to remote server (temporary failure)

This is a mismatch between Docker’s dual-stack networking and Postfix’s IPv4-only configuration. The inet_protocols = ipv4 setting is common — users set it to avoid IPv6 outbound delivery issues, and smtp_address_preference = ipv4 alone doesn’t prevent IPv6 DNS lookups.

Fix: Changed inet_protocols = ipv4 to inet_protocols = all in data/conf/postfix/extra.cf, keeping smtp_address_preference = ipv4 for outbound preference.

Suggestion for mailcow: Dovecot’s submission_host could reference Postfix by its static IPv4 address (e.g., ${IPV4_NETWORK}.253:588) instead of the hostname, making it immune to IPv6 resolution issues. Alternatively, the documentation could warn that inet_protocols = ipv4 in extra.cf will break sieve redirects.

Issue 2: rspamd re-scans sieve-redirected mail and rejects/greylists it

After fixing the connectivity issue, forwarded mail was being rejected or greylisted by rspamd. The sieve redirect submits mail back through Postfix port 588, which passes through rspamd (milters are inherited from main.cf). rspamd scans the already-delivered message a second time, and the forwarded copy scores badly because:

R_SPF_FAIL (6): The Docker container’s internal IP isn’t in any public SPF record
VIOLATED_DIRECT_SPF (3.5): Additional SPF penalty
HFILTER_HELO_5 (3): The container’s internal HELO hostname looks suspicious to rspamd

These penalties easily push the score above the reject threshold (₁₅) or greylist threshold, even for completely legitimate mail. I tested with both external mail (via https://sendtestemail.com/) and internal mail between two domains on the same mailcow instance — both were blocked on the forwarding leg.

This is particularly frustrating because the mail was already scanned and accepted on intake. The second scan is redundant and harmful.

Fix: Added a dedicated port in master.cf for sieve redirects that bypasses rspamd:

# sieve redirect bypass - skip milters for already-scanned forwarded mail
5870 inet n      -       n       -       -       smtpd
  -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_tls_auth_only=no
    -o smtpd_milters=
    -o non_smtpd_milters=
    -o cleanup_service_name=smtp_sender_cleanup
    -o syslog_name=postfix/sieve-redirect

Then created data/conf/dovecot/extra.conf:

submission_host = postfix:5870

This keeps port 588 intact for SOGo (with rspamd scanning) and gives sieve redirects a clean path that doesn’t re-scan.

Suggestion for mailcow: This feels like it should be the default behavior. Sieve redirects are for mail that has already passed rspamd on intake — re-scanning them through milters on port 588 causes false rejections for any forwarding setup. A dedicated submission port for Dovecot sieve redirects (separate from SOGo’s port 588) with milters disabled would fix this out of the box.

Concern about persistence:

Both fixes involve files (master.cf, extra.cf, extra.conf) that may be overwritten by update.sh. The extra.cf and extra.conf files should be safe, but the master.cf addition is at risk. It would be great if mailcow had a master.cf override mechanism similar to extra.cf/extra.conf.

Environment: mailcow-dockerized (latest as of Feb 2026), Postfix 3.7.11, Dovecot 2.3.21, Docker with IPv6 enabled.

(Note: Multiple edits were to clean up the markdown so it wasn’t ugly!)

ETNyx

Well lot of to read :-) Why you are forcing services to IPv4 only? IPv6 is standard part of stack, it’s 2026!

Seems to me, you are manually disabling IPv6 per service, this is not the way. Check docs how to disable IPv6 . Be aware this document contains several approaches to this topic based on MC version, Docker version. Up to date installation should be easy now.

CaptainPalapa

ETNyx Initially, I had set it that way because there were reported problems on ipv6 for mailcow on docker, potentially. However, re-enabling ipv6 doesn’t require changing “core” code, usually only the compose file or the config file, both of which are meant to be edited.

I’m no expert in these systems, and yes, the AI gave a fairly lengthy bug report. I’m hoping someone sees the post that can make a difference or point out something else I’ve done wrong.

I had my AI write down what the problem was, how it was solved, etc. I updated my personal Wiki for “how to update mailcow”, which includes my backup steps, etc. to have a big red note saying “after upgrade, test forwarding!” in case the files the AI modified get overwritten and I have to have it try to figure it all out for me again. 😃

ETNyx

Ok, as far as I know, IPv6 is no problem, so maybe try to allow it?

CaptainPalapa

ETNyx Isn’t this what the AI said it did?

Fix: Changed inet_protocols = ipv4 to inet_protocols = all in data/conf/postfix/extra.cf, keeping smtp_address_preference = ipv4 for outbound preference.

ETNyx

Well, yes, but i do not know if your AI agent have enough context. Currently in MC is disable/enable ipv6 just by setting in mailcow.conf. This settings make more work, for example it should change docker config that your AI does not mention. Possibly more,… Keep looking into docs, and check update.sh too,…

CaptainPalapa

Okay, I had a whole thing typed up here, but I’ve been grilling the AI sternly for about an horu to super explain to me. Turns out I have a file:
mailcow-dockerized-backup\mailcow-dockerized\data\conf\postfix\extra.cf

That file gets merged, I guess at update time, with the main.cf

And sure enough, those three lines are content in the extra.cf, which is .gitignore’d. I have NO idea how those lines got there, obviously other than setting my primary hostname, maybe through some setup wizard or a UI or whatever. I’ll be removing those two lines (ipv4 valued) from both files (or trying a git revert on the main.cf, I guess, or at least a compare).

You were right to encourage me back into the docs. (And by “me”, I mean “me make the AI do it”.) As a lifelong programmer (30+ years at it now), I suspected something goofy, so a post can have the community assist. I am truly grateful for your replies! Now I just have to fix it all back, restart, and test the forwarding again.

….However. The AI is still telling me that:

If you remove the port 5870 block from master.cf (the sieve-redirect service we added), forwarding will stop working.
What happens:
Dovecot’s extra.conf has submission_host = postfix:5870.
With the 5870 block in master.cf, Postfix listens on 5870 and accepts those connections (no rspamd), so forwarding works. With the 5870 block removed from master.cf, Postfix no longer listens on 5870, so Dovecot gets “Connection refused” when it tries to submit there and the redirect fails. So that block in master.cf is required for the current setup. The only “fragile” part is that a future update.sh might overwrite or merge away that block; the post-update check or post_update_hook.sh is there to re-add it if that happens.

master.cf – The port 5870 block was appended to a file that is in the repo. Mailcow doesn’t have an “extra.master.cf” or include, (I assume it means like the postfix main/extra does.) so when update.sh merges upstream, that block could be lost or conflict. That’s a limitation of the project, not something we did wrong.

So there might still be an issue here.

….However. The AI is still telling me that:

So there might still be an issue here.

[unknown] Grrr. Sorry for double edit. Flaw in this forum software, I forget. Seen it in others too.

ETNyx

I would spin up fresh install of MC, check if your problem is there. This way you will verify that MC works as expected, after this I would revert all modification done to your MC (use diff to find what is different,…). AI suggestion to modify master.cf are not right by me. Even it call it “fragile”.