Axigen Webmail dies after 3h on v10.6.24

monachus · December 29, 2025, 5:39am

I upgraded to 10.6.24 yesterday, and webmail won’t stay running. It runs for ~3h and then stops serving TLS traffic. When I connect to the load balancer in front of the mailserver, it hangs up immediately because the backend is down. When I connect directly to the backend, it hangs forever. If I connect to the webadmin port (9443), it returns a TLS cert fine.

➤ openssl s_client -connect edge-proxy.monach.us:443 -servername mail.monach.us
Connecting to 104.237.153.229
CONNECTED(00000005)
C060EB0B02000000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:696:
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 1554 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
# after port-forwarding localhost:8443 to the container port 443
➤ openssl s_client -connect localhost:8443 -servername mail.monach.us
Connecting to ::1
CONNECTED(00000005)
GET /
# hangs forever
^C⏎

There’s nothing in the container logs and nothing in everything.txt. The mailserver still receives and delivers mail over SMTP and IMAP for all domains. The webadmin works. Only webmail fails.

If I restart the container/pod, it all works again for another ~3h.

monachus · January 1, 2026, 6:00pm

More information - when it fails, it starts logging an error like this:

2025-12-31 22:44:24 +0000 04 axigen-0 WEBMAIL:00000000: TCPListener[0.0.0.0:443]: connection from [10.76.0.199
:35490] rejected due to listener-level broken limits

It looks like there’s some queue that fills up (connection queue?) and then starts blocking until I restart the mailserver.

This also looks like a bug or some new behavior for 10.6.x (now running 10.6.25), so I tried to reach out directly to Axigen only to get the “YOU DIDN’T GIVE US YOUR LICENSE KEY FOR SUPPORT” auto-reply.

Does anyone know how to get a bug report to them?

florin.burada · January 5, 2026, 8:08am

Hello @monachus!

The new connections are rejected due to the Flow Control configuration for Webmail listener on port 443 (HTTPS).

Tune these values based on your use case.

Be aware that service-level flow control is also active.

More information are available in the documentation at: Managing Service Listeners | Axigen Documentation

monachus · January 5, 2026, 8:55pm

This instance is running in Kubernetes, so all traffic to Webmail is coming from the reverse proxy, Traefik, which has the IP 10.76.0.199. This is an internal IP, and it’s probably failing because of health checks coming from an external monitoring system through that reverse proxy.

➤ k get endpoints -n traefik-system
Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
NAME            ENDPOINTS                           AGE
traefik-proxy   10.76.0.199:8000,10.76.0.199:8443   470d

root@axigen-0:/axigen/var/log# tail -n 500 everything.txt | grep WEBMAIL
2026-01-05 20:43:29 +0000 04 axigen-0 WEBMAIL:00000000: TCPController: (simultaneous peer) limits broken for address [10.76.0.199] (limits:{n=100/100,ndt=23/600,dt=35/60})

All traffic to webmail will come from this address, so the flow control is only an impediment.
This was never a problem in 10.25.x. Did something change in 10.26?
If nothing officially changed, then why are HTTP connections not being closed? The monitoring server connects 1x/minute. While there’s no netstat in the container, I can see in /proc that there aren’t 100 connections held open to webmail:

0.0.0.0:993 -> 0.0.0.0:0 state=0A
0.0.0.0:9443 -> 0.0.0.0:0 state=0A
0.0.0.0:9000 -> 0.0.0.0:0 state=0A
0.0.0.0:80 -> 0.0.0.0:0 state=0A
0.0.0.0:465 -> 0.0.0.0:0 state=0A
0.0.0.0:21 -> 0.0.0.0:0 state=0A
127.0.0.1:7000 -> 0.0.0.0:0 state=0A
127.0.0.1:8888 -> 0.0.0.0:0 state=0A
0.0.0.0:25 -> 0.0.0.0:0 state=0A
0.0.0.0:443 -> 0.0.0.0:0 state=0A
10.76.0.7:993 -> 71.222.13.117:53133 state=01
10.76.0.7:993 -> 71.222.13.117:54125 state=01
10.76.0.7:993 -> 34.139.166.5:17695 state=01
10.76.0.7:993 -> 71.222.13.117:62281 state=01
10.76.0.7:993 -> 71.222.13.117:53012 state=01
10.76.0.7:993 -> 71.222.13.117:58591 state=01
10.76.0.7:993 -> 71.222.13.117:57450 state=01
10.76.0.7:993 -> 71.222.13.117:53134 state=01
10.76.0.7:993 -> 104.196.22.183:47713 state=01
10.76.0.7:993 -> 71.222.13.117:54909 state=01

So this implies that those 100 connections from that one IP are never being flushed, and it’s not “100 simultaneous connections” but rather “100 connections ever.” This smells like a bug.

florin.burada · January 6, 2026, 8:52am

Hello @monachus

In your current setup, I think is better to disable the flow control in Axigen and enforce the corresponding limitations at the proxy layer.

Regarding netstat, it can be installed inside the container for troubleshooting purposes; however, this change will not persist after the container is recreated. You can install it using:

apt update && apt install -y net-tools

Regards,
Florin

monachus · January 6, 2026, 3:56pm

How do I disable it? Set the values to zero?

This also doesn’t answer the question of why I had no problems in 10.5 and now have problems in 10.6, though only with Webmail. Those 100 supposed connections that have filled the pipe don’t show up anywhere else, so I don’t think they’re real. They’re an HTTP request to / that doesn’t stay open, so why does the flow control think they’re still active?

monachus · January 9, 2026, 3:51pm

bumping this - how do i disable flow control when there are only options to control the number of messages?

why does it think there are 100 connections active when there are actually zero?

monachus · January 20, 2026, 5:12am

Bumping this again after 11 days with no response. If you’re going to make a suggestion, @florin.burada please follow it up with how to do the suggested thing.

It makes me very uncomfortable that you’re silent on why this is only a recent problem, and completely ignoring the question about why Axigen thinks there are 100 connections to the webmail process when there are actually zero.

florin.burada · January 20, 2026, 7:14am

Helo @monachus,

You may disable the flow control at service level by changing the value to 0 or at listener level by unchecking “Enable Flow Control for this Listener” option.

Regarding the number of connections, I haven’t seen any issues on my installs, and I haven’t heard of other users reporting this either, so it seems like it might be specific to your platform. To get a better idea of what’s going on, let’s start by checking the number of connections at a fixed interval (for example, every 60 seconds) and logging the results to a file using netstat.

netstat -an | grep ESTABLISHED | grep ":443 " | wc -l

It would also help if you could share the full Axigen log file (everything.txt) covering a longer period, like 12–24 hours.

Regards,
Florin

monachus · January 21, 2026, 5:28pm

Thanks for replying. As stated above, there are zero (0) connections, yet Axigen continues to think that there are 100 connections and blocks webmail. I’m running inside of Kubernetes. Traefik (proxy server) receives traffic on port 443 for mail.monach.us and mailadmin.monach.us and then forwards it to the axigen-0 pod on port 80 (which appears to get redirected to 443, which is hyper inefficient, but whatever).

In its failed state (now), any request to Axigen on port 80 redirects to 443 and then gets rejected by Axigen without sending a TLS cert. It just hangs up:

# This is from the proxy server pod
/ $ wget -S 10.76.0.7
Connecting to 10.76.0.7 (10.76.0.7:80)
  HTTP/1.1 301 Moved Permanently
  Server: Axigen-Webmail
  Location: https://10.76.0.7:443
Connecting to 10.76.0.7:443 (10.76.0.7:443)
ssl_client: 10.76.0.7: handshake failed: No error information
wget: error getting response: Connection reset by peer

I went ahead and installed netstat into the Axigen container:

root@axigen-0:/# netstat -an | grep EST | grep ":443" | wc -l
0
root@axigen-0:/# netstat -an | grep EST | grep ":80" | wc -l
0

This appears as the following behavior from outside of the cluster:

➤ openssl s_client -connect mail.monach.us:443 -servername mail.monach.us
Connecting to 104.237.153.229
CONNECTED(00000005)
40AC0EEE01000000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:701:
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 1552 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
40AC0EEE01000000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl/ssl_lib.c:2834:

Meanwhile, Axigen logs this:

root@axigen-0:/axigen/var/log# grep WEBMAIL everything.txt | tail -n 10
2026-01-21 17:03:34 +0000 04 axigen-0 WEBMAIL:00000000: TCPController: (simultaneous peer) limits broken for address [10.76.0.206] (limits:{n=100/100,ndt=43/600,dt=47/60})
2026-01-21 17:03:34 +0000 04 axigen-0 WEBMAIL:00000000: TCPListener[0.0.0.0:443]: connection from [10.76.0.206:55422] rejected due to listener-level broken limits
2026-01-21 17:04:27 +0000 04 axigen-0 WEBMAIL:00000000: TCPController: (simultaneous peer) limits broken for address [10.76.0.206] (limits:{n=100/100,ndt=43/600,dt=47/60})
2026-01-21 17:04:27 +0000 04 axigen-0 WEBMAIL:00000000: TCPListener[0.0.0.0:443]: connection from [10.76.0.206:38380] rejected due to listener-level broken limits
2026-01-21 17:04:34 +0000 04 axigen-0 WEBMAIL:00000000: TCPController: (simultaneous peer) limits broken for address [10.76.0.206] (limits:{n=100/100,ndt=43/600,dt=47/60})
2026-01-21 17:04:34 +0000 04 axigen-0 WEBMAIL:00000000: TCPListener[0.0.0.0:443]: connection from [10.76.0.206:41498] rejected due to listener-level broken limits
2026-01-21 17:04:58 +0000 04 axigen-0 WEBMAIL:00000000: TCPController: (simultaneous peer) limits broken for address [10.76.0.206] (limits:{n=100/100,ndt=43/600,dt=47/60})
2026-01-21 17:04:58 +0000 04 axigen-0 WEBMAIL:00000000: TCPListener[0.0.0.0:443]: connection from [10.76.0.206:46846] rejected due to listener-level broken limits
2026-01-21 17:05:34 +0000 04 axigen-0 WEBMAIL:00000000: TCPController: (simultaneous peer) limits broken for address [10.76.0.206] (limits:{n=100/100,ndt=43/600,dt=47/60})
2026-01-21 17:05:34 +0000 04 axigen-0 WEBMAIL:00000000: TCPListener[0.0.0.0:443]: connection from [10.76.0.206:57682] rejected due to listener-level broken limits

