SOGo | BTS - Issues

0006251: SOGo VLIST does not permanently save selected email addresses for contacts with multiple addresses

Fri, 25 Sep 2026 11:41:27 +0000

SOGo contacts can contain multiple email addresses, but a VLIST distribution list does not appear to preserve which specific email address of a contact was selected.

This causes problems when the same person should be contacted via different addresses depending on the distribution list.

Example:

* Contact: John Doe
* Private email: john.private@example.com
* Functional/work email: board@example.com

Desired usage:

* VLIST “Invitations” → john.private@example.com
* VLIST “Internal” → board@example.com

Steps to reproduce

1. Create a contact with at least two email addresses.
2. Create a new VLIST / distribution list.
3. Add the contact to the list.
4. Select the second email address of the contact.
5. Save the list.
6. Reopen the list.

Actual behavior

After reopening the VLIST, SOGo no longer shows or uses the previously selected email address.

Instead, another email address of the same contact is used again, apparently the default/preferred address.

Changing the address again and saving the list does not persist the selection.

Expected behavior

A VLIST member should preserve the exact email address selected for that contact.

It should be possible to use different email addresses of the same contact in different VLISTs.

Environment

* SOGo 5.12.11
* Web interface
* CardDAV address book
* Reproducible with contacts containing multiple email addresses

Question

Is this an intended limitation of the current VLIST implementation?

Does a VLIST member only reference the contact itself, causing SOGo to resolve the email address again from the contact?

If so, would it be possible for VLIST members to store or reference the specific selected EMAIL property instead of always resolving to a default/preferred address?

If this is not intended behavior, this may be a bug in how the selected email address is persisted or restored for VLIST members.

0006250: Email sorting does not work anymore

Wed, 23 Sep 2026 14:27:15 +0000

In the email view you can no longer sort the list of emails in the middle column.
Whatever sorting was set before upgrading to 5.12.11 is still there and can no longer be changed.

0006249: Choose mail identity in composer doesn't work intuitively

Mon, 21 Sep 2026 10:01:35 +0000

The dropdown to choose the mail identity in the composer only opens when clicking on the close/delete "x" button in the right.

As a user, I would expect the dropdown to open when clicking anywhere in the identity field. Also, the "x" symbol is irritative. To indicate, that the field is a dropdown, it should have a typical dropdown "v" symbol.

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

Wed, 16 Sep 2026 08:17:31 +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

0006168: Signature duplication when switching identities while composing email

Wed, 16 Sep 2026 08:17:31 +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.

0006248: Cannot subscribe to child calenders with Sogo connector

Wed, 16 Sep 2026 08:16:14 +0000

When using the latest Sogo connector for Thunderbird, I cannot subscribe to nested calendars, e.g.

Parent Calender
-> Child Calender 1
-> Child Calender 2

Sogo would only show me "Parent Calender", but not the two child calendars from this calendar. Using Sogo in the browser, this works as expected.

0006247: "Show time as busy outside working hours" ignores timezones

Fri, 11 Sep 2026 07:37:39 +0000

When a users sets the property "Show time as busy outside working hours" - they expect the time to be shown as busy for other users accounting for the timezone differences. However, the free/busy calendar view when scheduling an event shows the user with that setting enabled as busy outside the time they specified in their calendar settings "Day start time" and "Day end time", but not adjusting those hours according to the timezone of the source and target user. However, calendar events free/busy times ARE correctly adjusted to the timezone of the source user.

0006245: Languages.plist: NGObjWeb: map "tr"/"tr-tr" to TurkishTurkey (SOGo ships no Turkish.lproj)

Tue, 08 Sep 2026 08:28:11 +0000

## Problem

SOGo's Turkish translation is shipped only as `TurkishTurkey.lproj` (all 11 UI bundles in Alinto/sogo master; there is no `Turkish.lproj`). NGObjWeb's browser-language table `sope-appserver/NGObjWeb/Languages.plist` still maps the bare code to the old name:

"tr" = "Turkish";

As a result a browser that sends `Accept-Language: tr-TR,tr` never reaches the Turkish translation: WOResourceManager looks for `Turkish.lproj`, logs

sogod [pid]: [ERROR] [we-rm] did not find locale for language: Turkish and SOGo falls back to English (login page, and the whole UI for every user who has not saved a language preference yet), regardless of `SOGoLanguage = TurkishTurkey` in sogo.conf.

## Fix

Point the mapping at the bundle that actually exists, exactly like the existing entries for Spanish (`"es" = "SpanishSpain"`; SOGo ships `SpanishSpain.lproj`, no `Spanish.lproj`), and add the regional key browsers send:

"tr" = "TurkishTurkey";
"tr-tr" = "TurkishTurkey";

## Verification

With the one-line change applied to the installed plist and sogod restarted:

Accept-Language: tr-TR,tr;q=0.9,en;q=0.5 ->
Accept-Language: en-US,en;q=0.9 -> lang="en" (unchanged)
Accept-Language: de-DE,de;q=0.9 -> lang="de" (unchanged)
sogo.log: no further "did not find locale for language: Turkish" entries

Verified on three OpenBSD 7.9 hosts (SOGo 5.12.9, sope-4.9 packages). Users who have explicitly saved another language in Preferences are not affected; only the browser-language detection changes.

0006235: Vacation message : one day difference with sieve script

Thu, 03 Sep 2026 14:16:54 +0000

If you select a start date in the web interface for vacation message the day after is written in the .dovecot.sieve

0006243: Error 501 when and after saving settings

Wed, 02 Sep 2026 12:19:28 +0000

After clicking "save" in the web interface, error 501 appears and it is no longer possible to access the web interface under this user.
sogo.log:
Sep 02 15:53:09 sogod [24740]: 192.168.2.36 "GET /SOGo/so/yur/Preferences HTTP/1.1" 200 38657/0 0.500 180288 78% 2M - 15
Sep 02 15:53:10 sogod [24740]: 192.168.2.36 "GET /SOGo/so/yur/Calendar/alarmslist?browserTime=1788339190 HTTP/1.1" 200 60/0 0.012 - - 0 - 15
Sep 02 15:53:10 sogod [24740]: 192.168.2.36 "GET /SOGo/so/yur/activeExternalSieveScripts HTTP/1.1" 404 0/0 0.093 - - 0 - 15
Sep 02 15:53:10 sogod [24738]: 192.168.2.36 "POST /SOGo/so/yur/Mail/0/folderINBOX/changes HTTP/1.1" 200 20/126 0.272 - - 0 - 14
Sep 02 15:53:18 sogod [24738]: 192.168.2.36 "POST /SOGo/so/yur/Preferences/save HTTP/1.1" 501 0/4388 0.100 - - 1M - 14
Sep 02 15:56:32 sogod [24738]: 192.168.2.36 "GET /SOGo/so/yur/Preferences HTTP/1.1" 501 0/0 0.002 - - 0 - 15
Sep 02 15:56:35 sogod [24738]: 192.168.2.36 "GET /SOGo/so/yur/Preferences HTTP/1.1" 501 0/0 0.004 - - 0 - 15
...
2026-09-02 16:48:54.269 sogod[15277] EXCEPTION: NAME:NSInvalidArgumentException REASON:-[GSMutableArray
setObject:atIndexedSubscript:]: unrecognized selector sent to instance 0x5595a64a2d88 INFO:(null)
Sep 02 16:48:54 sogod [15277]: 192.168.2.36 "GET /SOGo/ HTTP/1.1" 501 0/0 0.012 - - 16K - 16

0006242: SOGo 5 web interface duplicates imported contacts with @ in UID during modification (URL-encoding bug)

Tue, 01 Sep 2026 14:21:52 +0000

When modifying an imported contact whose UID contains an @ sign, SOGo does not update the existing contact.
Instead, it creates a duplicate contact where the @ sign in the UID is replaced by its URL-encoded equivalent %40.

0006241: `fetchVanished:` misses an expunged highest UID when using `UID FETCH 1:*` against Cyrus IMAP 3.8

Tue, 01 Sep 2026 13:56:07 +0000

I updated from Cyrus IMAP 3.0.7 on RHEL 8 to 3.8.3 on RHEL 10 over the weekend. SOGo runs on a separate RHEL 9 server.

Symptom:
SOGo ActiveSync clients retain a deleted Inbox message when the deleted message was the mailbox's highest live UID. Additions continue to synchronize, SOGo webmail shows the correct mailbox, and independent ActiveSync clients (Nine and Samsung Email) fail identically.

Environment:

- SOGo and sogo-activesync 5.12.10 (30 August 2026 nightly)
- SOPE 4.9 from the same nightly
- Cyrus IMAP 3.8.3
- QRESYNC/CONDSTORE enabled
- `expunge_mode: delayed` and `autoexpunge: yes`

After expunging the mailbox's highest live UID, Cyrus 3.8 resolves `*` to the highest UID still present. The expunged UID is therefore outside the requested UID set and is not returned as VANISHED. SOGo advances the collection MODSEQ without generating an ActiveSync Delete, leaving the client entry stale.

