Environment
- Gromox:
gromox-3.8.27.m47a2746-lp160.12.1.x86_64
- Client: Apple
exchangesyncd
- User-Agent:
AppleExchangeWebServices/835 ExchangeSync/2007
- EWS endpoint:
/EWS/Exchange.asmx
- Reverse proxy between the client and Gromox
Problem
Apple exchangesyncd generates abnormally large downloads through EWS.
The mailbox itself is small, but individual EWS POST requests return several gigabytes of data.
Examples observed in the reverse proxy access log:
POST /EWS/Exchange.asmx HTTP/2.0 200 5975913876
POST /EWS/Exchange.asmx HTTP/2.0 200 9175404170
POST /EWS/Exchange.asmx HTTP/2.0 200 13240686462
POST /EWS/Exchange.asmx HTTP/2.0 200 1271036084
The traffic stops immediately when exchangesyncd is killed on the Mac.
macOS then automatically restarts exchangesyncd, after which the traffic can start again.
macOS network evidence
One failing request was recorded by CFNetwork with:
request_bytes=707
response_bytes=5983104688
transaction_duration_ms=364370
response_status=200
The same connection reported:
bytes in/out: 5999648541/428241
Duration: 364.500s
Immediately after the failure, Apple logged:
EXSEWSProtocolSubscription
Stopping EWS subscription
The connection ended with:
received H2 RST_STREAM with error code: 2
HTTP load failed
NSURLErrorDomain Code=-1005
Gromox EWS logging
Temporary EWS request logging was enabled.
The Apple client performs the following sequence:
Subscribe
GetStreamingEvents
Example:
[ews#5] Processing Subscribe
[ews#5] Done, code 200, 860 bytes
[ews#11] Processing GetStreamingEvents
The request is:
<m:GetStreamingEvents>
<m:SubscriptionIds>
<t:SubscriptionId>AQAAAAUAAAA=</t:SubscriptionId>
</m:SubscriptionIds>
<m:ConnectionTimeout>30</m:ConnectionTimeout>
</m:GetStreamingEvents>
Multiple streaming subscriptions were subsequently observed:
ews#11 AQAAAAUAAAA=
ews#51 AgAAAAUAAAA=
ews#53 AQAAAAUAAAA=
ews#87 AwAAAAUAAAA=
ews#108 BAAAAUAAAA=
ews#124 BQAAAAUAAAA=
ews#138 BgAAAAUAAAA=
The same SubscriptionId AQAAAAUAAAA= was observed in both ews#11 and ews#53.
Controlled A/B test
A controlled EWS test was performed:
- Subscribe
- GetStreamingEvents for 8 seconds
- Unsubscribe
Results:
Direct connection to Gromox:
933 bytes in 8 seconds
Through the reverse proxy:
933 bytes in 8 seconds
Therefore, a fresh streaming subscription behaves normally in both paths.
The issue appears to depend on the state or subscription sequence created by Apple exchangesyncd.
Backend network measurement
During the real Apple client issue, traffic was measured directly on the Gromox server between the backend and the reverse proxy.
First measurement:
192.168.1.5 → 192.168.1.120
160.50 MiB in 10 seconds
134.64 Mbit/s
A second measurement restricted specifically to HTTPS traffic from the Gromox server:
192.168.1.5:443 → 192.168.1.120
447.57 MiB in 10 seconds
375.45 Mbit/s
This confirms that the massive traffic already leaves the Gromox server before reaching the reverse proxy.
The reverse proxy is therefore not generating or amplifying the large response.
Expected behavior
GetStreamingEvents should return normal EWS notification data and should not continuously send gigabytes of data for a small mailbox.
Actual behavior
Under the subscription state created by Apple exchangesyncd, EWS streaming connections can produce multi-gigabyte responses and sustained traffic ranging from approximately 135 Mbit/s to more than 375 Mbit/s.
Fresh subscriptions created manually with curl do not reproduce the issue.
Questions
- Can GetStreamingEvents repeatedly serialize or resend the same event backlog under some subscription state?
- Is the streaming event backlog limit expected to apply to this case?
- Could multiple or reused SubscriptionIds created by Apple exchangesyncd trigger this behavior?
- Is there additional server-side tracing that would identify which events are repeatedly returned without logging the complete multi-gigabyte response body?