So we have zero connections to port 80/443, but axigen thinks there are 100 active connections and rejects everything from the proxy server (10.76.0.206). I can restart Axigen, and it takes ~3h for this queue to fill up and block again.

This was not a problem until I upgraded to 10.6 from 10.5. I’ve been running Axigen for years in this exact same configuration:

➤ k get sts
NAME     READY   AGE
axigen   1/1     3y364d

After restarting Axigen, the behavior looks like this:

From the proxy-server:

(Note that the IP changed because I restarted axigen. First pass fails because of CN mismatch in cert. This is not the issue, as without this in earlier test, it just dropped the connection instead of showing the error.)

/ $ wget -S 10.76.0.252
Connecting to 10.76.0.252 (10.76.0.252:80)
  HTTP/1.1 301 Moved Permanently
  Server: Axigen-Webmail
  Location: https://10.76.0.252:443
Connecting to 10.76.0.252:443 (10.76.0.252:443)
ssl_client: 10.76.0.252: name `10.76.0.252' not present in server certificate
wget: error getting response: Connection reset by peer

# providing host header resolves CN mismatch
/ $ wget -S --header "Host: mail.monach.us" 10.76.0.252
Connecting to 10.76.0.252 (10.76.0.252:80)
  HTTP/1.1 301 Moved Permanently
  Server: Axigen-Webmail
  Location: https://mail.monach.us:443
Connecting to mail.monach.us:443 (104.237.153.229:443)
  HTTP/1.1 200 OK
  Server: Axigen-Webmail
  Date: Wed, 21 Jan 2026 17:18:59 GMT
  Referrer-Policy: no-referrer
  Cache-Control: no-cache, no-store, must-revalidate, proxy-revalidate
  Pragma: no-cache
  Last-Modified: Wed, 21 Jan 2026 17:18:59 GMT
  Expires: Wed, 14 Jan 2026 17:18:59 GMT
  Content-Type: text/html; charset=utf-8
  X-Frame-Options: sameorigin
  X-XSS-Protection: 1; mode=block
  X-Content-Type-Options: nosniff
  Strict-Transport-Security: max-age=31536000
  Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' 'nonce-AXI-SCRIPT-1199624' 'strict-dynamic'; style-src 'self' 'unsafe-inline'
  Connection: Close

From the axigen log:

2026-01-21 17:18:59 +0000 08 axigen-0 WEBMAIL:00000021: [10.76.0.252:443] connection accepted from [10.76.0.206:42262]
2026-01-21 17:18:59 +0000 08 axigen-0 WEBMAIL:00000021: <> GET / HTTP/1.1 u= code=200 time=0
2026-01-21 17:18:59 +0000 08 axigen-0 WEBMAIL:00000021: connection closed with [10.76.0.206:42262]
2026-01-21 17:19:36 +0000 08 axigen-0 WEBMAIL:00000029: [10.76.0.252:443] connection accepted from [10.76.0.206:55950]
2026-01-21 17:19:36 +0000 08 axigen-0 WEBMAIL:00000029: <> GET / HTTP/1.1 u= code=200 time=0
2026-01-21 17:19:36 +0000 08 axigen-0 WEBMAIL:00000029: connection closed with [10.76.0.206:55950]

From axigen itself:

root@axigen-0:/# netstat -an | grep EST | grep -E ":(80|443)" | wc -l
1

From the outside:

➤ openssl s_client -connect mail.monach.us:443 -servername mail.monach.us
Connecting to 104.237.153.229
CONNECTED(00000005)
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=R13
verify return:1
depth=0 CN=mail.monach.us
verify return:1
---
Certificate chain
 0 s:CN=mail.monach.us
   i:C=US, O=Let's Encrypt, CN=R13
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Dec  1 22:50:00 2025 GMT; NotAfter: Mar  1 22:49:59 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=R13
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---

In three hours there will be zero (0) real connections to axigen, axigen will report 100 connections in its log, and webmail will be down again.

monachus · February 2, 2026, 3:28pm

Circling back on this. Despite making no changes on the server side, Webmail’s connection queue no longer fills up with ghost connections. It just stopped after my last reply, when I restarted Axigen (which I had done many times before). The only thing I did differently after the last restart was to install net-tools to get access to netstat. I’ve just restarted the container to remove those changes, and I’m curious now to see if Webmail dies again after 3h.

monachus · February 3, 2026, 12:07am

Well…it’s not dying again, so I’ll take that as a win. I never turned off the flow control. I’m still on 10.6.25. Nothing changed. It just stopped dying. Voodoo.