Exim4 TLS error on sending mail

kisbala · October 24, 2024, 12:05pm

Hello, I have a problem with TLS connection when sending mail with exim4. When the server receives mails on port 25 with TLS, there is no problem, only when sending. Components of my system: Ubuntu 22.04 LTS, HestiaCP 1.8.12.
The error occurs every time you send, but never when you receive.

Error message:

tls error on connection (recv) the tls connection was non-properly terminated

Most of the time the sending is successful, but sometimes the remote server rejects the message.

Is it a configuration error, or firewall problem, or what?

Pleas help!

Thanks!

eris · October 24, 2024, 12:09pm

This is an bug in Exim4 where some mail servers (Google) doesn’t prosper terminate

kisbala · October 24, 2024, 12:23pm

Ok, thank You! My exim version 4.95, this version belongs to Ubuntu 22.04. Does it make sense update to 4.98 or something?

eris · October 24, 2024, 12:25pm

It hasn’t been fixed in any Exim version yet…

github.com/Exim/exim

Add new option tls_ignore_missing_close_notify

Exim:master ← divinity76:tls_ignore_missing_close_notify

opened 12:16PM - 12 Oct 24 UTC

divinity76

+20 -4

- Introduced tls_ignore_missing_close_notify to handle servers that do not send …the TLS close_notify on connection close. - This addresses a common issue with both Gmail and Yandex servers, which intentionally omit close_notify to save a roundtrip, despite it being against the TLS protocol. - Without this option, the omission generates spurious errors in logs, such as: "2024-10-12 09:22:27 1szVWE-0071qn-2C H=gmail-smtp-in.l.google.com [142.250.102.27] TLS error on connection (recv_tls_read): The TLS connection was non-properly terminated." - The new option allows treating this as a normal EOF, equivalent to OpenSSL's SSL_OP_IGNORE_UNEXPECTED_EOF. quoting https://github.com/php/php-src/issues/8369 >OpenSSL became more strict about unexpected EOF (not sending close notify) in 1.1.1e ***but reverted that change in 1.1.1f due to the huge amount of non-compliant servers.*** With the new major release 3.0.0 it came back. See openssl/openssl#11378 for more details. It's the same issue here, turns out that gmail and yandex is among the `huge amount of non-compliant servers`, and it's triggering GnuTLS. The issue is so common that: - OpenSSL prior to 1.1.1e always ignored it - OpenSSL >= 1.1.1f decided to ignore it again - OpenSSL >=3.0 made ignoring it optional, configurable with `SSL_OP_IGNORE_UNEXPECTED_EOF` but GnuTLS (which Debian and Ubuntu's exim4 links to) does not have a setting to ignore it (or didn't last time I checked.. wouldn't surprise me if future versions of GnuTLS adds it) # The Exim Project does not use GitHub Issues Hey, we want your input, but we want to make sure that we actually see it and that your help is not wasted, so please read this. The GitHub repo exists for convenience for some folks, and to host our Wiki. The Git repo is an automated clone of our real repo over at <https://git.exim.org/exim.git>. Sometimes a maintainer will take a look at GitHub pull requests, just because we care about the software and want to know about issues, but expect long delays. It's not a really supported workflow. Our bug-tracker takes code-patches and is the place to go: <https://bugs.exim.org/> If you've found a security bug, then please email <[email protected]>. All Exim Maintainers can and do use PGP. Keyring: <https://ftp.exim.org/pub/exim/Exim-Maintainers-Keyring.asc> We don't have a re-encrypting mailer, just encrypt to all of them please. ## If this is too much hassle ... We do periodically get around to checking GitHub Pull Requests. It just won't be fast. Patches should update the documentation, `doc/doc-docbook/spec.xfpt`; if you like, just provide the plaintext which should go in there and we can mark it up. If it's a whole new feature, then please guard it with a build option `EXPERIMENTAL_FOO`; docs are in plaintext in `doc/doc-txt/experimental-spec.txt`. If you're feeling particularly thorough, these files get updated too: * `doc/doc-txt/ChangeLog` : all changes; workflow pre-dates Git * `doc/doc-txt/NewStuff` : if it's a change in intended behavior which postmasters should read * `doc/doc-txt/OptionLists.txt` : (we usually defer this until cutting a release) * `src/README.UPDATING` : if you're breaking backwards compatibility Thanks!

newbee · February 28, 2026, 11:19am

I dont know if it helps

I am using mutt and exim4 latest versions

I get regularely the error :

“TLS error on connection (recv): The TLS connection was non-properly terminated.”

This occurs on all my ubuntu-like systems.

I am used send a mail from a scrip located in “/etc/init.d/ i.e. during boot process. BUT This error is semi-permanent.

After several trials I discovered that the same “mutt” mail command never fails when used alone any time later after boot process.

So I assume that the issue is linked with the start of SSL processes and is a timing problem!

If it helps….