Auto Reply OOO Debugging

[jamesarbrown]

Have mailu 2.0.30 running under Kubernetes. Everything is fine apart from auto reply. Emails goto user, just no auto reply comes back.

Found this in the dovecot logs.
Error: smtp-client: conn mailu-front.mailu200124.svc.cluster.local:25 (10.43.96.92:25) [1]: Connection timed out after 30 seconds

followed by

lmtp(xyz@example.com)<2734><vb5UMdk6xWWuCgAAmEiwvg>: Error: sieve: msgid=<36qkiualjv43dfdrsm2edugg.1707424471129@gmail.com>: vacation action: failed to send vacation response to SRS0=lNgX=JR=gmail.com=user@example.uk: <smtp(mailu-front.mailu200124.svc.cluster.local): RCPT TO failed: Connect timed out> (temporary error)

Could anyone advise how we can debug this further

[jamesarbrown]

To check the IP and Pod were actually there on SMTP I fired up a networktools pod and ran

networktools:/# telnet mailu-front.mailu200124.svc.cluster.local 25
Trying 10.43.96.92...
Connected to mailu-front.mailu200124.svc.cluster.local.
Escape character is '^]'.

So it appear the pod is there and port open. No idea why "smtp-client" can not reach it.

[jamesarbrown]

Still trying to figure this one. There is a problem with the SSL which maybe the root of it.

This is dovecot logs

Feb 19 20:52:10 lmtp(1415): Error: SSL context initialization failed, disabling SSL: Can't load SSL certificate (ssl_cert setting): The certificate is empty 
Feb 19 20:52:10 lmtp(1415): Info: Connect from 10.42.1.56 
Feb 19 20:52:40 lmtp(reply@example.com)<1415><8f8hD3q/02WHBQAAmEiwvg>: Error: smtp-client: conn mailu-front.mailu200124.svc.cluster.local:25 (10.43.96.92:25) [1]: Connection timed out after 30 seconds 
Feb 19 20:52:40 lmtp(reply@example.com)<1415><8f8hD3q/02WHBQAAmEiwvg>: Error: sieve: msgid=<5neijiclva2tcj3l2rivdm07.1708375927008@example.com>: vacation action: failed to send vacation response to james@example.com: <smtp(mailu-front.mailu200124.svc.cluster.local): RCPT TO failed: Connect timed out> (temporary error) 
Feb 19 20:52:40 lmtp(reply@example.com)<1415><8f8hD3q/02WHBQAAmEiwvg>: Info: sieve: msgid=<5neijiclva2tcj3l2rivdm07.1708375927008@example.com>: stored mail into mailbox 'INBOX' 
Feb 19 20:52:40 lmtp(1415): Info: Disconnect from 10.42.1.56: Logged out (state=READY)

So i ran from another pod to check the cert

openssl s_client -connect mailu-front.mailu200124.svc.cluster.local:993
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 343 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

As the logs say, an empty certificate.

But, if as imap.example.org, via a traefik TCP loadbalancer (but NO TLS endpoint on traefik), i get a proper cert.

openssl s_client -connect imap.example.org:993 |more
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = example.org
verify return:1
CONNECTED(00000003)

...

In helm the ingress is set to true and the certificate set (certificate is by cert-manager for the entire cluster and reflected into this namespace)

  tls: true
  existingSecret: "example-org-tls"

In the front pod the certificates are present in /certs (have checked the keys also are the right ones).

mailu-front-5656fc7dc9-5n58p:/etc/nginx# ls /certs
cert.pem  key.pem

These are refered to by /etc/nginx/tls.conf

So at a bit of a loss now, the certificate is present, but being served up as empty when you hit the pod directly via its URI and not the mail server URI. TBH the vacation would be better hitting the proper server URI.

Will file as a bug as I think it possibly is.

[nextgens]

The OOO responder is a dovecot/sieve functionality that runs on the "imap" container.

In /etc/dovecot/dovecot.conf, it looks for submission_host and will connect to that. On master and 2.0 that should be front, see https://github.com/Mailu/Mailu/blob/master/core/dovecot/conf/dovecot.conf#L8

Connection timed out does mean that it was not reachable. I'd look into the network policies if I were you.

[jkolczasty]

Hello

I have similar problem. When proxy_protocol is used, front smtp/25 is expecting PROXY initialization. I works for load balancer, but when imap submission is trying to connect it fails with connect timeout, cause nginx is not sending banner, but is waiting for client initialization with proxy header.

Looks like using imap submission should use different port without proxy like webmail is using 10025.

[nextgens]

This is not an issue in master anymore; we are not planning to backport a fix since using PROXY on 2.0 is very difficult and will change significantly on master. Both with what's currently in and in case #3221 is merged

see
#3159 (comment)

[jamesarbrown]

@nextgens We are waiting for Helm chart update on release to test. Have not looked recently but about 8 weeks ago was not changed from release we were running

[jkolczasty]

I'm using 2.0.41 and problem with submission from dovecot affects it as it uses 25 port with proxy_protocol enabled and times-out waiting for smtp banner and frontend nginx mail smtp port is waiting for proxy header - both endpoints are waiting for something and it timeouts.

[nextgens]

I have linked to the solution we use in master. In the meantime, define an override as follows:

submission_host = $fqdn_of_proxy