This differs from Cyrus 3.0.7. Its `_parse_sequence()` used `state->last_uid` as the UID `*` expansion. Cyrus 3.8.3 instead uses `index_getuid(state, state->exists)` when messages remain, matching the highest surviving UID. The behavior change exposes SOPE's use of an ambiguous upper bound for vanished messages.

Direct reproduction after expunging the highest UID:

UID FETCH 1:* (UID) (CHANGEDSINCE VANISHED)

does not return the expunged UID, while both of these do:

UID FETCH 1: (UID) (CHANGEDSINCE VANISHED)
UID FETCH 1:4294967295 (UID) (CHANGEDSINCE VANISHED)

Proposed one-line fix:

diff
- @"UID FETCH 1:* (UID) (CHANGEDSINCE %llu VANISHED)",
+ @"UID FETCH 1:4294967295 (UID) (CHANGEDSINCE %llu VANISHED)",

The full UID range avoids `*` changing after the highest UID is expunged.

Validation: we packaged this change in a local fix. A disposable message was confirmed visible in SOGo, Nine and Samsung before deletion. SOGo deleted it; Cyrus reported the allocated UID absent, no live `\Deleted` records, and an advanced HIGHESTMODSEQ. Both ActiveSync clients then removed the message by normal refresh without resetting the folder or account.

0006240: non-root inline text/html part in multipart/related is rendered as message body

Thu, 27 Aug 2026 11:45:22 +0000

Problem:
SOGo renders a non-root text/html MIME part with

Content-Disposition: inline

inside a multipart/related message as additional visible message body content.

The same message is displayed correctly in Thunderbird.

Minimal MIME structure:

multipart/related; type="multipart/alternative"
|
+-- multipart/alternative <-- root object
| |
| +-- text/plain
| |
| +-- text/html <-- actual message body
|
+-- text/html <-- related non-root part
Content-ID:
Content-Disposition: inline

There is no "start" parameter on the outer multipart/related, therefore the first body part (multipart/alternative) is the root object.

Actual behavior in SOGo:
SOGo displays both

the normal HTML message body, and
the additional related text/html part below the message.

If the related HTML part contains CSS such as position, z-index or large backgrounds, this can severely break the message display.

Expected behavior:
Only the root object of multipart/related should be displayed as the message body.

Non-root related MIME parts should not automatically be rendered as additional message body content.

Thunderbird behavior:
Thunderbird displays only the actual root HTML message. The additional inline text/html related part is not appended to the visible message body.

0006238: SOGO Connector - Thunderbird 153esr - Subscribed calendar rename and color change don't persist

Thu, 27 Aug 2026 08:28:14 +0000

Good afternoon,

The current SOGo connector (140) installs on the new ESR version of Thunderbird (153) and mostly works. Sync, subscribe, unsubscribe work for calendars and the custom icons are there.

Unfortunately, when editing a subscribed calendar in Thunderbird to rename it or modify the color, the change does not survive a restart of Thunderbird.

Best regards,

Fabio

0006239: Attachments Mismatch When Two Users Send Emails Concurrently from the Same Mailbox via Web Interface

Thu, 27 Aug 2026 06:56:53 +0000

We are experiencing a critical issue with the SOGo web interface when two users are simultaneously logged into and using the same email account.

When two users compose and send two different emails at the same time from the same mailbox using the web interface, the file attachment from one email is incorrectly attached to the other email, and vice versa.

The attachments become swapped between the two outgoing messages.

Example:
email.xyz.zz - 0.0.0.148 - - [26/Aug/2026:11:54:41 +0300] "POST /SOGo/so/info@abc.aa/Mail/0/folderDrafts/newDraft1787734448-1/send HTTP/2.0" 200 95 "https://email.xyz.zz/SOGo/so/info@abc.aa/Mail//UIxMailPopupView" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36" 0.342 0.340
email.xyz.zz - 0.0.0.149 - - [26/Aug/2026:11:54:44 +0300] "POST /SOGo/so/info@abc.aa/Mail/0/folderDrafts/newDraft1787734448-1/send HTTP/2.0" 200 20 "https://email.xyz.zz/SOGo/so/info@abc.aa/Mail//UIxMailPopupView" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36" 0.307 0.306

0006236: Support structured calendar locations for iOS

Sat, 22 Aug 2026 17:10:43 +0000

When using SOGo Calendar through Exchange ActiveSync on iOS, calendar event locations are synchronized as plain text.
As a result, Apple Calendar does not provide its normal location/map suggestions when entering a location in an event.
The same iOS device provides location suggestions correctly when using an iCloud calendar.
Since ActiveSync is being retained in SOGo 6 specifically to provide native mobile-client compatibility, improved calendar-location support for iOS would be particularly useful.

