[BUG] - front mail ports are not exposed via hostPort

[mreiche]

Describe the bug
The documentation says:

All mail ports of the "front" POD will be simply exposed via the "hostPort" function.

But the front pod has only the following ports opened:

mailu-front-68bcb7cb4c-5fh6g:/app# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:10204         0.0.0.0:*               LISTEN      13/nginx -g daemon 
tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN      12/dovecot
tcp        0      0 0.0.0.0:14190           0.0.0.0:*               LISTEN      12/dovecot
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN      13/nginx -g daemon 
tcp        0      0 0.0.0.0:10025           0.0.0.0:*               LISTEN      12/dovecot
tcp        0      0 0.0.0.0:10143           0.0.0.0:*               LISTEN      12/dovecot
tcp        0      0 0.0.0.0:4190            0.0.0.0:*               LISTEN      12/dovecot
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      13/nginx -g daemon 
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      13/nginx -g daemon

Only port 80 and 25 are ready.
I reviewed the /etc/dovecot/proxy.conf and provided some environment variables:

front:
  extraEnvVars:
    - name: PORT_587
      value: "1"
    - name: TLS_993
      value: "1"
    - name: PORT_143
      value: "1"
    - name: TLS_465
      value: "1"

That enables some dovecot proxy ports:

mailu-front-8f48fdd79-sdnms:/app# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      13/dovecot
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      13/dovecot

But what about the the TLS ports?
It looks like, that the whole Dovecot Proxy is not ready and the documentation misleading.

To Reproduce

Enable hostPorts

front:
  hostPort:
    enabled: true

And test for open ports on the node:

nc -vt localhost 25  # Always works (forwarded by Nginx)
nc -vt localhost 587 # fails

Also using externalService doesn't change anything on this behaviour:

front:
  hostPort:
    enabled: false
  externalService:
    enabled: true
    type: LoadBalancer
    externalTrafficPolicy: Local

Expected behavior
The ports should be opened, forwarded to postfix/dovecot or properly proxied.

Environment (please complete the following information):

• Helm Chart Version: 2.6.3
• Kubernetes Platform: k3s

Values.yaml Configuration
see above

[eiidoubleyuwes]

Facing the same issue

[fiskhest]

Disclaimer: I am a mailu helm chart user.

Whilst migrating from ingress to HTTPRoute in a (previously) working cluster setup I happened to hit upon the exact symptoms identified in this thread. mailu-front was listening on some, but not all of its ports locally. No hints in the logs about any issues.

After much spelunking, I figured out that I had to mount the new Gateway certificates into the pod at /certs/{cert,key}.pem and changing TLS_FLAVOR=notls to TLS_FLAVOR=mail. After a restart with these settings, mailu-front immediately started working and listening on the missing ports.

Here's the values.yaml changes for brevity:

ingress:
  enabled: false
  existingSecret: mail-mydomain-tld-tls
  tlsFlavorOverride: mail

@DrPsychick this might be interesting to document over at mailu-helm, maybe my search-fu failed me but I can't find anything there about it. I can create a PR if it is welcome.

[kooskaspers]

Disclaimer: I am a mailu helm chart user.

Whilst migrating from ingress to HTTPRoute in a (previously) working cluster setup I happened to hit upon the exact symptoms identified in this thread. mailu-front was listening on some, but not all of its ports locally. No hints in the logs about any issues.

After much spelunking, I figured out that I had to mount the new Gateway certificates into the pod at /certs/{cert,key}.pem and changing TLS_FLAVOR=notls to TLS_FLAVOR=mail. After a restart with these settings, mailu-front immediately started working and listening on the missing ports.

Here's the values.yaml changes for brevity:

ingress:
  enabled: false
	  existingSecret: mail-mydomain-tld-tls
	  tlsFlavorOverride: mail

@DrPsychick this might be interesting to document over at mailu-helm, maybe my search-fu failed me but I can't find anything there about it. I can create a PR if it is welcome.

Hmm, I think I ran into the same issue as @fiskhest and initially fixed it in a rather poor way.

I recently switched from Ingress to NGINX Gateway Fabric. Everything worked fine for a couple of weeks, but at some point the gateway started reporting:

nginx 2026/04/10 07:05:23 [error] 107160#107160: *276451 connect() failed (111: Connection refused) while connecting to upstream,
client: 192.168.1.1,
server: mail.kaspe.rs,
request: "GET / HTTP/2.0",
upstream: "http://10.42.0.7:80/",
host: "mail.xx.xx"

After that, I could no longer access Mailu. The problem seemed to be that Mailu no longer had access to a valid certificate.

My workaround was to copy the mailu-tls secret created by the Gateway into the mailu namespace and then point the Helm chart to it:

kubectl -n gateway get secret mailu-tls -o yaml > mailu-tls.yaml

I changed the namespace in the YAML to mailu, applied it, and set this in values.yaml:

ingress:
  existingSecret: mailu-tls

That worked, but reading your comment, it sounds like the proper fix is to mount the Gateway certificate into mailu-front at /certs/{cert,key}.pem and set TLS_FLAVOR=mail instead of notls.

That does still leave me with one challenge, though: the certificate created by NGF is not available in the mailu namespace, because it is created in the gateway namespace. So unless I manually copy or sync that secret into the mailu namespace, Mailu still cannot mount it directly.

I agree this would be useful to document in mailu-helm, especially for users migrating from Ingress to Gateway API / HTTPRoute.

@fiskhest I think the issue we are facing is different from @mreiche so maybe we should open a new issue.

[fiskhest]

@fiskhest I think the issue we are facing is different from @mreiche so maybe we should open a new issue.

My findings were exactly identical to the given symptoms in this issue 🤷🏼 I have no problems creating a new issue, though I do not know where or with what details other than replicating the findings given in this issue. There was nothing in the debugging process that gave other facts that pointed me in the right direction, which could form the report for another, non duplicating issue.

That does still leave me with one challenge, though: the certificate created by NGF is not available in the mailu namespace, because it is created in the gateway namespace. So unless I manually copy or sync that secret into the mailu namespace, Mailu still cannot mount it directly.

Ah, in my cluster/Gateway spec I roll out per-namespace certificates that are provisioned in their respective namespace. I think there are controllers you can use for syncing secrets between namespaces (https://github.com/emberstack/kubernetes-reflector among others).

[DrPsychick]

@fiskhest yes, feel free to submit a PR, if needed with a separate issue. This project needs the contributions from the community. I joined maintainers to provide feedback faster and release more often, but I'm also just a "user" of the chart :P

[fiskhest]

👍🏼 Understood, I'll draw something up as soon as life permits.