Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 50

Thread: Exim 4.92

  1. #21
    Join Date
    Jan 2008
    Location
    Sneek, Netherlands
    Posts
    28
    Quote Originally Posted by soulshepard View Post
    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.

  2. #22
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    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 by Peter Laws; 06-14-2019 at 02:05 PM.

  3. #23
    Join Date
    Apr 2005
    Location
    GMT +7.00
    Posts
    13,311
    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.
    Regards, Alex G.

    - Get the best commercial DirectAdmin support and hire me on poralix.com
    - Follow and like @Poralix on Facebook

  4. #24
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    Quote Originally Posted by zEitEr View Post
    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


  5. #25
    Join Date
    Sep 2005
    Posts
    381
    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.

  6. #26
    Join Date
    Sep 2005
    Posts
    381
    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.

  7. #27
    Join Date
    Sep 2005
    Posts
    381
    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.

  8. #28
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    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.

  9. #29
    Join Date
    Feb 2008
    Posts
    133
    Quote Originally Posted by AndriesLouw View Post
    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.

  10. #30
    Join Date
    Mar 2016
    Posts
    9
    Quote Originally Posted by smtalk View Post
    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?

  11. #31
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    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 by Peter Laws; 06-18-2019 at 08:07 AM.

  12. #32
    Join Date
    Apr 2005
    Location
    GMT +7.00
    Posts
    13,311
    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.
    Regards, Alex G.

    - Get the best commercial DirectAdmin support and hire me on poralix.com
    - Follow and like @Poralix on Facebook

  13. #33
    Join Date
    Jan 2004
    Location
    Russia
    Posts
    257
    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 by ClayRabbit; 06-19-2019 at 06:02 AM.
    From Siberia with love
    And sorry for bad english

  14. #34
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    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 by Peter Laws; 06-19-2019 at 06:56 AM.

  15. #35
    Join Date
    Apr 2005
    Location
    GMT +7.00
    Posts
    13,311
    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
    Regards, Alex G.

    - Get the best commercial DirectAdmin support and hire me on poralix.com
    - Follow and like @Poralix on Facebook

  16. #36
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    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?

  17. #37
    Join Date
    Apr 2005
    Location
    GMT +7.00
    Posts
    13,311
    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 by zEitEr; 06-19-2019 at 09:02 PM. Reason: Updated
    Regards, Alex G.

    - Get the best commercial DirectAdmin support and hire me on poralix.com
    - Follow and like @Poralix on Facebook

  18. #38
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,734
    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

  19. #39
    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/ma...-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

  20. #40
    Join Date
    Apr 2005
    Location
    GMT +7.00
    Posts
    13,311
    Quote Originally Posted by Peter Laws View Post
    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
    I've updated my post, as it was missing a couple of steps. Please try again.
    Regards, Alex G.

    - Get the best commercial DirectAdmin support and hire me on poralix.com
    - Follow and like @Poralix on Facebook

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •