Exim
Add new option tls_ignore_missing_close_notify
- 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 Gitdoc/doc-txt/NewStuff: if it's a change in intended behavior which postmasters should readdoc/doc-txt/OptionLists.txt: (we usually defer this until cutting a release)src/README.UPDATING: if you're breaking backwards compatibility
Thanks!
Is this still an issue? I run into this problem but only because I had the other typical upgrade error of exim4 not wanting to talk to the local dovecot-lda anymore using the default setup. This gave the same error message, but only for the outgoing mails. Since I fixed this, I have no errors anymore.
Yes, still seems un-fixed in current git master (currently 3d137234194aa562de97d742255bb160a1798fe1 )
My logs are getting filled up with this, too, but doesn't look like anyone cares to pick it up from here.
Maybe it helps to submit the patch through bugs.exim.org?
Not just logs. My spam filter (inline with SMTP) blocks IPs that have too many TLS errors, so this can break mail.
Anyone ever open a bug for this issue on bugzilla? I couldn't find one to link here. may also be why the issue has stagnated.
Our bug-tracker takes code-patches and is the place to go: https://bugs.exim.org/
Anyone ever open a bug for this issue on bugzilla? I couldn't find one to link here. may also be why the issue has stagnated.
Our bug-tracker takes code-patches and is the place to go: https://bugs.exim.org/
This was https://bugs.exim.org/show_bug.cgi?id=3121 and is already fixed in GIT HEAD.
