Solved Loads of exim minalog errors: error:0A000126:SSL routines::unexpected eof while reading

Richard G

Richard G

Verified User
Joined
Jul 6, 2008
Messages
14,479
Location
Maastricht
Just seen this happening when I send a mail, so I checked my exim logs and I get loads of these errors both on ipv4 and ipv6.

In my case I've seen it when a message to some company was completed via the server and then this line is added with my home ip.
Code: 
2025-09-18 22:48:56 1uzLYl-000000007va-1JyL Completed
2025-09-18 22:48:56 TLS error (SSL_read): on connection from 2001-1c05-xxx-xxx-xxx-xxx-xxx-xxx.cable.dynamic.v6.ziggo.nl (PCNAME) [2001:1c05:xxx:xxxx:xxxx:xxxx:xxxx:xxxx] error:0A000126:SSL routines::unexpected eof while reading

But I've got loads of the same (mostly customers) in the mainlog too on all servers.
TLS error (SSL_read): on connection from [162.xxx.xxx.xxx] error:0A000126:SSL routines::unexpected eof while reading

I got this exim customisations on all servers in the exim.variables.conf.custom but I doubt this is causing it:
Code: 
bounce_return_message = false
AUTH_ENABLE_CONDITION = ${if !eq{$interface_port}{25}}
AUTH_BLOCK_SENDER_SPOOFING = no

How can we fix this
 
Anybody a clue on how to fix these errors? I do also need plain pass authentication on port 587 so I need that custom line.
 
Hi Richard

Maybe a shot in the dark, but I think the client can't make a TLS connection with the server.
Could it be that the client and the server does not have any TLS protocol or cipher in common?

Kind regards
Dries
 
Hello Dries.
Thanks for answering but that is not the case, this is happening with lots of clients on all servers.

As you can see in my first message, it happened to a mail I send too, and I do have everything in perfect order. And what is wondering me most is that the error came -after- the sending of my mail was stated as "completed".

Since I have a lot of those lines on all servers, I think this has to do with the exception I'm making in the exim.variables.conf.custom file so on 1 server I remove that customisation to see if that will make any difference.
 
Hi Richard

I did a grep on my servers, and I can only see it happening on RHEL 9 servers, not on RHEL 8 servers.
It probably has something to do with the OpenSSL 3.2.2 library in RHEL 9, as OpenSSL 1.1.1k is used on RHEL 8.

I would not worry, and ignore it.

Kind regards
Dries Pattyn
 
Driesp said:
only see it happening on RHEL 9 servers, not on RHEL 8 servers.
Click to expand...
Oh great... not. :(
So I presume you have the same issue on your RHEL 9 servers then?

Yes I can ignore it, but I don't like that much errors in my logfiles. I tends to give the impression something is wrong while it's not. Which is a bad thing because as you found out this was not happening on RHEL 8 servers.

I wish we could have back the old times where not as much errors (also see my other thread) are in logs and need to be ignored.

Maybe OpenSSL can fix this hopefully then.
Thank you for checking, I don't have any RHEL 8 anymore so no way to compare.
 
zEitEr said:
By setting the log_selector global option
Click to expand...
Thank you. That would be a good solution if it were just warnings. But when something's wrong, one would like to see errors and these are real error notices.
So I don't think it would be wise to disable the error loggings. Maybe to another file but then I can also just keep it as is.
However thank you for pointing it out.
 
Richard G said:
Oh great... not. :(
So I presume you have the same issue on your RHEL 9 servers then?

Yes I can ignore it, but I don't like that much errors in my logfiles. I tends to give the impression something is wrong while it's not. Which is a bad thing because as you found out this was not happening on RHEL 8 servers.

I wish we could have back the old times where not as much errors (also see my other thread) are in logs and need to be ignored.

Maybe OpenSSL can fix this hopefully then.
Thank you for checking, I don't have any RHEL 8 anymore so no way to compare.
Click to expand...
My friend GPT-5 says the following :)

Here’s the tl;dr from that DirectAdmin thread you shared, plus what it usually means and what you can (and can’t) do about it:

What that error actually means​

error:0A000126:SSL routines::unexpected eof while reading is an OpenSSL 3.x behavior: it’s logged when the peer (your mail client or a remote MTA) closes the TLS connection without sending a proper close_notify. Older OpenSSL versions mostly hid this; OpenSSL 3 surfaces it as an SSL error, so you suddenly see lots of log noise even when the mail itself succeeded.

In the DA thread, the error line appears right after a “Completed” delivery line, and it references the user’s home IP on ports 465/587—so the message is sent, then the client tears down the TLS session a bit abruptly, and Exim logs the EOF warning. That matches the classic “benign but noisy” case.

Is it harmful?​

Usually no. It’s most often caused by MUAs, mobile clients, or middleboxes that just drop the TCP/TLS session instead of doing a clean TLS shutdown. Since OpenSSL 3 changed the reporting, you notice it now even though the behavior likely existed before.
Click to expand...

Mitigations (realistic expectations)​

  • Best: Leave it. Treat these as informational unless they correlate with failed deliveries. (They usually won’t.)
  • Reduce log noise (limited): Exim’s log_selector can toggle extra TLS details (cipher, peer DN, etc.), but it doesn’t suppress genuine TLS error lines—so you can’t neatly “turn off just these” without losing important errors too. See Exim’s logging spec for what is tunable. exim.org
  • Client-side cleanup (where possible): Some MUAs/proxies can be updated or configured to properly send close_notify. You can’t force third-party remotes, but you might reduce occurrences from your submission clients by updating them. The underlying cause is the peer closing the connection abruptly.
  • Stay current: Keep OpenSSL and Exim up-to-date. This won’t remove the message (it’s intentional in OpenSSL 3), but you get bug fixes and clearer diagnostics.
Click to expand...
 
OK, you're the boss on your server. I don't know how to help you, when you want two contradicting things at the same time)

Richard G said:
Yes I can ignore it, but I don't like that much errors in my logfiles.
Click to expand...

Richard G said:
That would be a good solution if it were just warnings. But when something's wrong, one would like to see errors and these are real error notices.
Click to expand...
 
eva2000 said:
My friend GPT-5 says the following :)
Click to expand...
Sorry Eva, but I don't have any trust in GPT or AI answers as often they have errors in their answers and are not always 100% accurate. At least I've seen that a couple of times.
Which is the reason I rather ask it here. However it contains some interesting sentence which I will quote next.

zEitEr said:
I don't know how to help you, when you want two contradicting things at the same time)
Click to expand...
It's not contradicting, it's either or. You want to help me, but the only way to help is to surpress all errors, and that is not a good thing.
From Eva's chatgpt:
so you can’t neatly “turn off just these” without losing important errors too.
Click to expand...
And that's my sorrow, if I turn it off, I would loose important errors too and then get a hard time when trying to find the cause of a problem if one will occur.

The option for a seperate file is not of use to me (so not contradicting) as it would contain all errors then and still I'm not rid of the "fake" errors, just all errors (including real errors) are logged in to a seperate file.

So if I can not get rid of the "fake" errors fully, then a seperate file is usesless to me and I can just as well take my loss and ignore.

As for the contradictions in my sentences, there are none, as in the first line you quote I speak of "errors", I don't want a lot of errors in my log, and in the second line I stated that the solution would be good if it were "warnings", which is something different.

So I don't want to see fake errors, but I -do- want to see real errors which are not safe to ignore. Nothing contradictory to that imho.

Since it's not possible to only have these "fake" (or ignorable" errors to be removed, I set the topic to solved as then I rather choose to have all errors (including the important ones) than none at all. ;)
Maybe this clarify's things to you?
 
For me it is rather simple:

1. if you see anything wrong that breaks things and it can be fixed - fix it
2. if you see anything wrong and it does not break things - ignore it)

Do not want to see? - Either fix or hide)

Logs will always have both useful and useless lines. Use tools such as grep/exigrep for filtering logs and/or monitor logs for certain keywords and errors.

p.s. just my 2 cents here, ain't gonna persuade anybody at all)
 
zEitEr said:
Do not want to see? - Either fix or hide)
Click to expand...
In this case, can't be fixed so only solution is ignore (which is why I put topic to solved).

Indeed logs will always have some useless lines, but these are a massive amount useless lines, otherwise I wouldn't have bothers. But a lot is irritating to me.
It's just like how I use logs. I sometimes just like to scroll through them with the less command to look at some things quickly.
Or use nano with ctlr-w.
Now I tried grep with an email address which I wanted to look at and got massive of these useless lines too. Just trying to improve things if possible. In this case seems it's not.
 
Richard G said:
Sorry Eva, but I don't have any trust in GPT or AI answers as often they have errors in their answers and are not always 100% accurate. At least I've seen that a couple of times.
Which is the reason I rather ask it here. However it contains some interesting sentence which I will quote next.
Click to expand...
related I think https://github.com/openssl/openssl/discussions/22690

This usually happens when the remote peer abruptly shuts down the connection without sending a "close_notify" alert which is what you are supposed to do.

1.1.1 and earlier treated this incorrectly. In such a case SSL_read() would fail and SSL_get_error() would return SSL_ERROR_SYS - but with nothing in errno. This was actually incorrect behaviour - it should be treated as SSL_ERROR_SSL with an appropriate error in the error stack. But making that change in 1.1.1 branch was too disruptive so it was introduced in 3.x instead.

So, this behaviour on behalf of the peer has probably always been there, but you are just noticing it now because how OpenSSL reacts to it has changed.

One option for dealing with this is to set the SSL_OP_IGNORE_UNEXPECTED_EOF option. See:

https://www.openssl.org/docs/man3.1/man3/SSL_set_options.html

This causes OpenSSL to treat an unexpected eof as if the peer had closed down gracefully - but make sure you read the docs above around truncation attacks.

If you have control over the remote peer, then another option is to change the remote peer so that it closes down connections gracefully.
Click to expand...
 
Thanks. Goes a bit too far for my knowledge and I'm already reading the line like "be aware of truncation attacks". If possible I rather leave things alone.
However, so 1.1.1 and earlier did not handle it correctly and now the new version does so we got a load of errors.
But then these errors must be caused by the mail clients of the users, because there are so much of them. So if I understand correctly all those mail clients do not send a close_notify often then. And already for so long then.
 
You must log in or register to reply here.
Back
Top