Hello Please open a bug report at https://sogo.nu/bugs
As currently development of SOGo 6 is prioritised, this will probably not get a fix in the near future.
With a bug report, it will not get lost. Kind regards, Christian MackAm 06.07.26 um 12:14 schrieb "Nathan Fowler (X-Net)" ([email protected]):
Hello,
I'd like to report a bug affecting SOGo's mail folder export feature
(exportFolder) when the resulting export archive exceeds roughly 2 GiB.
Environment:
- SOGo version: 5.12.8
- Installation: mailcow-dockerized, mailcow version 2026-05c
- Reverse proxy: nginx (bundled with mailcow)
- IMAP backend: Dovecot (bundled with mailcow)
Summary:
When a user attempts to export a mail folder via the web UI ("Export" on a
mailbox/folder) where the resulting archive is roughly 14-16 GiB in size, the export fails after
approximately 19-20 minutes. The browser is redirected back to the inbox with a generic "nginx
cannot connect to upstream" error page.
Root cause (as best I can determine):
The nginx access/error logs show SOGo returning an invalid, negative
Content-Length header once the export completes:
nginx-mailcow-1 | 2026/07/01 16:27:11 [error] 18#18: *476769 upstream sent invalid "Content-Length" header:
"Content-Length: -1778931325" while reading response header from upstream, client: [redacted], server:
[redacted], request: "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/2.0", upstream:
"http://[redacted]:20000/SOGo/so/[user]/Mail/0/folderINBOX/exportFolder";
nginx-mailcow-1 | [redacted] - - [01/Jul/2026:16:27:11 +0100] "GET
/SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/2.0" 502 2015 ...
sogo-mailcow-1 | Jul 1 16:27:11 [container] sogod [99]: [ERROR]
<0x...[WOHttpTransaction]> client disconnected during delivery of response for
<WORequest...> (len=0): the socket was shutdown
sogo-mailcow-1 | Jul 1 16:27:11 [container] sogod [99]: [redacted] "GET
/SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/1.1" 200 0/0 1253.452 - - 103M
- 15
The reported Content-Length value (-1778931325) is consistent with a 32-bit
signed integer overflow: adding 2^32 to that value yields approximately 2.34
GiB, which strongly suggests the export archive's byte size is being
stored/reported in a 32-bit signed integer field, wrapping to a negative value
once the true size exceeds ~2 GiB (2,147,483,647 bytes). nginx correctly
rejects the resulting header as invalid, which surfaces to the end user as a
generic 502/connection failure with no indication of the true cause.
Steps to reproduce:
1. Have a mailbox/folder whose export archive will exceed ~2 GiB (in our case,
roughly 14.5 GiB source mailbox).
2. In the SOGo web UI, trigger "Export" on that folder.
3. Wait for the export to build server-side (in our case ~19-20 minutes).
4. Observe the request fail; nginx logs show the invalid negative
Content-Length shown above; sogod logs show the client socket being shut down
at the same timestamp.
Expected behavior:
The export should either complete successfully regardless of size, or SOGo
should stream/chunk the response (e.g., via chunked transfer encoding) rather
than relying on a Content-Length value that appears to be limited to a 32-bit
signed range.
Additional notes:
- We ruled out request timeouts (WOWatchDogRequestTimeout was raised from the
default and the failure still occurred at the same point, ~19-20 minutes in,
consistent with export size rather than time elapsed).
- We ruled out memory exhaustion (SxVMemLimit raised; no OOM kills observed via
docker stats/dmesg during the failed export).
- nginx's own proxy/read timeouts are already set to 3600s in our
configuration, ruling out nginx-side timeout as the cause.
Happy to provide further logs, a full sogo.conf, or test against a patched
build if that would help narrow this down further. Please let me know if
there's any additional diagnostic information I can supply.
Thank you for your time and for maintaining SOGo.
Regards,
Nathan Fowler
-- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416
smime.p7s
Description: Kryptografische S/MIME-Signatur
