other: Question lost connection after BDAT / DATA in postfix

[cloud-erik]

Subject

Something else that requires developers attention

Description

This is just a question, not a bug, but I know there are a lot of experienced people here and I was hoping someone might have a tip to solve the following problem I am facing:
I am currently using docker-mailserver release 13.3.1.

Since last week I have been getting connection loss errors for larger mails (mostly > 64kb).
lost connection after BDAT / DATA

has increased significantly from about 2% to over 65% of all connections. I have also received feedback from email senders about bouncing mails.
To my knowledge no hardware, software or configuration has been changed.

The problem is mainly related to Microsoft servers (*.outbound.protection.outlook.com), most other senders work fine, including e.g. gmail.
Small emails (mainly under 64kb) are delivered fine even from outlook.com. I have a few errors also for mails around 40kb, but most connection losses are exactly at 64kb (65536 bytes).

I have disabled Postfix BDAT support with
mtpd_discard_ehlo_keywords = chunking, silent-discard
but this just moved the issue from
lost connection after BDAT
to
lost connection after DATA

I changed MTU and MSS values of connection without any change

Issue persits for IPv4 as well as for IPv6

I checked and changes allowed TLS versions without any change
I use DMARC, SPF, DNSSEC. TLSA, DANE. checked certificates, Usuall checkes by e.g. mxtoolbor and Microsoft itself work fine without any issue. again smaller maisl are also delivered form outlook.com

I degugged docker-mailserver logs incl. armavis etc. without any insight. connection just gets lost. I switched of DNSBL, CLAMAV, FAIL2BAN, SPOOF_PROTECTION, POSTSCREEN, SPAMASSASSIN without change

I switched off IDS (snort) on the firewall and changed some configurations there without any change.

I upgraded and downgraded docker-mailserver to different versions without any changes.

Mailserver sits behind a HA proxy. I also double-checked and triple-checked all settings there and upgraded the HA proxy without any changes.

Upgrading the docker host also did not change anything.

Would be great if any of you have any idea of the root cause of the problem or how to narrow it down.

Erik

Update: I chacked from Admin console from a Exchange onlien account what error is created on sender side. an it is
Reason: [{LED=451 4.4.400 Error communicating with frontend host or destination host. -> 421 4.4.2 Connection dropped due to ConnectionReset};{MSG=};{FQDN=MYSERVERIP};{IP=MYSERVERIP};{LRT=4/21/2024 5:18:03 PM}]. OutboundProxyTargetIP: MYSERVERIP.

[glime-ai]

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

---

It seems like you've already conducted a thorough investigation into the issue with large emails being dropped when interacting with Microsoft servers. Given the specific nature of the problem (connection loss at exactly 64KB), this might suggest an issue related to network or protocol handling specific to how Microsoft's servers interact with your mail server configuration.

Here are a few additional steps you might consider to further diagnose or mitigate the issue:

1. Network Trace: If not already done, perform a network trace (using tools like Wireshark) to capture the traffic between your server and the Microsoft servers. Look specifically for any resets or unusual sequence of packets around the 64KB mark.

2. Contact Microsoft Support: Since the issue is predominantly with Microsoft servers, reaching out to Microsoft technical support might provide insights or known issues related to BDAT/DATA commands with their outbound protection services.

3. Test with a Simplified Setup: Temporarily configure a test environment with a minimal setup (bypassing HAProxy and any other intermediate network services) to see if the issue persists when connecting directly to the internet.

4. Review SMTP Conversation: Check the SMTP conversation logs in detail to see if there are any clues in the responses from Microsoft servers just before the connection drops.

5. Adjust Timeout Settings: Although it seems unrelated, adjusting the timeout settings for your SMTP connections might help if the issue is due to delayed responses from Microsoft servers.

6. Consult Docker-mailserver Community: Since this is a complex issue, consider posting a detailed question in the Docker-mailserver community discussions or forums. Other users might have faced similar issues or could offer new suggestions based on their experiences.

Given the complexity of the issue and the steps you've already taken, it might also be beneficial to consult with a network specialist who can offer a deeper analysis of the network traffic and potentially identify any anomalies that are not immediately obvious.

This comment was generated by Glime.

[github-actions]

This issue has become stale because it has been open for 20 days without activity.
This issue will be closed in 10 days automatically unless:

• a maintainer removes the meta/stale label or adds the stale-bot/ignore label
• new activity occurs, such as a new comment

[github-actions]

This issue was closed due to inactivity.