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.26: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.26:25,194.42.96.40:59854,<,EHLO
> mail.example.com,
> 2026-02-25T09:20:21.839Z,edge01\Internet,08DE6A521B0E8C30,3,172.25.0.26: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.26:25,194.42.96.40:59854,<,STARTTLS,
> 2026-02-25T09:20:21.870Z,edge01\Internet,08DE6A521B0E8C30,5,172.25.0.26: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.26: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
