On Sun, Sep 27, 2026 at 09:20:00PM +0200, Joachim Lindenberg via Postfix-users 
wrote:

> Actually I now noticed that the errors are alternating between "client
> TLS configuration problem" and "Cannot start TLS: handshake failure".

You really do need to fix the first problem.  The second happens when
STARTTLS is actually attempted, but the TLS handshake fails.

If you're unable to post the configuration details, help will be quite
limited.

> Mailcow uses a (non-standard) tls-policy-agent, no idea whether it
> returned an erroneous value, but I then hardwired the policy to
> "dane-only" and then captured network traffic with tcpdump.

Postfix 3.12-20260925 (anything after 20260514) supports conditional
recording of TLS protocol traces.  Configuration looks like:

    smtpd_tls_loglevel_maps =
        # ...
    smtp_tls_loglevel_maps =
        inline:{{host.example = 1,trace}},
        cidr:{{192.0.2.0/24 1,trace},
              {2001:db8::/32 1,trace}}

> One shows a Hello Retry Request, the other plenty of retransmissions.

You could disable support for PQ key exchange:

    tls_eecdh_auto_curves = X25519 prime256v1 X448 secp384r1 secp521r1
    tls_ffdhe_auto_groups = ffdhe2048:ffdhe3072

perhaps that'd help.

> I was able
> to deliver both messages using a policy "none". Therefore I don´t know
> but suspect it might be related to OpenSSL changes, as I previously
> was able to deliver to both destinations.
> 
> What information might help to clarify? The network traces I obtained? 
> Postfinger, but then what options?

You could start with (linebreaks preserved accurately):

    $ postconf mail_version
    $ postconf -nf
    $ postconf -Mf

tshark decodes of PCAP files may also be helpful.  Some "tshark" notes
from an old post below my signature:

-- 
    Viktor.  🇺🇦 Слава Україні!

Most likely your problem is elsewhere, in which case, a "tshark" decode
of a single connection attempt from that client will be needed to
determine what went wrong.

   # CLIENT_IP=192.0.2.1  # Insert actual IP address here
   # tcpdump -s 0 -w /tmp/smtp.pcap tcp port 25 and host "$CLIENT_IP" &
   # pid=$!
   ... Wait for client to try to connect and fail ...
   # kill -INT $pid

   # tcpdump -nr /tmp/smtp.pcap 'tcp[13] & 0x12 = 0x02'

The above reports SYN packets from the client, note the client's TCP
source port number for the first reported connection.  For example:

   19:05:39.014372 IP 127.0.0.1.52757 > 127.0.0.1.25: Flags [S],
       seq 3815386084, win 65535, options
       [mss 16344,nop,wscale 6,nop,nop,TS val 3114352004 ecr 0,sackOK,eol],
       length 0

This has client port == 525757

Run the PCAP recording through "tshark":

   # CPORT=52757 # Insert actual TCP port number here
   # tshark -r /tmp/smtp.pcap -V -d tcp.port==25,ssl tcp.port==$CPORT |
       sed -ne '/^Transport Layer Security/,/^$/p' > /tmp/tshark.txt

Post the "tshark.txt" file here (attach it, without folding lines or
otherwise changing whitespace), but keep the PCAP file around, just in
case.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to