On Fri, Feb 27, 2026 at 09:04:14AM +0100, Niels Dettenbach via mailop wrote:
> Am Donnerstag, 26. Februar 2026, 18:08:26 UTC+00:00:01 schrieb Michael
> Peddemors via mailop:
> > We did still find that about 30% of those were still trying to use old
> > TLS, or not properly negotiating based on advertised versions support
> > and ciphers supported..
>
> i remember a similiar scenario where the affected SMTP server was configured
> to offer obsolete ciphers / hashings / TLS versions while the integrated SSL
> lib was not able to handle that all anymore.
>
> If the connecting server choosed a offered combination not supported by the
> ssl lib anymore, connection dropped without meaningful log entries on both
> sides.
These sort of handwavy conjectures don't get us any closer to a
solution, pending a PCAP file. Everything else is pure unfounded
speculation including the below:
The only visible oddity is the variant server "EHLO response" that ends
in
250 SMTPUTF8
in the reported server session, but why I connect it is:
250-SMTPUTF8
250 XSHADOW
If there is some sort of proxy that conditionally inserts itself into
the connection, or is bypassed entirely by the problem sender, then that
could be part of the problem.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
