Docker Mailserver
Specify TLSv1.3 as the only TLS version #4714
-
|
Hello, I try and score 100% on the internet.nl mail test and they've recently marked several TLSv1.2 cipher suites as phase-out or insufficient which drops the overall score. Is there somewhere I can specify my own cipher suites or TLSv1.3 as the minimum TLS version? I saw I could specify my own DH groups, but all groups are marked phase-out or insufficient as well. And specifying 1.3 didn't work in mailserver.env for TLS_LEVEL, unless I had the wrong syntax. Any help is appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
This answer provides context for why I discourage chasing scores without understanding the risk of doing so. You should be fine however setting TLS 1.3 as the minimum if you're only dealing with modern mail servers and clients. However keep in mind you're reducing compatibility in favor of a score, DMS has you covered with secure TLS 1.2 cipher suite config (feel free to read through my lengthy audit from 2020-2021 linked below if you need assurance on that).
The DMS ENV The This feature only applies to client ports such as:
Those are all ports your mail client can interact with to retrieve mail or submit it to be sent. Security matters for these ports the most. Port 25 (StartTLS) where mail is delivered to DMS from external mail servers is more relaxed and permits a wider set of cipher suites.
These services tend to be more of a guide for those that lack expertise to know better. I want to place emphasis on as a guide because chasing a perfect score does not necessarily mean it's the best, especially if the test is generic. Here's various examples to demonstrate what I mean:
From the above are also comments of mine (1, 2) emphasizing on the fact not to chase scores but use such scanning tools/services as a guide for awareness of what may be wrong and looking into that. As shown from the cited links above the scores themselves from such tools aren't necessarily accurate or reliable depending on context.
Yes there is support to customize them, but you're generally advised not to (especially if you don't know what you're doing). Despite standardized groups being used by a large number of servers, these start at 2048-bit and as a result are quite secure like I mentioned with RSA 2048-bit. In fact TLS 1.3 does have the ability to use DHE and forbids custom groups, instead using the standardized ones (RFC 7919). OpenSSL for example provides this (although I think there was a recent change related to such support, I can't recall if that was TLS 1.2 or TLS 1.3... I think it was to allow TLS 1.2 to leverage standardized groups implicitly without providing them to OpenSSL). EDIT: Ah here is a comment from the Postfix maintainer at OpenSSL about using RFC 7919 groups for TLS 1.2 (despite the later history in that thread, that was resolved and should be included in the OpenSSL 4.0 release (April 2026)). NOTE: DMS will eventually remove DHE cipher suites (with docs for manually restoring support). If users require that for older clients, but it should mostly be irrelevant these days AFAIK (I don't keep track of SMTP ciphersuite negotiations or manage a mail server myself, but by now I'd hope most clients are capable of TLS 1.3 or the older TLS 1.2 cipher suites). |
Beta Was this translation helpful? Give feedback.
-
Here is the short and sweet advice that should work for you via a Be aware what you've asked for isn't officially supported, so when upgrading DMS in future do pay extra attention to our changelog (as this advice is not officially supported, such breakage may not be as obvious). It's possible a future release breaks the advised solution (generally I try to enable users to customize and have control, but that sometimes conflicts with DMS scripts and expectations of what DMS has authority over). Adapt the following reference to your own services:
dms:
image: ghcr.io/docker-mailserver/docker-mailserver:15.1
hostname: mail.example.test
environment:
# Workaround - Prevent DMS from undoing your custom changes for forcing TLS 1.3:
# (NOTE: May break in future image upgrade)
TLS_LEVEL: CUSTOM
# You must set this to a valid value to leverage TLS (otherwise TLS is disabled by default):
# https://docker-mailserver.github.io/docker-mailserver/v15.1/config/environment/#ssl_type
SSL_TYPE: letsencrypt
# These are embedded configs in `compose.yaml`, you can use `volumes` instead if you prefer:
configs:
- source: overrides-postfix
target: /tmp/docker-mailserver/postfix-main.cf
- source: overrides-dovecot
target: /tmp/docker-mailserver/dovecot.cf
# Using the Docker Compose `configs.content` feature instead of volume mounting separate files.
# NOTE: This feature requires Docker Compose v2.23.1 (Nov 2023) or newer:
# https://github.com/compose-spec/compose-spec/pull/446
configs:
overrides-postfix:
content: |
smtpd_tls_protocols = >=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.3
smtp_tls_protocols = >=TLSv1.3
overrides-dovecot:
content: |
ssl_min_protocol = TLSv1.3NOTE: You possibly don't need or care about the
Full explanationIf you still insist on this, the relevant settings to modify are here: docker-mailserver/target/postfix/main.cf Lines 43 to 46 in 4257c15 docker-mailserver/target/dovecot/10-ssl.conf Lines 53 to 55 in 4257c15 Postfix 3.6+ can use simpler syntax (DMS v15.1 provides Postfix 3.7, our config just hasn't been updated to the newer syntax yet): # Inbound connections (port 25, mandatory is for ports 587 and 465):
smtpd_tls_protocols = >=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.3
# Outbound connections (DMS sending mail to another mail server):
# Warning: This means if the MTA DMS connects to doesn't support TLS 1.3, you'll likely fallback to unencrypted.
smtp_tls_protocols = >=TLSv1.3Dovecot ssl_min_protocol = TLSv1.3Apply the above with our However... our docker-mailserver/target/scripts/helpers/ssl.sh Lines 87 to 104 in 4257c15 Presently it looks like you can workaround this by adding the docker-mailserver/target/scripts/helpers/ssl.sh Lines 133 to 157 in 4257c15 To my knowledge, that'd be more problematic with TLS 1.2 (if we had to consider changing the cipher suites), but with TLS 1.3 since that's no longer relevant, I think you'll be alright. AFAIK that seems to be the only relevant DMS logic affecting the TLS level config for both the Postfix and Dovecot services 👍 |
Beta Was this translation helpful? Give feedback.
Here is the short and sweet advice that should work for you via a
compose.yamlreference.Be aware what you've asked for isn't officially supported, so when upgrading DMS in future do pay extra attention to our changelog (as this advice is not officially supported, such breakage may not be as obvious). It's possible a future release breaks the advised solution (generally I try to enable users to customize and have control, but that sometimes conflicts with DMS scripts and expectations of what DMS has authority over).
Adapt the following reference to your own
compose.yaml: