5

I have a home server and updated the system drive to an SSD as it had been on a combination of USB and HDD for /home and /var. Because the USB was on a previous version of Debian I have done a fresh install, which has also upgraded me to version 4.95 of EXIM, previously I was on 4.94.2.

Despite the same smarthost configuration, to use my ISP's SMTP server, it no longer uses TLS and gives a validation error.

/var/log/exim4/mainlog:

2022-04-12 03:30:25 1ne6I7-000AHw-MF TLS session: (certificate verification failed): delivering unencrypted to H=<DOMAIN> [<IP>] (not in hosts_require_tls)

The mail is still accepted unencrypted, but now mail from cron jobs is being flagged by my I.S.P. as spam. The only change being messages being a Received header which has gone from being with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) to just with esmtp (Exim 4.95). So presumably that difference is what is flagging it for extra attention.

I had been using the same self-signed key and certificate (with a 2013) timestamp as the previous installation. I also tried generating a new pair with similar lack of effect.

After searching online for advice it was suggest to use a letsencrypt configuration so it could be validated. I already use that, but it caused the same behaviour in EXIM.

This is my configuration

/etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='<LOCAL DOMAIN>'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<ISP DOMAIN>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

/etc/exim4/etc/exim4/conf.d/main/00_local_settings:

MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<LOCAL DOMAIN>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<LOCAL DOMAIN>/privkey.pem

/etc/letsencrypt/archive/<LOCAL DOMAIN>/*15.*

-rw-r--r-- 1 root Debian-exim 1870 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem

I also have /etc/exim4/passwd.client file with my SMTP login details, and which obviously is working to be sending mail at all.

is a domain which points to my home IP addrress.

The entries to the letsencrypt keys in 00_local_settings point to its symlinks that go to the current versions. On those I have changed the group ownership so that EXIM can see the private key, but leave the permissions alone.

My previous working configuration was the same, but with the self-signed exim.crt and exim.key files in /etc/exim4, and so without the latter two lines in my 00_local_settings file.

I have also tried copying the letsencrypt files into /etc/exim4 and naming them exim.cert and exim.key with the same permissions of 640 and nothing in 00_local_settings but it did not change anything.

What is particularly annoying is that as a final test I just deleted the keys with no configuration for them to see what would happen. I got the same error, so I am cannot tell whether there is a problem with the keys I have used, or it is just not even seeing them at all.

2
  • 1
    look for clues in /var/log/exim4/mainlog and /var/log/exim4/paniclog
    – Jasen
    Commented Apr 14, 2022 at 0:08
  • 1
    Unfortunately there is no paniclog and the line I gave is the only clue in mainlog. The entries before and after the same as one the old Debian system, to confirm the connection and that the mail has been accepted. But for the TLS error I included everything looks normal. Not even a configuration error is logged anywhere when launching Exim. I am completely lost what to do.
    – Rebecka
    Commented Apr 14, 2022 at 12:49

1 Answer 1

8

I have continued to research and I have found an answer, of sorts. It was not clear to me whose certificate was being verified, I had assumed mine but realized it could be the one of the remote SMTP server.

Adding the entry below to /etc/exim4/etc/exim4/conf.d/main/00_local_settings disables verification, allows TLS to be used.

REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*

This can be confirmed in a message header which now shows it being received with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)

I assume this is what was happening before and that either Debian or Exim have changed the default to require verification since my initial configuration.

Presumably if the remote server uses a self-generated certificate it cannot be verified?

3
  • 1
    on re-reading th log line I was about to suggest the same cause.
    – Jasen
    Commented Apr 15, 2022 at 1:37
  • 1
    It was a bit vague as to who was dong the verifying of whom as it gives no suggestion which server generated the error. Given I searched a lot to find an answer without success, hopefully having posted it here means anyone else in s similar situation will find the simple solution. Thanks for taking a look at the question though.
    – Rebecka
    Commented Apr 16, 2022 at 0:25
  • 2
    Thanks! This was driving me mad.
    – Tim Angus
    Commented Dec 5, 2022 at 13:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .