Exim 4.92

AndriesLouw

Verified User
Joined
Jan 4, 2008
Messages
28
Location
Sneek, Netherlands
i have the same on some older servers

--make[1]: Entering directory `/usr/local/directadmin/custombuild/exim-4.92/build-Linux-i386'
>>> version 4.92 #4

>>> version 4.92 #5

gcc -DMACRO_PREDEF macro_predef.c
In file included from exim.h:482,
from macro_predef.c:11:
structs.h:757: error: 'NS_MAXMSG' undeclared here (not in a function)
make[1]: *** [macro_predef.o] Error 1
make[1]: Leaving directory `/usr/local/directadmin/custombuild/exim-4.92/build-Linux-i386'
make: *** [all] Error 2

*** The make has failed, would you like to try to make again? (y,n):
---

did anyone resolved this?
Please press Ctrl+Z when getting this message.

Then do:
vim /usr/local/directadmin/custombuild/exim-4.92/build-Linux-x86_64/structs.h

Type:
:set number

Go to line 747, before the typedef struct, press i, and add:
#ifndef NS_MAXMSG
# define NS_MAXMSG 65535
#endif

Press escape, type:
:wq!

Followed by enter, type the following commands:
fg
y

Build should proceed, if there are any additional errors, please download latest openssl-1.0.2s and compile it. This can be done with:

cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.2s.tar.gz
tar -xvzf openssl-1.0.2s.tar.gz
cd openssl-1.0.2s
./config --prefix=/usr no-threads shared
make
make test
make install

Please do the builds of apache, php, exim and dovecot again after updating openssl.
 

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
I spoke too soon..... Clients say their email is being bounced.....

TLS error on connection from mail-ed1-f66.google.com [209.85.208.66] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
What is going on?!


What has changed in 4.92?

OS is Debian 8....
 
Last edited:

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
I've been running Exim version 4.92 #5 built 14-Feb-2019 05:23:06 until now without any issue on Debian 7.11 (yes, it is EOL) with OpenSSL 1.0.1t .

Re-compiled fine: Exim version 4.92 #5 built 15-Jun-2019 11:51:26


Emails are coming fine on my end:

Code:
2019-06-15 11:55:01 1hc5On-0006GW-2E <= hidden.here@gmail.com H=mail-lj1-f171.google.com [209.85.208.171] P=esmtps X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=3532 DKIM=gmail.com id=em0bcdf3b3-3a04-4902-b6a0-99512258b6da@gmail.com T="Test" from <hidden.here@gmail.com> for poralix@example.net
Whatever reason might be in your case, it should be investigated. Probably your exim config is too strict in terms of allowed TLS protocols and ciphers.
 

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
Whatever reason might be in your case, it should be investigated. Probably your exim config is too strict in terms of allowed TLS protocols and ciphers.
I also have a Debian 7 box, and exim 4.92 is fine.

All my exim configs are the default.

Debian 7: OpenSSL 1.0.1t 3 May 2016
Debian 8: OpenSSL 1.0.1t 3 May 2016

:confused:
 

ju5t

Verified User
Joined
Sep 14, 2005
Messages
384
We're still having major issues with clients using TLS. Exim still returns an error.

Code:
error:1412E0E2:SSL routines:ssl_parse_clienthello_tlsext:clienthello tlsext
Fun. Now we have to decide whether we would like servers to get hacked or if we want to send email.
 

ju5t

Verified User
Joined
Sep 14, 2005
Messages
384
The issue seems to be related to SNI. Not sure why or how but I have been digging into this a little deeper this afternoon.

In 4.92 the following has been implemented:

JH/35 OpenSSL: fail the handshake when SNI processing hits a problem, server side. Previously we would continue as if no SNI had been received."
In /etc/exim.variables.conf there is this snippet:

Code:
tls_certificate=${if exists{/etc/virtual/snidomains}{${lookup{$tls_in_sni}nwildlsearch{/etc/virtual/snidomains}{${if exists{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.cert.combined}{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.cert.combined}{/etc/exim.cert}}}{/etc/exim.cert}}}{/etc/exim.cert}}
tls_privatekey=${if exists{/etc/virtual/snidomains}{${lookup{$tls_in_sni}nwildlsearch{/etc/virtual/snidomains}{${if exists{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.key}{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.key}{/etc/exim.key}}}{/etc/exim.key}}}{/etc/exim.key}}
We're connecting to smtp.domain.com. This domain exists in /etc/virtual/snidomains. The username exists. And there is a certificate for domain.com in /user/local/directadmin/data/users/[username]/domains too. In this particular case it's a wildcard certificate for *.domain.com.

As soon as I empty /etc/virtual/snidomains things start to work. I have no idea what's going wrong here.
 

ju5t

Verified User
Joined
Sep 14, 2005
Messages
384
After a LOT of debugging we have found the issue. It turned out to be a problem on our end that never showed until now. The combined certificate and key didn't match due to an incomplete entry in the systems that manage our servers.

We're not seeing any errors on our servers anymore. Please do not let my previous posts hold you back in updating your servers. It's vital that you do.
 

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
Doubt this is my issue....... I'm confused it is just Debian 8....... I have 7, 8 and 9, all have the same config and compile files........

I had a Google, and didn't really help.
 

soulshepard

Verified User
Joined
Feb 7, 2008
Messages
133
Please press Ctrl+Z when getting this message.

Then do:
vim /usr/local/directadmin/custombuild/exim-4.92/build-Linux-x86_64/structs.h
...
Thanks AndriesLouw, much appreciated reply.
I was in a dead lock with some old ancient servers. i did mitigate it by putting a spam proxy solution in front of it, with only allowing the ip's of the spam proxy to send email to it.
but your solution gives also others in the same situation a solution. Thanks again. this gives some time to fase these old servers out.

Soul.
 

doublespaces

Verified User
Joined
Mar 16, 2016
Messages
10
Code:
cd /usr/local/directadmin/custombuild
./build update
./build set exim yes
./build exim
Thank you for this. Both my 4.91 servers are now updated to 4.92. Kind of wish there was a more formal way of addressing these things from the direct admin site rather than looking for it through the forums. If there is forgive me and if you'd kindly point me to it?
 

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
Am I the only one with the problem stated in post #22

Anyone else have Debian 8.11?

I'm running out of ideas to get this sorted.

Edit:

I only see this error only with certain hosts, Google being one, eg.
2019-06-13 06:04:58 TLS error on connection from mail-ed1-f49.google.com [209.85.208.49] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
2019-06-13 06:05:57 TLS error on connection from [77.40.27.144] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
2019-06-13 06:05:58 TLS error on connection from (localhost.localdomain) [77.40.27.144] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
2019-06-13 06:06:21 TLS error on connection from webgridf011.emsecure.net [91.230.176.11] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
 
Last edited:

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
I've checked Debian 8.11 on our end. No issue found.

- A server has been running Exim version 4.92 since 26-Feb-2019

Code:
root@server:/usr/local/directadmin/custombuild# exim --version
Exim version 4.92 #5 built 26-Feb-2019 01:27:39
...

with OpenSSL 1.0.1t 3 May 2016



- For testing purposes I've re-compiled Exim:

Code:
Exim installation complete
Moving exim binary.
Enabling exim in systemd...
Exim 4.92 Installed.
Restarting exim.
- Exim version is the same, and built date updated:


Code:
root@server:/usr/local/directadmin/custombuild# exim --version
Exim version 4.92 #5 built 18-Jun-2019 13:02:48
...
I've sent a testing email from my @gmail.com account:

Code:
2019-06-18 13:04:18 1hdHWr-0001AD-Sh <= ***hidden***@gmail.com H=mail-lf1-f41.google.com [209.85.167.41] P=esmtps X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=4014 DKIM=gmail.com id=eme727f101-c5cf-4be4-b33e-10c93952c590@echobook T="Test" from <***hidden***@gmail.com> for poralix@server.example.net
2019-06-18 13:04:18 1hdHWr-0001AD-Sh => poralix <poralix@server.example.net> F=<***hidden***@gmail.com> R=localuser T=local_delivery S=4142
2019-06-18 13:04:18 1hdHWr-0001AD-Sh Completed
The email delivered fine.

You might open a ticket with DirectAdmin support if you want them to check your server.
 

ClayRabbit

