On Sat, Sep 26, 2026 at 12:53:48AM -0700, Mel P via Postfix-users wrote: > > I am puzzled what what interop issues those might be? Something at the > > DNS layer preventing adding them to the MX host zone? > > A mail system that mine talks to regularly is DANE-aware, but whatever > they're using can't negotiate TLS with postfix 3.11 + OpenSSL 3.5 even > though I use smtpd_tls_* defaults.
Well, that's interesting an potentially useful data. Have you been able
to examine a TLS protocol trance of an attempted handshake?
What's notably new in Postfix 3.11 + OpenSSL 3.5 is support for the
PQ-hybrid X25519MLKEM768, which becomes relevant only when both ends
support it, however your server appears to not issue a Hello Retry
Request (HRR) when the client supports it but the initial keyshares
include X25519-only:
$ posttls-finger -c -Lsummary,trace bluerosetech.com
posttls-finger: TLS protocol trace saved to
posttls-finger-20260926193527.001273-208.111.40.118-DVmqrm
posttls-finger: Untrusted TLS connection established to
echo.brtsvcs.net[208.111.40.118]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
(256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits)
server-digest SHA256
Even when the initial client keyshares do include X25519MLKEM768, I still
see the server choosing just plain X25519:
$ posttls-finger -o "tls_eecdh_auto_curves = DEFAULT" -c -Lsummary,trace
bluerosetech.com
posttls-finger: TLS protocol trace saved to
posttls-finger-20260926194312.727960-2607:f740:c::4ae-K5aGj3
posttls-finger: Untrusted TLS connection established to
echo.brtsvcs.net[2607:f740:c::4ae]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature
RSA-PSS (4096 bits) server-digest SHA256
So it remains a puzzle why the system in question is running into some
friction. The server's handshake parameters are in no way exotic or
specific to new OpenSSL 3.5 features. The only thing slightly unusual
that should not matter with DANE is that the server's certificate
appears to be issued by a private CA:
C = US, ST = Oregon, L = Portland, O = brtsvcs.net, OU = Certificate
Authority, CN = brtsvcs.net CA
If you did have TLSA records in place, they existed so fleetingly that
the DANE survey (running once a day) never managed to record their
existence. DNSSEC-signed MX records pointing to the same DNSSEC-signed
MX hosts date back to July 30 2019...
--
Viktor. 🇺🇦 Слава Україні!
posttls-finger-20260926193527.001273-208.111.40.118-DVmqrm.gz
Description: application/gzip
posttls-finger-20260926194312.727960-2607:f740:c::4ae-K5aGj3.gz
Description: application/gzip
_______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
