SOGo | BTS - Issues

0006229: Store server-side calendar iMIP/iTIP messages in organizer's Sent folder

Thu, 09 Jul 2026 10:22:53 +0000

When SOGo sends calendar invitation emails server-side via CalDAV/iMIP/iTIP scheduling, the messages are delivered correctly to attendees, but no copy is stored in the organizer's IMAP Sent folder.

This makes it difficult for users to track which calendar invitations, updates or cancellations were sent.

From a user's perspective, a calendar invitation sent on their behalf is still an outgoing message. Therefore, users expect these messages to appear in their Sent folder, just like normal sent emails.

Normal sent emails are stored correctly in the Sent folder. The configured Sent folder itself works as expected.

Expected behavior:

When SOGo sends calendar-related iMIP/iTIP messages on behalf of a user, SOGo should optionally append a copy of the generated message to the user's configured Sent folder.

The target folder should preferably use the existing setting:

SOGoSentFolderName

For example, if SOGoSentFolderName = Sent; is configured, server-side calendar invitation, update and cancellation messages should be stored in the user's Sent folder.

A possible configuration option could be:

SOGoStoreCalendarMessagesInSent = YES;

This should apply at least to:

- calendar invitations
- calendar updates
- calendar cancellations
- possibly attendee replies, if SOGo sends them on behalf of the user

0004704: Behaviour of sogo-tool and sogo-alarms-notify in version 3

Tue, 07 Jul 2026 11:58:30 +0000

Two tools are opening the root folder ("/") thousand times a day, just for reading and getting the attributes.

This is visible with AppArmor:

operation="getattr" profile="/usr/sbin/sogo-ealarms-notify" name="/" comm="sogo-ealarms-no" requested_mask="r" fsuid=126 ouid=0
operation="getattr" profile="/usr/sbin/sogo-tool" name="/" comm="sogo-tool" requested_mask="r" fsuid=126 ouid=0
operation="open" profile="/usr/sbin/sogo-tool" name="/" comm="sogo-tool" requested_mask="r" fsuid=126 ouid=0

I really wonder why those binaries are opening the root ("/") folder, even for reading and getting the attributes.

- What is the point of doing this?
- Is this a bug?
- Is this fixed in the version 4?

0006228: bug affecting SOGo's mail folder export feature (exportFolder) when the resulting export archive exceeds roughly 2 GiB

