What is the minimum TLS version you use for Exim?

What is the minimum TLS version you use for Exim?

  • TLS 1.3

    Votes: 0 0.0%
  • TLS 1.2 and up

    Votes: 9 81.8%
  • TLS 1.0 and up

    Votes: 2 18.2%
  • Other

    Votes: 0 0.0%

  • Total voters
    11

Erulezz

Verified User
Joined
Sep 14, 2015
Messages
697
Location
🇳🇱
DirectAdmin uses the intermediate config from Mozilla since a few years if a remember correctly and that uses TLS 1.2 and up also for Exim. There are still many Exim servers with old configs and for that reason I changed that to use TLS 1.0 and up only for Exim with the correct ciphers. I'm just curious what Exim config you use and if it's "safe" these days to disable TLS 1.0 and 1.1 for Exim and if you encounter delivery issues. Thinking of doing some tests to change this to TLS 1.2.

See this explanation from the Internet.nl test (translated from Dutch):

Note that quite a few mail servers only support older TLS versions. If the sending and receiving mail servers do not both support the same TLS version, they will typically fall back to unencrypted transport. For this reason, it may be advisable to continue to support the TLS versions with 'phasing out' status for the time being. Based on log data, make a well-considered choice about disabling these 'to be phased out' TLS versions.

See 'ICT security guidelines for Transport Layer Security (TLS) v2.1' from NCSC, guideline B1-1 and table 1
 
I'm just curious what Exim config you use and if it's "safe" these days to disable TLS 1.0 and 1.1 for Exim and if you encounter delivery issues.
Well, as you might expect from me, I disabled the older TLS versions and only use TLS 1.2, so the intermediate setting. Reason for the choice is that at a certain point also Microsoft disabled them in Office 365 by default for example.

Ofcourse it might be depending on the mail flow, but on the other hand, hosters should not use EOL versions anymore, at least if even the big company's like Office 365 also stopped using them already last year if I'm not mistaken.

Those "quite a few mail servers", should upgrade to at least support TLS 1.2 next to 1.0 and 1.1 if they want to keep using those old protocols.
This way they can still connect to all other mail servers around the world.

To me, keeping TLS 1.0 and 1.1 is not only a security issue, but also helping those lazy admins out there to keep being lazy instead of at least adding TLS 1.2 if they don't want to disable the EOL protocols.
So if they have issues to send their mail, it's -their- problem and not -ours-.

Internet.nl says "based on log data". Well that's a choice ofcourse. We had no issues at all using the intermediate, except maybe from some spam systems (mostly Chinese), which is in fact a good thing, their connections get blocked according to our log if I seen it correctly, because of not meeting the TLS requirements.

But that's us, with relativaly small mail flow. Maybe some collegue with a bigger or big mail flow can give better insights for your needs.
 
if you have multi layer firewall like big cloud data, it still can use tls1.0 .

but for us that's just small company, disable tls1.1 or lower is the best choice.
 
To me, keeping TLS 1.0 and 1.1 is not only a security issue, but also helping those lazy admins out there to keep being lazy instead of at least adding TLS 1.2 if they don't want to disable the EOL protocols.
So if they have issues to send their mail, it's -their- problem and not -ours-.
Definitely agree with you. The reason why I was still a bit hesitant about email is because in the past I sometimes did not receive important emails (such as from insurers) because I had only enabled TLS 1.2. That was a while ago, but still. But they now also use 1.2.
at least if even the big company's like Office 365 also stopped using them already last year if I'm not mistaken.
That's a good point too. TLS 1.0 and 1.1 are also no longer enabled by default in Windows 11.

I did some more reading and tests and disabled TLS 1.0 and 1.1 for Exim (y)
 
My understanding - by default, if the SSL/TLS connection cannot be established, it will fall back to plain-text connection.
 
if the SSL/TLS connection cannot be established, it will fall back to plain-text connection.
But in what? I've also read this somewhere, but I've seen connections not having this fall back.
So I wonder if this is:
a.) If SSL/TLS any version can not connect to another version with same TLS version it will fall back to plain-text?
b.) If a server with SSL/TLS connects to a server without any SSL/TLS it will fall back to plain text connection?
c.) Fallback is only when ciphers don't match?

Because i've seen connections in the log being rejected because of version mismatches without fallback to plain-text connection.

And I've only found this in the SMTP doc from Exim under a DANE setting:
Normal SMTP delivery is not able to make strong demands of TLS cipherconfiguration, because delivery will fall back to plaintext.

So I think that fallback is limited to certain conditions, otherwise not so many connections would be rejected.
But ofcourse I could be wrong.
 
You may try -
Code:
grep ' P=esmtp ' /var/log/exim/mainlog
It shall list those requests without encryption.

Also, my understanding is - Encryption is not a must in standard SMTP protocol.
(except those strict compliance requirement)
 
It shall list those requests without encryption.
Correct and like I suspected most of them coming from unkown/spamming mailservers :)

However, do they just don't have TLS instead of being a fallback? Because I also see loads of these:
Code:
2024-06-06 22:13:20 TLS error on connection from alluring.monitoring.internet-measurement.com [2a06:4880:1000::1a] (SSL_accept): error:0A0000C1:SSL routines::no shared cipher
I don't see any esmtp from the same at the same time or shortly after.
But this is a spammer, with different ipv6 so maybe there will be good ones after this... I just had a very quick look.

And yes correct, encryption is not a must in SMTP yet.
 
Back
Top