Huge EWS traffic with Apple Mail after recent updates

souverain

Hello,

I am seeing abnormal EWS behaviour with Apple Mail / ExchangeSync after recent package updates on my grommunio appliance.

Context:

Server: grommunio appliance
Hostname: <mail.example.tld>
OS: grommunio 2025.01.2 / openSUSE Leap 15.6
The grommunio server is behind a reverse proxy.
Reverse proxy hostname: <reverse-proxy.example.tld>
Client: Apple Mail / AppleExchangeWebServices on macOS
Affected endpoint: /EWS/Exchange.asmx
Affected user: user@example.tld

Since 2026-06-04, the reverse proxy logs show repeated huge HTTP 200 responses from EWS to Apple Mail. These transfers are not isolated: they repeat roughly every 30–35 minutes.

Examples from the reverse proxy Nginx access log:

43.19 GiB [04/Jun/2026:08:26:52 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
24.47 GiB [04/Jun/2026:08:48:57 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
42.44 GiB [04/Jun/2026:09:25:29 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
38.79 GiB [04/Jun/2026:09:59:48 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
41.54 GiB [04/Jun/2026:10:34:07 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
40.94 GiB [04/Jun/2026:11:08:26 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
39.71 GiB [04/Jun/2026:11:46:57 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
38.07 GiB [04/Jun/2026:12:21:16 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
44.20 GiB [04/Jun/2026:12:55:35 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
47.35 GiB [04/Jun/2026:13:29:53 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
48.00 GiB [04/Jun/2026:14:04:12 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
48.28 GiB [04/Jun/2026:14:38:31 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
45.13 GiB [04/Jun/2026:15:12:50 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
41.89 GiB [04/Jun/2026:15:47:09 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
41.57 GiB [04/Jun/2026:16:21:28 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
42.69 GiB [04/Jun/2026:16:55:47 +0200] client=<client_public_ip> user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"

The issue was also visible in bandwidth monitoring, with around 25–27 MiB/s of sustained traffic during active transfers.

A live connection capture during the issue showed the expected path:

Apple Mail client / public IP -> reverse proxy -> grommunio backend

More precisely:

<reverse_proxy_lan_ip>:443 -> <client_public_ip>
<reverse_proxy_lan_ip>:<port> -> <grommunio_backend_lan_ip>:443

Recent package update history:

2026-06-02 12:29:05 | zypper up -y
2026-06-02 12:29:07 | install | grommunio-web | 3.18.4.g141cd2733-lp156.480.1

Current relevant package versions:

grommunio-admin-api-1.19.9.mdf74f35-lp156.4.1.noarch
grommunio-dav-1.6.24.84942ef-lp156.1.1.noarch
grommunio-sync-2.4.8.483c521-lp156.23.1.noarch
grommunio-web-3.18.7.gec5085ffd-lp156.481.1.noarch
gromox-3.7.256.me40a504-lp156.46.1.x86_64
mapi-header-php-2.1.22.762be6f-lp156.10.1.noarch
nginx-1.21.5-150600.10.12.1.x86_64
php8-8.2.30-150600.3.25.1.x86_64
postfix-3.8.4-150600.3.3.1.x86_64

I also checked the journal on the grommunio server around the problematic time range. I did not find explicit EWS / gromox-http / exmdb errors matching the huge transfers. The journal mainly shows regular grommunio-index runs and unrelated Postfix SMTP noise.

Questions:

Could this be a known EWS / Apple Mail / ExchangeSync issue with the current gromox or mapi-header-php versions?
Is there a way to identify which mailbox item, folder, attachment, or sync state is causing such huge repeated EWS responses?
Which logs or debug options would you recommend enabling to capture the EWS request details without exposing mailbox content?
Would resetting the EWS sync state for this Apple Mail client be recommended, and if so, what is the correct procedure on grommunio/gromox?

Thanks for your help.

Mister2

souverain
This seems very similar to my ticket on 1/6/26 'Out of Memory error after installing today's updates'. On my appliance the large amount of traffic eventually leads to an 'Out Of Memory' kill triggering on Nginx.
I have rolled back to a snapshot before the updates I installed on the 1/6/26 (see above referenced ticket). The system is stable on these settings. My gut feeling the issue ois with the 'crypto-policies 20250714.cd6043a-160000.2.1' update, but I can't prove it.
Yesterday I built a new clean appliance and upgraded it to OS 16.0 plus latest updates. As soon as I migrated my data back to it, exactly the same issue of persistent OOM kills on Nginx started again. I tried deleting my users and recreated them, then re-imported the mailbox via PST. I have also deleted my Mac OS Mailboxes/profiles and recreated those as well. Ran out of time to test if this helps, but I suspect not.
I am going to wait a few days and test with updates then to see if the devs have picked up the issue and fixed it. Fortunately, this is only a home mailserver.

souverain

Additional finding: on the macOS client, the traffic stops immediately when the exchangesyncd process is suspended with sudo pkill -STOP -x exchangesyncd. After that, outbound traffic on the reverse proxy drops to 0 MiB over 10 seconds. This confirms that the huge EWS traffic is triggered by macOS ExchangeSync in the background, even when Apple Mail is not visibly open.

Mister2

souverain I confer with this. Yesterday I also found that if I closed Mac OS Mail app on the Mac the OOM kills stopped and the CPU trace in the Admin UI went back to virtually 0% within a few secs. I then monitored it for over 20mins and not a single blip on the trace. I then opened the Mac OS Mail client and the OOM kills started within a couple of minutes.

This was what led me to delete the Mac Mail profiles that connect to this server and recreate then. But I haven't applied the updates on my live server at this time to test if the mac Mail profiles had become corrupts because of the EWS issues experienced since the updates of 25/5/26. I also issued a full resync of iPhone profiles even though these do not appear to have been affected. My server with updates prior to 1/6/26 is currently running without issue at the moment (I will clone it and test current updates over the next few days to see if this issues gets resolved).

souverain

Process state after suspension:

PID STAT COMMAND
5567 T /System/Library/PrivateFrameworks/ExchangeSync.framework/Versions/Current/exchangesyncd

souverain

Additional update after latest packages:

The issue still occurs after installing the following latest packages:

grommunio-admin-api-1.19.11.mc7e4cbd-lp156.5.1.noarch
grommunio-antispam-4.0.1-lp156.5.1.x86_64
gromox-3.7.256.me40a504-lp156.47.1.x86_64
gromox-debugsource-3.7.256.me40a504-lp156.47.1.x86_64
grommunio-web-3.18.7.gec5085ffd-lp156.481.2.noarch
gromox-debuginfo-3.7.256.me40a504-lp156.47.1.x86_64

After resuming macOS exchangesyncd, the reverse proxy traffic immediately rose again:

Reception: 157 MiB / 10s
Upload: 281 MiB / 10s

After suspending exchangesyncd again with:

sudo pkill -STOP -x exchangesyncd

the reverse proxy traffic immediately dropped to:

Reception: 0 MiB / 10s
Upload: 0 MiB / 10s

This confirms that the issue is still reproducible after the latest updates and that the massive EWS traffic is directly triggered by macOS exchangesyncd.

EureGraueKompetenz

I also can confirm this.

Updated yesterday in the late evening and from that on the server has gone out of memory every 30 Minutes.
This morning i forced the users who were running apple mail with grommunio to delete their accounts.
The server is stable since then.

Thanks @Mister2 & @souverain you guys saved my weekend!

souverain

EureGraueKompetenz You asked for their account to be deleted, but were they able to reactivate it, or is this just a temporary measure until a fix is available and you can tell them they can reactivate their account?

EureGraueKompetenz

souverain
this is just a temporary measure. I wont ask them to readd their accounts until monday.

souverain

EureGraueKompetenz Thanks for your feedback!

souverain

Update: I also tested with the newer packages:

gromox-3.7.256.me40a504-lp156.48.1
gromox-debugsource-3.7.256.me40a504-lp156.48.1
grommunio-web-3.18.7.gec5085ffd-lp156.481.3
gromox-debuginfo-3.7.256.me40a504-lp156.48.1

Unfortunately, the issue still persists.

When I resume macOS exchangesyncd with:

sudo pkill -CONT -x exchangesyncd

the reverse proxy bandwidth rises again.

When I suspend it again with:

sudo pkill -STOP -x exchangesyncd

the bandwidth immediately drops back down.

So the issue is still reproducible with gromox .48.1 and grommunio-web .481.3.

WalterH

Try the package from devel. repo: https://download.grommunio.com/devel/openSUSE_Leap_15.6/gromox-3.7.282.x2898dfa-lp156.27.1.x86_64.rpm

souverain

WalterH I tested the devel package gromox-3.7.282.x2898dfa-lp156.27.1.

Unfortunately, the issue still occurs.

With iftop on the reverse proxy, I can clearly see heavy traffic between the reverse proxy and the grommunio backend on 192.168.x.x:443, and then from the reverse proxy to the Apple/EWS client.

The traffic rises to around 200 Mb/s when macOS exchangesyncd is active.

When I suspend exchangesyncd with:

sudo pkill -STOP -x exchangesyncd

the traffic immediately drops back down.

So the issue is still reproducible with gromox-3.7.282.x2898dfa-lp156.27.1.

WalterH

In /etc/gromox/http.cfg, try to set these parameter:

# EWS attachments are base64 encoded, rise attachment size up to 66MB.
http_rqbody_max_size=100M

Restart gromox-http. No idea if it helps.

souverain

WalterH I tested both suggestions:

I installed the devel package: gromox-3.7.282.x2898dfa-lp156.27.1
added the following parameter in /etc/gromox/http.cfg:
http_rqbody_max_size=100M

Then I restarted gromox-http.

Unfortunately, the issue still occurs.

After resuming macOS exchangesyncd and opening Apple Mail, the reverse proxy still logs large EWS responses:
2.67 GiB [06/Jun/2026:10:08:57 +0200] user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
2.85 GiB [06/Jun/2026:15:34:39 +0200] user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
2.79 GiB [06/Jun/2026:15:40:50 +0200] user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 Mail/3826.700.81.1.8"
20.76 GiB [06/Jun/2026:15:56:39 +0200] user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"
3.93 GiB [06/Jun/2026:16:15:15 +0200] user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 Mail/3826.700.81.1.8"
4.82 GiB [06/Jun/2026:16:16:58 +0200] user=user@example.tld status=200 user-agent="AppleExchangeWebServices/835 ExchangeSync/2007"

The traffic still drops when I suspend macOS exchangesyncd:

sudo pkill -STOP -x exchangesyncd

So the issue is still reproducible with gromox-3.7.282.x2898dfa-lp156.27.1 and http_rqbody_max_size=100M.

It may have changed the size/frequency of the transfers, but the abnormal EWS bandwidth usage is still present.

souverain

For practical reasons, I have reverted my setup to the previous stable configuration.

I removed the test parameter from "/etc/gromox/http.cf"` and restored the previous configuration file. I also downgraded from the devel package back to the stable repository package:
gromox-3.7.256.me40a504-lp156.48.1

Current relevant versions are now:
gromox-3.7.256.me40a504-lp156.48.1.x86_64
grommunio-web-3.18.7.gec5085ffd-lp156.481.3.noarch
mapi-header-php-2.1.22.762be6f-lp156.10.1.noarch

The "http_rqbody_max_size" parameter is no longer present in http.cfg.

I will keep "exchangesyncd" suspended on the macOS client for now to avoid the bandwidth issue while waiting for further guidance.

Duese6

I can confirm the same behavior.

I had been running version 3.7.256.me40a504-lp160.46.1 for a few days, which had resolved the Outlook issues.
However, today the first user reported problems with Apple Mail: as soon as Apple Mail is opened, the server continues running for about 10 minutes and then crashes.
The system is a VM with 48 GB RAM and 8 vCPUs.

I’ve now rolled back to gromox-3.7.130.m30144a6-lp160.23.1. The rest of the system is up to date.

Outlook on macOS — which also uses EWS — has actually been broken since the end of March (see: https://github.com/grommunio/gromox/issues/231) and is still crashing as well.

Unfortunately, my workaround had been to switch to Apple Mail instead of Outlook, which now ends up taking down the server within minutes.