EAS protocol details:
The EAS AirSyncBase namespace defines structured location properties beginning with EAS 16.0.

Relevant elements include:
* AirSyncBase:Location
* AirSyncBase:Street
* AirSyncBase:City
* AirSyncBase:State
* AirSyncBase:Country
* AirSyncBase:PostalCode
* AirSyncBase:Latitude
* AirSyncBase:Longitude
* AirSyncBase:Accuracy
* AirSyncBase:Altitude
* AirSyncBase:AltitudeAccuracy
* AirSyncBase:LocationUri

Microsoft protocol specification:
https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-aswbxml/aa548cbc-b15f-4dc1-8bda-82b35d9d41c4

Current behavior:
For an event containing, for example:
Location: Oslo S, Jernbanetorget 1, 0154 Oslo
SOGo/EAS appears to expose the location primarily as a conventional text location.
Apple Calendar consequently treats it as text rather than as a structured location that can be resolved through Apple Maps.

Requested behavior:
Could SOGo’s ActiveSync implementation expose the structured AirSyncBase:Location properties when synchronizing calendar events?
At minimum, it would be useful to investigate mapping SOGo/iCalendar location data to:
Location
Street
City
State
Country
PostalCode
Latitude
Longitude
LocationUri

Where coordinates are not available in the calendar data, the server could potentially provide the textual address fields without latitude/longitude, or leave those fields empty.

EAS version negotiation:
It would also be useful to clarify whether iOS requires the server to advertise/negotiate EAS 16.x before it will consume the structured AirSyncBase:Location elements.
If so, could the relevant EAS 16.x capability/version negotiation be implemented independently of the rest of the EAS 16 feature set?
In other words, this request does not necessarily require a complete EAS 16 implementation if the structured Location functionality can be added independently.

Expected result on iOS:
When creating or editing an event in an SOGo calendar on iOS, entering an address or place in the Location field should provide the native Apple Calendar location suggestions/map integration, in the same way as an iCloud calendar.

Environment:
* SOGo 5.x / planned SOGo 6
* Mailcow
* Exchange ActiveSync
* Apple Calendar on iOS

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

Sun, 16 Aug 2026 01:48:02 +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

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

Thu, 13 Aug 2026 06:24:52 +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.

0006234: IDN mailbox: web UI inconsistent (using both IDN and punycode versions of the email address)

Sun, 02 Aug 2026 18:45:33 +0000

I have an IDN domain in use with SOGo (as part of mailcow 2026-07a).

When I launch SOGo for a mailbox under that domain, the SOGo web UI is very inconsistent. It shows on the very same page
- the proper IDN representation in the message view (right part in the screen shot, showing the contents of INBOX) and
- the punycode representation of the email address (in the left pane that shows the account name)

In my view, the punycode representation should never be shown to ordinary users. They know nothing about Punycode, it just confuses them.

0006233: IDN mailbox: sending email uses punycode representation of domain instead of IDN variant

Sun, 02 Aug 2026 18:37:26 +0000

I have an IDN domain configured, let's call it "exümple.org", and a mailbox called "test@exümple.org". When I log on to SOGo (I'm using it as part of mailcow 2026-07a) and send an email from that account, the "From:" header uses the punycode representation "test@xn--exmple-4ya.org" (and not the expected "test@exümple.org" that humans commonly use and expect!).

So a recipient sees the very cryptic sender address of "test@xn--exmple-4ya.org" that will typically be unknown (and untrusted!) to them, and they will not recognize the sender as a known one.

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

Tue, 21 Jul 2026 06:31:25 +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

Sun, 19 Jul 2026 09:02:39 +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?

0006201: Calendar invite: email has invalid message id

Fri, 17 Jul 2026 20:14:11 +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

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

Fri, 17 Jul 2026 20:14:01 +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.

0006232: Account verification link is broken when displayed in SOGo email viewer

Mon, 13 Jul 2026 12:54:06 +0000

When receiving the account registration email from the SOGo Bug Tracker or anywhere else, the verification URL is not displayed correctly in the SOGo webmail interface.

Instead of showing the complete URL, part of the query parameter is replaced with ***, resulting in a link similar to:

https://bugs.sogo.nu/verify.php?id=4129&con***=...

Clicking this link opens an invalid URL, and the account cannot be verified.

The original verification URL should remain intact and clickable. It appears that SOGo is masking or truncating the URL, causing the verification process to fail.