Recent releases of various TLS libraries are enabling support for "post-quantum" key agreement. For example, in OpenSSL 3.5 the default client behaviour is to send TLS 1.3 "keyshares" for both the hybrid "post-quantum" X25519MLKEM768 and for the "classical" X25519. The size of the resulting TLS Client Hello message is close to 1500 bytes and it often splits across multiple TCP segments. This may run into friction with "middlebox" TLS inspection, or with server TLS stack implementations, resulting in failure (often timeouts) to complete the TLS handshake, which hangs or aborts are the TLS Client Hello. It is expected that use of these algorithms by TLS clients will continue to grow and it is best to take action now and not wait for problems to become urgent. If you have access to a computer with OpenSSL 3.5 (or later) you can check your server with: $ host=your.server-fqdn.example $ (sleep 2; printf 'QUIT\r\n') | openssl s_client -starttls smtp -connect $host:25 \ -groups "*X25519MLKEM768:*X25519:P-256:ffdhe3072" -state -brief If this hangs after printing "SSL_connect:SSLv3/TLS write client hello", you likely have a problem, to confirm, you can try again with: $ host=your.server-fqdn.example $ (sleep 2; printf 'QUIT\r\n') | openssl s_client -starttls smtp -connect $host:25 \ -groups "X25519MLKEM768:*X25519:P-256:ffdhe3072" -state -brief and if that succeeds promptly, it is appropriate to take action to find out what's causing the problem, and take steps to remediate it. -- Viktor. 🇺🇦 Слава Україні!