Huge EWS traffic with Apple Mail after recent updates

souverain · 2026-06-04T15:09:40+00:00

Hello, I am seeing abnormal EWS behaviour with Apple Mail / ExchangeSync after recent package updates on my grommunio appliance. Context: Server: grommuni...

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.

souverain

Hello everyone, I just updated Gromox to version gromox-3.8.126.m2bf620a-lp160.50.1.x86_64

and the problem is gone.

I had submitted a ticket: https://github.com/grommunio/gromox/issues/268

and the ticket is now closed. So if you’re experiencing the same issue, please feel free to confirm whether it’s been fixed (or not) on your end.

Thanks in advance to the whole team!