Just a heads up for anyone wanting to try this: Outlook does NOT support TLS 1.3, at least for IMAP.
I know people should document themselves properly before tweaking and securing their servers, but maybe some warning on that page would be nice in this regard.
Something like: if you are using Outlook or any other MUA not compatible with TLS 1.3, do not try this.
It looks like it is perhaps a minimum so that you don’t use lower like v1.2 or lower?
From /etc/dovecot/conf.d/10-ssl.conf
# Minimum SSL protocol version to use. Potentially recognized values are SSLv3,
# TLSv1, TLSv1.1, and TLSv1.2, depending on the OpenSSL version used.
#ssl_min_protocol = TLSv1
Well, that was unexpected. No Windows support until Server 2022!
Note
TLS 1.3 is supported starting in Windows 11 and Windows Server 2022. Enabling TLS 1.3 on earlier versions of Windows is not a safe system configuration.
OK. I’m finding posts on the Microsoft forum saying it still isn’t supported in Outlook in Auguist, 2024. Much easier to find posts saying why you shouldn’t use V1.2 and below.
No expert but V1.2 looks unsafe from a quick search. The question is do you want to open up a machine that requires PCI compliance to a known vulnerability because of Outlook? The risks are yours to evaluate and base your personal decisions on.
Is PCI compliance required for email services if you aren’t sending any cardholder data via email (which I’m sure isn’t recommended in any case…) or are you running email services on a web server which is handling cardholder data?
@Joe, Email services like Postfix or Dovecot are indirectly covered under PCI DSS requirements if they store, process, or connect to systems handling cardholder data.
Since we can’t be certain whether the user’s server will handle cardholder data, I included it just to be safe.
@inteq pointed out a potential problem. I’d at least mention that in the docs and let the user figure out the implications. At least they won’t be caught by surprise.