Mail app fails the internet.nl mail test on cipher suites

[imc67]

The https://en.internet.nl mail test fails the "Secure mail server connection (STARTTLS and DANE)" category on all three of my Cloudron servers — 9.2.0, mail app 3.18.2 — with identical findings on each, which suggests a platform default rather than local configuration.

Cipher suites offered that the NCSC guidelines (2025-05) rate insufficient:

TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

And rated phase out:

TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Cipher suite order fails as well — the server prefers ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 over suites rated good. Lower severity in the same test: SHA-224 for the key exchange hash (separate topic, it applies to nginx too) and client-initiated renegotiation reported as unlimited.

Everything else passes — IPv6, DNSSEC, DKIM/SPF/DMARC, DANE and RPKI — so the failed category comes down entirely to the cipher list. Each server scores 97%.

With v10 in progress: worth including?

[girish]

The last time I touched all these ciphers, they started failing left and right in production. In fact, we had to whitelist even TLS 1.1 for a big german provider. The reality is if you want to accept mail, you have to be as open as possible and people get very upset when they are unable to get mail and they get no notification about this. Since this is all at the connection level, it is incredibly hard to surface all this information to the admin and users in some meaningful way. So yeah, best not to touch all this. These are the nodejs defaults (which we keep upgrading. Cloudron 10 has 24.19.0).

$ node -e 'console.log(require("tls").DEFAULT_CIPHERS)'
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA

[imc67]

The opportunistic-TLS point is fair and I'll concede it — on port 25 a weak cipher beats a plaintext fallback, and internet.nl's model implicitly assumes an enforcing world (DANE, MTA-STS) that doesn't match how inbound mail actually works.

One correction on the Node side though, because it affects the "we track Node's defaults" reasoning. Read off the running mail container:

# node -p 'require("tls").DEFAULT_CIPHERS'
...:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA

That list names 12 suites explicitly and then ends with the HIGH: catch-all, which expands it to 58. Every flagged suite arrives through the catch-all — not one of them is named in Node's own list:

                                 with HIGH:   without
ECDHE-ECDSA-AES256-CCM8             yes         no
ECDHE-ECDSA-ARIA256-GCM-SHA384      yes         no
ECDHE-ECDSA-AES256-SHA              yes         no

So upgrading Node doesn't move this. The list has had the same shape for years, and Node 24 in Cloudron 10 will produce the same test result that Node 22 does today.

And the compatibility argument, while true, covers a narrower set than the whole list. The long tail of old MTAs lives on the CBC-SHA1 suites. ARIA is a Korean national standard and CCM_8 is a short-tag variant from the IoT world — no MTA in the wild speaks only those. Just noting where the observation stands; the trade-off is yours to make.