An error was made please unsubscribe me. My side is fine. I was able to log on.
Respectfully, Alexandra Protopapas Enjoy your day! 💕💐🌸🌷🌼🌺🌞 On Mon, Jul 6, 2026 at 7:59 AM Christian Mack <[email protected]> wrote: > 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 Mack > > Am 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 > >