Tue, 07 Jul 2026 07:44:33 +0000

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 (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 0000015:0000002 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.

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, 0000018:0000019-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.

0006185: No more arm64 packages for Ubuntu 24.04 (noble)?

Mon, 06 Jul 2026 14:44:32 +0000

It was fine with apt repo for Ubuntu 24.04:
```
deb https://packagingv2.sogo.nu/sogo-nightly-ubuntu/ noble main
```

But`apt update` reports error yesterday:

> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://packagingv2.sogo.nu/sogo-nightly-ubuntu noble InRelease' doesn't support architecture 'arm64'

Questions:

- Did SOGo team remove the arm64 packages?
- Also, any plan to build packages for upcoming Ubuntu 26.04 (resolute)? It's scheduled to be released on April 27th.

0006082: Outlook EAS client always runs into Authnetication error after some time forcing user confirm login data

Fri, 03 Jul 2026 13:48:11 +0000

I setup SOGo using MySQL authentication:

SOGoUserSources = (
{
type = sql;
id = users;
viewURL = "mysql://xxx:yyy@127.0.0.1:3306/sogo/sogo_users";
canAuthenticate = YES;
isAddressBook = YES;
displayName = "Benutzer";
userPasswordAlgorithm = md5;
}
);

I added a bigger EAS account to various Outlook installations (also with different Outlook versions, it doesn't matter, occurs on all of them).
The Outlook Client authenticates fine and tries to sync EAS elements which also seems to work.
After a while, i.e. 10 Minutes, I get the following entry in sogo.log:

Feb 03 03:28:59 sogod [17012]: 192.168.2.51 "POST /SOGo/Microsoft-Server-ActiveSync?Cmd=Sync&User=xxx@yyy.at&DeviceId=C324A4AC32914C48A840393833BF65B6&DeviceType=WindowsOutlook15 HTTP/1.1" 200 13864846/4343 2.159 - - 18M - 13
Feb 03 03:29:01 sogod [17012]: <0x0x556df1ce6500[SOGoDAVAuthenticator]> tried wrong password for user 'xxx@yyy.at'!
Feb 03 03:29:01 sogod [17012]: 192.168.2.51 "POST /SOGo/Microsoft-Server-ActiveSync?Cmd=Sync&User=xxx@yyy.at&DeviceId=C324A4AC32914C48A840393833BF65B6
&DeviceType=WindowsOutlook15 HTTP/1.1" 401 12/4343 0.002 - - 0 - 14

The auth data is 100% correct. It causes users to be prompted with a login-popup.
It happens sporadically on multiple machines and is making users mad.
What can be done about it, how to diagnose the issue?

# grep "tried wrong password for" sogo.log
Feb 03 03:01:16 sogod [18531]: <0x0x556df6578170[SOGoDAVAuthenticator]> tried wrong password for user 'xxx@yyy.at'!
Feb 03 03:13:57 sogod [19843]: <0x0x556df147ecf0[SOGoDAVAuthenticator]> tried wrong password for user 'xxx@yyy.at'!
Feb 03 03:29:01 sogod [17012]: <0x0x556df1ce6500[SOGoDAVAuthenticator]> tried wrong password for user 'xxx@yyy.at'!

0006112: Automatically add external meeting invitations to calendar

Fri, 03 Jul 2026 10:58:06 +0000

Dear SOGo team,

We are actively using SOGo Groupware in our organization and find it very efficient and user-friendly.

Currently, when a user receives a meeting invitation from another user within the same SOGo server, the invitation is automatically added to the user's calendar — even before it is accepted. This is a very useful feature that simplifies scheduling.

However, when a user receives a calendar invitation from an external sender (e.g. Google, Outlook, or any CalDAV-compatible system), the event is not automatically added to the calendar. Users have to manually accept and create the event, which increases the risk of missed meetings and extra manual work.

**Feature Request:**
Please consider implementing a feature that will allow automatic processing of external meeting invitations in the same way as internal ones — showing them in the calendar right away as pending or tentative events.

This functionality would significantly improve interoperability with other systems and streamline the user experience.

It would be great if this behavior could be made configurable per user or domain.

Thank you very much for your time and great work!

Best regards,
Anton Sapanovskiy
Bug Tracker Username: sapanovskiy

0006067: User option to automatically add external invitations to personal agenda

Fri, 03 Jul 2026 10:58:06 +0000

Is there a way to add this, when invitations come from outside SOGo-managed domains, like Gmail does ?

It seems not possible to do this if a user is not connected on webmail, because it needs an active IMAP connexion.
But it would be nice to activate this as soon as a user reads an email where SOGo detects invitations, instead of relying on user interaction (buttons Accept / Decline / etc.).

Is it already on a roadmap ?

0006227: Broken encoding of display names containing a comma and square brackets

Thu, 02 Jul 2026 06:32:03 +0000

We have many users who use the format

, [department]

as their sender name (preferences: "Full Name").

SOGo does not quote the "display name" [see RFC 5322: https://www.rfc-editor.org/info/rfc5322/#section-3.4] (which is probably correct because it's not required here, I guess) when sending new messages or responding to messages with such a sender name. Instead it uses the "Q encoding" as transfer-encoding [see RFC 2047: https://www.rfc-editor.org/info/rfc2047/#section-4.2].

When encoding the display name the comma is interpreted as separator of multiple addresses and since the part before the comma is not a valid email address, "@MISSING_DOMAIN" is appended here to mark the "address".

The same display error occurs when the message was sent from a different mail client which does not quote the display name.
It does not occur (in the first place) when the display name is quoted (as e.g. Thunderbird does). But it does in replies to such messages: the recipient of the reply works when sending the message, but it's wrongly displayed when opening the reply in SOGo.

0006214: Signature duplicated when switching identity in compose (regression from #5695 fix)

Wed, 01 Jul 2026 07:56:35 +0000

When a user switches the From address in the compose window (e.g. from their personal address to a shared/public mailbox), the signature is not removed and a second copy is appended.

SOGo version: 5.12.8 (nightly 20260518-1)
Compose mode: Plain text (SOGoMailComposeMessageType = text), also reproducible in HTML mode
Browser: Firefox (latest)

Setup:
- User has a personal identity with a multi-line signature (name, address, phone, URLs)
- User has access to shared/public mailboxes with no signature defined
- SOGoMailSignaturePlacement = above
- SOGoMailAuxiliaryUserAccountsEnabled = NO

0006118: Build packages for CentOS Stream 10?

Thu, 25 Jun 2026 08:54:05 +0000

Dear all,

CentOS Stream 10 was released in Dec 2024, any plan to build packages for it?

0006226: Wehn password recovery is not enabled, the login page returns 403 for the url "/SOGo/so/passwordRecoveryEnabled"

Tue, 23 Jun 2026 08:45:50 +0000

This is not optimal, as some servers are using 403 code to trigger IP address ban.
I suggest to use 204 instead, meaning "no content"

0006224: Attachment is lost when attempting to send an email to a non-existent address

Mon, 22 Jun 2026 10:44:23 +0000

When attempting to send an email with an attachment to a non-existent address, SOGo saves a draft and returns an HTTP 405 error.
If the non-existent address is then replaced with a valid one, SOGo sends the email, but the attachment is missing. Notably, the attachment remains present within the saved draft.

0006225: Client IP address not sent to the IMAP server

Sun, 21 Jun 2026 11:57:10 +0000

SOGo is sending the ID x-originating-ip after the authentication, instead of sending it before.
As a result, the real client IP is never used by Dovecot (or any other mail server)

This was supposed to be implemented in https://bugs.sogo.nu/view.php?id=2366, but fails.

0006209: HTML ckeditor content truncated on forward if header reference

Thu, 18 Jun 2026 07:06:51 +0000

It seams that a forward on a mail wich is already a response (to list?) truncate html from previous content.

If we edit HTML directly in source, content is ok. It seems to be related to ckeditor.

No probl with reply on the same mail.

0006196: Sorting of subscriptions in calendar changes unintendendedly during the day

Wed, 17 Jun 2026 07:19:27 +0000

I have several calendars subscribed to and manually sorted in a meaningful way. During the day Sogo reorders these sunscriptions in an unexpected way.
I can reset the order which switches to an aphabetical order.

0006220: Search for subject leads to wrong highlighting

Sun, 14 Jun 2026 12:07:04 +0000

Searching for a substring of a subject line doesn't highlight the matched substring. Instead the substring ist displayed as
SUBSTRING

0006210: High latency between Nginx and SOGo under concurrent load / Delayed response delivery

Fri, 05 Jun 2026 10:56:29 +0000

We are experiencing intermittent, severe delays when loading the message list in the SOGo web interface.
To diagnose this, we configured extended logging in Nginx.
The metrics reveal a significant discrepancy between the time Nginx spends waiting for the backend and the actual processing time reported by SOGo.

Log Analysis Example:
Nginx Log:
email.xxx.xx - xx.xx.xx.26 - - [14/May/2026:17:00:17 +0300] "POST /SOGo/so/otgruzka@xxx.xx/Mail/0/folderINBOX/changes HTTP/2.0" 200 27 "https://email.hoster.by/SOGo/so/otgruzka@xxx.xx/Mail/view" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36" 2.149 uсt=0.000 uht=2.144 urt=2.144
SOGo Log:
May 14 17:00:17 sogod [3636941]: xx.xx.xx.26 "POST /SOGo/so/otgruzka@xxx.xx/Mail/0/folderINBOX/changes HTTP/1.0" 200 27/152 0.182 - - 0 - 17

As shown above, SOGo processed the request in 0.182 seconds, but Nginx recorded an upstream response time (uht/urt) of 2.144 seconds.
This leaves an unaccounted-backlog delay of 1.962 seconds (2.144 - 0.182).
In worst-case scenarios, the browser waits for a response for up to 30 seconds.

Questions:
Where is the request spending the remaining 0000015:0000002 seconds before or after SOGo processes it?
Could this indicate that requests are getting queued in WOListenQueueSize before hitting a worker, or is it an issue with response buffering in SOGo?
What adjustments or optimizations can we implement to resolve this latency bottleneck?

0005830: In Thunderbird + SOGo Caldav calendar, recurring event schedule is not updated as expected

Mon, 01 Jun 2026 17:15:13 +0000

In Thunderbird, when updating the schedule of all occurrences of a recurring event (that already has a schedule exception on a single occurrence), the event is not updated for the attendees in the SOGo Calendar.

As a result, the resource calendar is displaying wrong or conflicting information.

0006085: Details of an event are not correct reset/modified when copying this event (causes invitations that cannot be accepted)

Mon, 01 Jun 2026 12:23:10 +0000

When events are copied by the three dot menu in same or other calendar only the UID is changed (CORRECT BEHAVIOUR) but other details of the event like CREATED, LAST-MODIFIED and SEQUENCE (if changed before) are not set in same manner like new event. This prevents the participants from accepting the copied event in some clients as well the creator to insert / update the notifications. Other malfunctions cannot be ruled out.
Please read the reproduction steps to follow in order to eliminate the certainly minor error.

So please, whenever coping an event in SoGo Webmail:
- Create new UID (already working)
- Set SEQUENCE to 0 or remove (not working in 5.11.2)
- Set CREATED to copy time like in new created events (not working in 5.11.2)
- Set LAST-MODIFIED to CREATED like in new created events (not working in 5.11.2)

Maybe the proposal 0005820 can be solved too, when working on this bug.

Thanks a lot.

0006221: OIDC Backchannel logout URI

Sat, 30 May 2026 13:12:43 +0000

Does SOGo support a OIDC backchannel logout URI so that logging out of the OTPme SSO Portal (https://github.com/the2nd/otpme) also logges out the SOGo session?

0006223: Tag is automatically removed when opening an email in a new window

Thu, 28 May 2026 18:58:36 +0000

An existing tag is automatically removed from an email when the email is opened in a new window.
SOGo log output:
May 28 17:58:10 sogod [556178]: |SOGo| starting method 'GET' on uri '/SOGo/so/ks@xxx.dev/Mail/0/folderINBOX/29246/view'
May 28 17:58:10 sogod [556178]: |SOGo| request took 0.029016 seconds to execute
May 28 17:58:10 sogod [556178]: 0.0.0.0 "GET /SOGo/so/ks@xxx.dev/Mail/0/folderINBOX/29246/view HTTP/1.0" 200 741/0 0.031 - - 0 - 14
May 28 17:58:18 sogod [556178]: |SOGo| starting method 'GET' on uri '/SOGo/so/ks@xxx.dev/Mail//UIxMailPopupView'
May 28 17:58:18 sogod [556178]: |SOGo| request took 0.069524 seconds to execute
May 28 17:58:18 sogod [556178]: 0.0.0.0 "GET /SOGo/so/ks@xxx.dev/Mail//UIxMailPopupView HTTP/1.0" 200 17761/0 0.076 72026 75% 0 - 14
May 28 17:58:19 sogod [556178]: |SOGo| starting method 'POST' on uri '/SOGo/so/ks@xxx.dev/Mail/0/folderINBOX/addOrRemoveLabel'
May 28 17:58:19 sogod [556178]: |SOGo| request took 0.015807 seconds to execute
May 28 17:58:19 sogod [556178]: 0.0.0.0 "POST /SOGo/so/ks@xxx.dev/Mail/0/folderINBOX/addOrRemoveLabel HTTP/1.0" 204 0/58 0.018 - - 0 - 14

0006222: Cyrillic tags cannot be added

Thu, 28 May 2026 14:38:11 +0000

An HTTP 501 error occurs when attempting to attach a Cyrillic tag to an email:
May 28 17:23:17 sogod [556179]: |SOGo| starting method 'POST' on uri '/SOGo/so/ks@xxx.dev/Mail/0/folderINBOX/addOrRemoveLabel'
2026-05-28 17:23:17.398 sogod[556179:556179] EXCEPTION: NAME:NSInvalidArgumentException REASON:[NGMutableHashMap-jsonRepresentation]
should be overridden by subclass INFO:(null)
May 28 17:23:17 sogod [556179]: |SOGo| request took 0.034584 seconds to execute
May 28 17:23:17 sogod [556179]: 0.0.0.0 "POST /SOGo/so/ks@xxx.dev/Mail/0/folderINBOX/addOrRemoveLabel HTTP/1.0" 501 0/56 0.036 - - 0 - 14

0005992: Repeating events are not shown in Webmail BEFORE importing into calendar

Thu, 28 May 2026 09:31:37 +0000

If you get an invite for an repeating event from a companies e-mail sent by Microsoft Outlook via Exchange the preview by SoGo shows only the first occurence of the meeting but neither that's a repeating event nor the other and last occurences.
This is very annoying as the user will crosscheck with first occurence, agrees to one meeting and will learn that he accepted unintentionally a whole bunch of meetings.

A (blurred) screenshot is attached as well an excerpt of the ics file:

RRULE:FREQ=WEEKLY;UNTIL=20241119T120000Z;INTERVAL=2;BYDAY=TU;WKST=MO
DTSTART;TZID=W. Europe Standard Time:20240730T130000
DTEND;TZID=W. Europe Standard Time:20240730T140000
CLASS:PUBLIC
PRIORITY:1
DTSTAMP:20240722T114355Z
LOCATION;LANGUAGE=de-DE:Microsoft Teams-Besprechung

Currently we are looking into the *.ics file manually before accepting an event from people who want to invite us.
As this is a very hard workaround we would favour if this clould be fixed soon. Thank you very much!

The Bahnkonzept team from Dresden/Germany

0005939: Recurring event invites not shown in mail invites

Thu, 28 May 2026 09:31:37 +0000

Dear SoGo-Team,

The information that an invite is a recurring appointment is not displayed in the invitation e-mail, but is imported and displayed in the calendar afterwards. The information is available in the message source but not shown in the UI. This may lead to accepting an recurring event under the circumstance that it may understood as one-time event.

example: RRULE:FREQ=DAILY

Current state: The appointment invitation is not displayed in the emails whether the appointment is repeated
Desired state: The appointment invitation is displaed in the emails with the following information:
* first occurrence
* appointment will be repeated
* last occurrence
* frequency

The Bahnkonzept team from Dresden/Germany

0006154: TOTP secret is not changed after disabling --> reenabling

Thu, 28 May 2026 06:46:34 +0000

The TOTP secret is not deleted by disabling 2FA in webinterface PReferences.
Therefore you can not change your secret at all.