On 2026-09-26 3:26, Viktor Dukhovni via Postfix-users wrote:
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?
Yes, but the cause is terribly boring: disjoint cipherlists.
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
foxtrot:
posttls-finger: Untrusted TLS connection established to
foxtrot.brtsvcs.net[2607:f740:14::c13]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519MLKEM768
server-signature RSA-PSS (4096 bits) server-digest SHA256
echo isn't using 3.5 yet.
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...
They were in the public horizon for half an evening--just long enough to
blow up delivery.
p.s., do you have a link for the DANE survey mentioned?
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
