Hi John, thanks for your answer.
I got another logfile from the sending side: [email protected]:/root<mailto:[email protected]:/root> # openssl s_client -starttls smtp -connect edge01.systema-online.de:25CONNECTED(00000003)depth=2 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46verify return:1depth=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36verify return:1depth=0 CN = edge01.systema-online.deverify return:1---Certificate chain 0 s:CN = edge01.systema-online.de i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Jul 8 00:00:00 2025 GMT; NotAfter: Aug 8 23:59:59 2026 GMT 1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36 i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46 a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA384 v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT---Server certificate-----BEGIN CERTIFICATE-----MIIGojCCBQqgAwIBAgIQIab2w8fXCWFzN2AroPpn0zANBgkqhkiG9w0BAQsFADBgMQswCQYDVQQGEwJHQjEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5TZWN0aWdvIFB1YmxpYyBTZXJ2ZXIgQXV0aGVudGljYXRpb24gQ0EgRFYgUjM2MB4XDTI1MDcwODAwMDAwMFoXDTI2MDgwODIzNTk1OVowITEfMB0GA1UEAxMWZWRnZTAxLndlcmRlci1oYXZlbC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfFEeCRa1RqE3Z/TuZDR5vncfEpqdP9ADhKus0noJQuThSxn+IW4CxqtNuQ9jVR9JpUgqza6Uqm/R/sJ11CR/EQ79nplG1sjrVzFW1VzgsEPCxz7Y0jsJx7Kka9IQZt6zz2C6SydGnRJtpLkDGkUV0aYTav2iCsp6S0jYGNXINicfMx6H86IYemJrPZDoK6eSd+mfA73KElD0gffZVU60U8l+OcwmsQOIX6khnFAWLny78YvOFjXQsIzCqSxvbEWxWwnFnSANc8v4mjkejeZ1a/FJH17UddjJOkWXZqeklIzMMqfzWrVrZKi7rqyQO5lAw9lzdOSzj58xAyH3WCkpUCAwEAAaOCAxUwggMRMB8GA1UdIwQYMBaAFGjAEhYYDq/O9oemMlejRlFdywcnMB0GA1UdDgQWBBRL+PQdFno+LAZWTAre+HEdRGhEWDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdvUHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURWUjM2LmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wPQYDVR0RBDYwNIIWZWRnZTAxLndlcmRlci1oYXZlbC5kZYIad3d3LmVkZ2UwMS53ZXJkZXItaGF2ZWwuZGUwggF/BgorBgEEAdZ5AgQCBIIBbwSCAWsBaQB2ANgJVTuUT3r/yBYZb5RPhauw+Pxeh1UmDxXRLnK7RUsUAAABl+pkfzUAAAQDAEcwRQIgCeeV2eI3bDL+jwdyIc89F3vO8r+YXiJc9WhJYSk1p+4CIQDN/Qtp7Tzp7ZsI4q8VOV0E1gpsqRxUYXohdOx+AobDrAB2AKyrMHBs6+yEMfQT0vSRXxEeQiRDsfKmjE88KzunHgLDAAABl+pkfwMAAAQDAEcwRQIgWteBGHcPie2ulg9Z+eh2WaOH3tXGNx9B2jrAhHehWDoCIQCDfY1yzKTtWVDn34C/RPHx5Eqlcw+QZKo27QOaRrld1gB3ANdtfRDRp/V3wsfpX9cAv/mCyTNaZeHQswFzF8DIxWl3AAABl+pkfs8AAAQDAEgwRgIhAPw9hceoLz4QmCVxqW56vbzhhPegs5otPO13C/JFsjA9AiEAwngnRw9U7+EEe4a4KIj6H/Bk2azTB5oVAXzTuvIIlp4wDQYJKoZIhvcNAQELBQADggGBAF+cAlor8MXqInB8YfPZ2GIbpBrD3m18NAldBCJMgzGOGyUls66Ty8z425VLE9/FmCcejkMtaAFskZb5g/pqUj4fHWzFCDvDkfyXs3Dfr3mjFjXiR8dlC+sGQtmztyqzpD65TR3DBReAyb6eWOO9qfF0czQn13kj65q5t5xORDii1tOXVZMao+mVcr1qWOVP1HbXkcUiq+g13W5TL7cmyIQtUVxQA0tzzPGMlHKXJA+y0IcS9do9i1YzHyMNDGCskSxn8oy/rTrJ87rCK7lxln7T5SlsO3sSlHKFdSEdMeD8yHbkKDVTe2C6FFQLR8JDBvFy/T3i4ghHDVrR9Dn9/OHqP7+Vb3BCktRl411a22aGv79uzJeZI5831C/oP6MlUEt55lVE12fDUp82uuj8Lvtkvv5QC84BDz59ZDqjZCsp2lTBr8APKpOqM/UaeSsLwp24Kj1o+Kck+HwBdYxN7EtnM16BTbDIwSYuPZ5USIkehh4WTfvwLQWiZMqVPVnWNA==-----END CERTIFICATE-----subject=CN = edge01.systema-online.deissuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36---No client certificate CA names sentPeer signing digest: SHA256Peer signature type: RSA-PSSServer Temp Key: ECDH, secp384r1, 384 bits---SSL handshake has read 4157 bytes and written 515 bytesVerification: OK---New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384Server public key is 2048 bitSecure Renegotiation IS supportedCompression: NONEExpansion: NONENo ALPN negotiatedSSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: C0220000C75E404CD98FB0AD746B8C71BCA45BD0AAEB53DB5CF04A3C84B7EA47 Session-ID-ctx: Master-Key: 11E365F029F52A74654A94A539542E4CCA052140EB196E767B2BC849CEF45B5524F93D0E1135E5CC682DDFD6462530DE PSK identity: None PSK identity hint: None SRP username: None Start Time: 1772011298 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes---250 SMTPUTF8ehlo mx.self-hosted.email451 4.7.0 Timeout waiting for client input40A7BCB1747C0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:316:[email protected]:/root # Don’t know if you might find that helpful. But at least that’s openssl. You are right about same log entries from both sides. I’ll try to get another one. But as I see the same error from this sender since “months” and on my side always the same remote(SocketError). This telnet session and the above openssl session snippet is the only info I got til now. Regarding the website https://de.ssl-tools.net/ does not get you something in your browser? The sender send me the side to show me, that the side has the “same?” problems like he has connecting to our server. So it might or might not be related. As I don’t get much more info from the side either except “unexpected EOF”. Kind regards Norbert Von: mailop <[email protected]> Im Auftrag von John Fawcett via mailop Gesendet: Donnerstag, 26. Februar 2026 13:17 An: [email protected] Betreff: Re: [mailop] Problem: Timeout after starttls HI Norbert comments in line On 26/02/2026 12:04, Fehlauer, Norbert via mailop wrote: Hi, I’m having a problem receiving mails from some sending servers. The logfile shows, that the sending server won’t send after the tls session is started: 2026-01-20T14:22:07.126Z,edge01\Internet,08DE372FE331F619,7,10.0.0.4:25,194.42.96.41:35025,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 0 bits and key exchange algorithm CALG_ECDH_EPHEM with strength 384 bits" 2026-01-20T14:22:07.141Z,edge01\Internet,08DE372FE331F618,8,10.0.0.4:25,194.42.96.41:46695,-,,Remote(SocketError) 2026-01-20T14:22:07.159Z,edge01\Internet,08DE372FE331F619,8,10.0.0.4:25,194.42.96.41:35025,-,,Remote(SocketError) Presumably the remote server suddenly disconnected. Why will hopefully be in the logs of the remote server. I don't think there is evidence to support it being a timeout issue. https://de.ssl-tools.net/mailservers/systema-online.de Does not resolve to a website for me. testing with this tool seems to be different handling when using the server with ecc certificate (edge02) instead of RSA based certificate. Both are Exchange Servers with Edge Role. I contacted the supportdesk of an affected sender (cleverreach) and they send me some telnet logs, but I just don’t see any hint if the problem is on my side or if the sending side just handles something wrong. $ telnet edge01.systema-online.de 25 Trying 178.15.145.73...Connected to edge01.systema-online.de.Escape character is '^]'.220 edge01.systema-online.de Microsoft ESMTP MAIL Service ready at Wed, 25 Feb 2026 10:28:08 +0100ehlo crash.crsend.com250-edge01.systema-online.de Hello [80.228.25.228]250-SIZE 20971520250-PIPELINING250-DSN250-ENHANCEDSTATUSCODES250-STARTTLS250-8BITMIME250-BINARYMIME250-CHUNKING250 SMTPUTF8ehlo crash.crsend.com250-edge01.systema-online.de Hello [80.228.25.228]250-SIZE 20971520250-PIPELINING250-DSN250-ENHANCEDSTATUSCODES250-STARTTLS250-8BITMIME250-BINARYMIME250-CHUNKING250 SMTPUTF8500 5.3.3 Unrecognized command 'unknown'ehlo crash.crsend.com500 5.3.3 Unrecognized command 'unknown'ehlo crash.crsend.com250-edge01.systema-online.de Hello [80.228.25.228]250-SIZE 20971520250-PIPELINING250-DSN250-ENHANCEDSTATUSCODES250-STARTTLS250-8BITMIME250-BINARYMIME250-CHUNKING250 SMTPUTF8250-edge01.systema-online.de Hello [80.228.25.228]250-SIZE 20971520250-PIPELINING250-DSN250-ENHANCEDSTATUSCODES250-STARTTLS250-8BITMIME250-BINARYMIME250-CHUNKING250 SMTPUTF8 Anyone has an idea what the problem might be? Hard to tell from this string of data. Seems that during the telnet session, some invalid input was given. I would say that whatever error was made in the telnet session is unrelated to your problem. Reason for saying that is that telnet is not useful for testing encrypted connections. For this kind of testing openssl s_client command is appropriate. It's important to get the logging from the same transaction that gave you the error or if it's a test to reproduce the error, it's important to capture both sides of the logging from the same test, else you won't really know if the error is the same one you're troubleshooting or an unrelated one. Regards Norbert
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
