XSHADOW is more commonly used in Microsoft Exchange Server. That, along with some of the other headers (e.g., XECH50), seems to indicate such.
https://learn.microsoft.com/en-us/exchange/mail-flow/transport-high-availability/shadow-redundancy FWIW, the remote server certificate appears to have been updated in the past 24 hours. We recently saw a similar issue with an Exchange server - the certificate itself was incorrectly set up and resulted in a similar log error: 05460 09:51:58.627 RX: <250-SIZE 37748736> 05460 09:51:58.627 RX: <250-PIPELINING> 05460 09:51:58.627 RX: <250-DSN> 05460 09:51:58.627 RX: <250-ENHANCEDSTATUSCODES> 05460 09:51:58.627 RX: <250-STARTTLS> 05460 09:51:58.627 RX: <250-X-ANONYMOUSTLS> 05460 09:51:58.627 RX: <250-AUTH NTLM> 05460 09:51:58.627 RX: <250-X-EXPS GSSAPI NTLM> 05460 09:51:58.627 RX: <250-8BITMIME> 05460 09:51:58.628 RX: <250-BINARYMIME> 05460 09:51:58.628 RX: <250-CHUNKING> 05460 09:51:58.628 RX: <250-SMTPUTF8> 05460 09:51:58.628 RX: <250 XRDST> 05460 09:51:58.628 TX: <STARTTLS> 05460 09:51:58.810 RX: <220 2.0.0 SMTP server ready> 05460 09:51:58.999 SSL connection error. - SSL_ERROR_SSL 05460 09:51:58.999 error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:703 Once configured correctly, the connections succeeded. -----Original Message----- From: mailop <[email protected]> On Behalf Of Viktor Dukhovni via mailop Sent: Friday, February 27, 2026 2:48 PM To: [email protected] Cc: Viktor Dukhovni <[email protected]> Subject: Re: [mailop] Problem: Timeout after starttls On Thu, Feb 26, 2026 at 03:42:30PM +0000, Fehlauer, Norbert via mailop wrote: > Yes, the actual problem is, that the sender can not send mails to the > server and as it is with this kind of problems he says it's our > problem and I'm relatively confident that the problem is on the > sender's side. It is not yet clear whether the issue is at the network layer, or higher up the stack. At this point a PCAP file (network packet capture) of a *single* complete connection with that server is essential. Make sure you're capturing full size rather than truncated to a smaller size packets (tcpdump -s 0, if using tcpdump). > 2026-02-25T09:20:21.807Z,edge01\Internet,08DE6A521B0E8C30,1,172.25.0.2 > 6:25,194.42.96.40:59854,>,"220 edge01.systema-online.de Microsoft > ESMTP MAIL Service ready at Wed, 25 Feb 2026 10:20:21 +0100", > 2026-02-25T09:20:21.839Z,edge01\Internet,08DE6A521B0E8C30,2,172.25.0.2 > 6:25,194.42.96.40:59854,<,EHLO mail.example.com, > 2026-02-25T09:20:21.839Z,edge01\Internet,08DE6A521B0E8C30,3,172.25.0.2 > 6:25,194.42.96.40:59854,>,250 edge01.systema-online.de Hello > [194.42.96.40] SIZE 20971520 PIPELINING DSN ENHANCEDSTATUSCODES > STARTTLS 8BITMIME BINARYMIME CHUNKING SMTPUTF8, > 2026-02-25T09:20:21.870Z,edge01\Internet,08DE6A521B0E8C30,4,172.25.0.2 > 6:25,194.42.96.40:59854,<,STARTTLS, > 2026-02-25T09:20:21.870Z,edge01\Internet,08DE6A521B0E8C30,5,172.25.0.2 > 6:25,194.42.96.40:59854,>,220 2.0.0 SMTP server ready, > 2026-02-25T09:20:21.870Z,edge01\Internet,08DE6A521B0E8C30,6,172.25.0.26:25,194.42.96.40:59854,*," > CN=edge01.systema-online.de CN=Sectigo Public Server Authentication CA DV > R36, O=Sectigo Limited, C=GB 21A6F6C3C7D709617337602BA0FA67D3 > 5878E90CE2818CF8B7BA5E6085F0128FE8237223 2025-07-08T02:00:00.000Z > 2026-08-09T01:59:59.000Z > edge01.systema-online.de;www.edge01.systema-online.de",Sending certificate > Subject Issuer name Serial number Thumbprint Not before Not after Subject > alternate names > 2026-02-25T09:20:21.948Z,edge01\Internet,08DE6A521B0E8C30,7,172.25.0.26:25,194.42.96.40:59854,*,,"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" A TLS 1.2 handshake completes normally. With TLS 1.2, any session tickets are sent before the server's TLS "finished" message, So that by the time their reported "openssl s_client" session reports handshake complete, there are no outstanding TLS handshake messages to be sent in either direction, the rest is just application_data until the connection is torn down. > 2026-02-25T09:21:21.996Z,edge01\Internet,08DE6A521B0E8C30,8,172.25.0.2 > 6:25,194.42.96.40:59854,>,451 4.7.0 Timeout waiting for client input, And then for 60s the server hears nothing from the client. Which is odd, because the next thing that should happen is the client resending EHLO inside the just-established TLS-encrypted channel, as shown below (see ---> prefixed line): $ posttls-finger -Lsummary edge01.systema-online.de posttls-finger: Connected to edge01.systema-online.de[2a00:0:2d41:2:178:15:145:73]:25 posttls-finger: < 220 edge01.systema-online.de posttls-finger: > EHLO amnesiac posttls-finger: < 250-edge01.systema-online.de Hello [2001:db8::2] posttls-finger: < 250-SIZE 37748736 posttls-finger: < 250-PIPELINING posttls-finger: < 250-DSN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-STARTTLS posttls-finger: < 250-X-ANONYMOUSTLS posttls-finger: < 250-X-EXPS NTLM posttls-finger: < 250-8BITMIME posttls-finger: < 250-BINARYMIME posttls-finger: < 250-CHUNKING posttls-finger: < 250-XEXCH50 posttls-finger: < 250-SMTPUTF8 posttls-finger: < 250 XSHADOW posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 SMTP server ready posttls-finger: Verified TLS connection established to edge01.systema-online.de[2a00:0:2d41:2:178:15:145:73]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) ---> posttls-finger: > EHLO amnesiac posttls-finger: < 250-edge01.systema-online.de Hello [2001:db8::2] posttls-finger: < 250-SIZE 37748736 posttls-finger: < 250-PIPELINING posttls-finger: < 250-DSN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-X-EXPS NTLM posttls-finger: < 250-8BITMIME posttls-finger: < 250-BINARYMIME posttls-finger: < 250-CHUNKING posttls-finger: < 250-XEXCH50 posttls-finger: < 250-SMTPUTF8 posttls-finger: < 250 XSHADOW posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Service closing transmission channel That same "openssl s_client" (with the missing line breaks) purports to send "ehlo mx.self-hosted.email" once the TLS handshake is complete, but all that comes back from the server is the timeout. So somehow that "ehlo mx.self-hosted.email" is never seen by your server, which is consistent with what your logs our showing. One slightly puzzling difference between what I see with either "posttls-finger", or my previously posted "s_client" test run, is that I see the server's EHLO response terminated with "250 XSHADOW", while the report from the sender's systems purports "250 SMTPUTF8". Why does the problem sender not also see XSHADOW[1] in the sender's response? If that means that their traffic is routed to a different system on your end, or is somehow proxied, ... then any observations from my perspective are not directly comparable to the problem sender's perspective. This does not look like an issue with path MTU, because the EHLO message is quite small. The actual SMTP software on the sender side (not openssl s_client) is unlikely to be using just LF line endings, it is surely sending CRLF, so I would expect any issues related to that. If the client's TLS stack were sending garbage, your TLS stack would generally detect malformed input and hang up. So at this point there's little to indicate why client's comparatively short EHLO never makes it to the server. Without a PCAP file captured on one or the other side, no substantive progress is likely. One might speculate, but there's little reason to take such speculation seriously. -- Viktor. 🇺🇦 Слава Україні! [1] Asking the Gemini AI what XSHADOW is, I get the response pasted below. If you’re seeing 250 XSHADOW in an SMTP conversation, you’ve likely stumbled upon a specialized extension used by Symantec Messaging Gateway (SMG) or certain Cisco security products. In the world of SMTP, any command starting with an "X" is a non-standard, vendor-specific extension. "XSHADOW" is specifically designed to handle Shadow Redundancy. What is Shadow Redundancy? Shadow Redundancy is a fail-safe mechanism designed to ensure that an email isn't lost if a server crashes mid-transmission or immediately after receiving a message but before it can be delivered to the next hop. Here is how the process generally works when XSHADOW is active: The Handshake: The receiving server advertises 250 XSHADOW during the EHLO greeting. The "Shadow" Command: The sending server (the client) issues an XSHADOW command during the session. Redundancy Negotiation: This tells the receiving server: "I am going to keep a copy of this email in my queue until you explicitly confirm that you have successfully handed it off to the next destination." The Safety Net: If the receiving server goes down before finishing the job, the sending server still has the "shadow" copy and will attempt to send it again (either to the same server when it recovers or to a backup). Why use it? Standard SMTP (RFC 5321) considers a message "delivered" the moment the receiving server sends a 250 OK after the data transfer. If that server’s hard drive fails one second later, that email is gone forever. XSHADOW extends that "responsibility" period until the message is safely further down the line. Common Environment You will almost exclusively see this in enterprise environments using: Broadcom/Symantec Messaging Gateway: It uses this to coordinate between scanners. Cisco Email Security Appliances (ESA): Often used in high-availability clusters. Note: If you are writing a custom SMTP client and see this, you can safely ignore it. Since it's a vendor-specific extension, standard clients aren't required to support it to successfully send mail. Would you like me to help you decode any other unusual SMTP status codes or headers you've encountered? _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