Verified User
Joined
Jan 3, 2004
Messages
260
Location
Russia
We have found the same issue today with one of our customer domains - (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
And this was a file permission issue - exim was unable to read key and certificate from /usr/local/directadmin/data/users/.../domains/ because file owner is diradmin:diradmin
Issue resolved after we changed permissions for .key and .cert.combined files to 640 diradmin:mail

So what's the reason for that issue and how this SNI-support supposed to work?
Because now for every SSL-enabled domain on the server we are getting:
Code:
# openssl s_client -quiet -connect localhost:465 -servername userdomain.com
34380880456:error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name:/usr/src/crypto/openssl/ssl/s23_clnt.c:802:
until we fix permissions as stated above.
 
Last edited:

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
In response to ClayRabbit.

I can see a domain.cert.combined.combined with permissions of diradmin:mail on my Debian 7 box..... but not on my Debian 8 box, I see domain.cert.combined with permissions of diradmin:diradmin


Bug or what?

Note: I only see combined.combined for some domains, which I think are from 2018.

So my question is, is this really a permission issue with 4.92? That said, diradmin:diradmin works with other boxes with 4.92 {shrug emoji}
 
Last edited:

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
Good catch. To set correct permissions run

Code:
/usr/local/directadmin/scripts/set_permissions.sh da_files
it should set to diradmin:access 640

- domains/*.cert
- domains/*.cacert
- domains/*.cert.combined
- domains/*.key
 

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
It didn't..... it set them to diradmin:diradmin......
Code:
set /usr/local/directadmin/data/users/{user}/domains/*.cert diradmin:diradmin 640 flag
set /usr/local/directadmin/data/users/{user}/domains/*.cert.combined diradmin:diradmin 640 flag
set /usr/local/directadmin/data/users/{user}/domains/*.cacert diradmin:diradmin 640 flag
set /usr/local/directadmin/data/users/{user}/domains/*.key diradmin:diradmin 640 flag


Is the access group a default now, or do we need to add something to directadmin.conf?
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
What do you see?

Code:
/usr/local/directadmin/directadmin c |grep '^secure_access_group='
if it's empty you need to run:

Code:
echo "secure_access_group=access" >> /usr/local/directadmin/conf/directadmin.conf
service restart directadmin
echo "action=rewrite&value=secure_access_group" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin//dataskq

then run set_permissions.sh da_files again.
 
Last edited:

Peter Laws

Verified User
Joined
Sep 13, 2008
Messages
1,747
Location
London UK
It was empty, ran task queue, then the permission script....... Nothing changed........

No wonder, the set_permissions.sh has diradmin:diradmin hard-coded upon inspection :rolleyes:
 

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
8,919
Hi guys,

We've had a few tickets on this and it appears to plausibly be enforcement of something that should have been enforced before, and the fix simply enforces some other error. So it's just exposing problems with the cert/key pairs being used, rather than silently giving up and using the server cert.

A few options can be used, so there are 3 ways to go about sorting out the issue:

  1. Simply to ensure that the cert/key pair being used for this SNI connection is valid, as it appears the invalid pair that "should fallback to the main cert"?, instead fails the handshake entirely. This is recommended.
    Martynas and I have written a script to help check your cert/key pairs, it can be found here. Instructions below.
  2. Or disable the /etc/virtual/snidomains (rename the file for now), but this means that valid ones in question would no longer work, so probably not what you want.
  3. Fallback to exim 4.91, again not a great solution.

The change log for 4.92 is here:
https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog

The change most likely to be the trigger is this one:
JH/35 OpenSSL: fail the handshake when SNI processing hits a problem, server side. Previously we would continue as if no SNI had been received.
That being said, we can see there are already a whole slew of OpenSSL related to change for 4.93 (not yet released), perhaps they're addressing it in one of those, but possibly not.

For #1, to test your cert/key pairs, use the mentioned script, like this:
Code:
wget http://files.directadmin.com/services/all/ssl/verify_certs/verify_snidomains_certs.sh
chmod 755 verify_snidomains_certs.sh
./verify_snidomains_certs.sh
note that it uses /bin/bash, so ensure you have bash present.
If there are any errors, they'll end up in verify_snidomains_certs.sh.log, right beside the script.

It's possible that the cases in question are in fact a truly broken cert/key pair, in which case it's not an exim bug at all, just either expired or no longer valid, not sure.
If you happen to hit this error and can narrow down exactly which state the cert/key pair are in (.combined is preferred over the .cert), let us know, and we could even add it a nightly check on certs if needed (although, LetsEncrypt certs are already checked, so not sure exactly what people are running in to)

Any issues, feel free to let us know so we can sort out the exact cause/scenarios, and add preventative measures if needed.

John
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
It was empty, ran task queue, then the permission script....... Nothing changed........

No wonder, the set_permissions.sh has diradmin:diradmin hard-coded upon inspection :rolleyes:
I've updated my post, as it was missing a couple of steps. Please try again.
 
Top