kisbala
October 24, 2024, 12:05pm
1
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.
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
2
This is an bug in Exim4 where some mail servers (Google) doesn’t prosper terminate
kisbala
October 24, 2024, 12:23pm
3
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
4
It hasn’t been fixed in any Exim version yet…
Exim:master ← divinity76:tls_ignore_missing_close_notify
opened 12:16PM - 12 Oct 24 UTC
- 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!