Add new option tls_ignore_missing_close_notify

[divinity76]

• 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 php/php-src#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!