SOGo | BTS - Issues

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

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

Thu, 28 May 2026 11:11:32 +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?

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.

0006217: Serve web-created contact lists over CardDAV as standard group vCards instead of the proprietary VLIST format

Thu, 28 May 2026 06:25:19 +0000

When a contact list is created in the SOGo web interface, SOGo stores and
serves it over CardDAV as a proprietary "BEGIN:VLIST … END:VLIST" object.
This is not a vCard and is not valid CardDAV address-data per RFC 6352, so
standards-compliant CardDAV clients cannot consume it: the resource is
silently dropped during sync and the list is invisible in the client.

This is a feature request to serialize web-created lists as a standard
group vCard — Apple's X-ADDRESSBOOKSERVER-KIND:group +
X-ADDRESSBOOKSERVER-MEMBER (optionally vCard 4 KIND:group / MEMBER) — when
serving them over CardDAV.

The fix is well-scoped: SOGo's CardDAV layer already handles group vCards
correctly. PUTting an X-ADDRESSBOOKSERVER-KIND:group vCard returns 201, and
a subsequent GET / addressbook-query REPORT returns it verbatim. The gap is
only that lists created in SOGo's own web UI are stored in the legacy VLIST
format and served as-is, with no VLIST->vCard conversion on output
(class SOGoContactGCSList).

0001205: update the vcard handling to VCARD 4 spec

Thu, 28 May 2026 06:25:19 +0000

The new spec is currently in revision stage:
http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev

Once completed, we should update our implementation.

0006202: Adding participant to calendar invite received from external user causes invite to be sent using their email address as sender

Wed, 27 May 2026 10:08:04 +0000

(I'm a mailcow user, so I'm using SOGo as part of that install. I assume that this doesn't change anything with regards to this bug report, though.)

I had a meeting in my calendar that was put in my calendar by receiving an invite from a @gmail.com address. I extended that invite by editing the calendar entry in Thunderbird and adding the additional participant's email address. mailcow created a new invite and sent it to the additional participant, using the @gmail.com email address of the original sender (the organizer of the meeting).

This sender address was used both in the message header (From: header) as well as in the envelope of the email message (Return-Path: header).

This is super dangerous to your mail server's reputation, because your mail server sends from an ip address that is not authorized by the original domain's SPF record (gmail.com in this case), nor is the message DKIM-signed. This is typical "spamming" behavior and can cause your mail server's reputation to degrade, with the consequence that you might suffer from future issues sending "legitimate" email to external recipients.

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

Wed, 27 May 2026 08:02:31 +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.

0006143: Data Loss When Exporting Contacts with Multiple Phone Numbers

Wed, 27 May 2026 07:57:35 +0000

When exporting contacts from the address book, not all phone numbers are included if a contact contains multiple numbers of the same type (e.g., two "Work" phone numbers). Only the first number is exported, while all subsequent numbers of the same type are lost.

Expected Behavior:
All phone numbers should be exported regardless of type, as this complies with the VCard standard (RFC 6350 allows multiple values per property type).

0006201: Calendar invite: email has invalid message id

Tue, 26 May 2026 19:11:40 +0000

When I send a calendar invite, the resulting email message has an invalid message id in the format Message-Id: <ae06c383-0f08-ba0a-682a-4db12d05fb49@example.org>> (note the duplicate "greater than" character!).

The integration is: Thunderbird using CalDav towards my mailcow server. Thunderbird is not sending the invite locally via SMTP, but the mailcow backend creates the invite and sends it.

More details here: https://github.com/mailcow/mailcow-dockerized/issues/7213

0006195: SOGoMailCustomFromEnabled = NO not enforced server-side

Tue, 26 May 2026 15:42:00 +0000

The configuration option
SOGoMailCustomFromEnabled = NO
only disables the From field in the SOGo web UI It does not enforce any server-side validation on the /send endpoint. As a result, any authenticated user can bypass the restriction by directly POSTing to the draft send API with a modified from field in the JSON body, without needing any special tools beyond a browser's built-in DevTools.

0006220: Search for subject leads to wrong highlighting

Tue, 26 May 2026 11:59:56 +0000

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

0006219: SOGo sends two OIDC /authorize requests on login

Mon, 25 May 2026 12:24:43 +0000

SOGo configured for OIDC login sends two /authorize requests on user login which creates two OIDC sessions in OTPme (https://github.com/the2nd/otpme). Is this intentionally?

0006218: OIDC /end_session call does not include id_token_hint

Mon, 25 May 2026 12:02:35 +0000

The /end_session call of SOGo does not include the id_token_hit and thus OTPme (https://github.com/the2nd/otpme) does not know the SOGo OIDC session and cannot logout the SOGo session only but only do a complete logout of the user.

I havent found anything related in the SOGo documentation and want to ask, if there is a way to get SOGo to send the id token.

Regards
The2nd

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

Wed, 20 May 2026 12:04:21 +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

0006211: HTML sanitization corrupts JSON in preferences

Tue, 19 May 2026 08:05:12 +0000

After updating to SOGo 5.12.8 some users started to report that their changes are silently discarded when they try to save their preferences. The server log indicates that there is a problem parsing the JSON string:

```
May 18 09:54:07 sogod [1177678]: [ERROR] <0x0x55855f287ab0[GSUInlineString]> json parser: Expected value while parsing array, attempting once more after unescaping...
May 18 09:54:07 sogod [1177678]: [ERROR] <0x0x55855f287ab0[GSUInlineString]> total failure. Original string is: { […] "signature":" […] […] }
May 18 09:54:07 sogod [1177678]: x.x.x.x "POST /SOGo/so/user/Preferences/save HTTP/1.1" 200 0/15323 0.022 - - 0 - 17
```

The substring ``, which is part of the user's HTML email signature, is mangled into ` \"content-type\" con***="" charset=UTF-8\">`. This is a regression caused by commit 67ce01ec2a1a7854d8e9f615dd65afb949043e86 ("fix(mail): sanitise mail with ics (invitation to event)"). The revised regular expression incorrectly matches other HTML attribute names, such as `content`, instead of the intended event handler attributes. The string replacement performed in `stringWithoutHTMLInjection` is inappropriate when called by `saveAction` in `UIxPreferences.m`, as it removes the escape characters in the JSON string. In addition, the code path lacks proper error handling, as it returns an HTTP 200 status code and does not indicate any error to the user.

0006198: Clicking the Reply button causes a logout

Thu, 14 May 2026 14:24:13 +0000

When the Reply button is clicked in a specific email, SOGO generates HTTP requests without cookies (see screenshots).
This results in the user being logged out and redirected to the home page.

0006209: HTML ckeditor content truncated on forward if header reference

Tue, 12 May 2026 12:59:27 +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.

0006203: Build packages for Ubuntu 26.04 LTS

Mon, 11 May 2026 08:02:48 +0000

Dear developers,

Ubuntu 26.0t LTS was released[1] on Mar 23th 2026, any plan to build packages for it? And arm64 platform?

[1] https://discourse.ubuntu.com/t/resolute-raccoon-release-notes/59221

0006200: HTML is not rendered on search results

Sun, 10 May 2026 09:55:24 +0000

Message html content is correctly displayed when browsing message list, but is not rendered if the message list is filtered by search criteria.

0006167: Email preview fails when message contains more than 250 embedded HTML tags

Thu, 07 May 2026 12:51:51 +0000

Symptoms:

- Email preview does not render/display correctly
- No errors are shown in the logs
- The email displays correctly when opened in edit mode
- Other email clients (Thunderbird, Roundcube) display the same emails correctly in preview mode

0006168: Signature duplication when switching identities while composing email

Thu, 07 May 2026 12:51:28 +0000

We have identified an issue with signature management when composing emails with accounts that have multiple identities configured.

Symptoms:

- When composing a new email, the default user signature is inserted automatically
- When switching to a different identity, the new identity's signature is added to the message
- The original default signature is NOT removed, resulting in duplicate signatures
- Both the default user signature and the identity-specific signature appear in the email body

Expected behavior:
When switching to a different identity while composing an email, the previous signature should be removed and replaced with the signature associated with the newly selected identity. Only one signature should be present at any time.