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.
2
