SOGo | BTS - Issues

0006261: SOGo: Adding an attendee to an existing event does not notify the existing attendees

Wed, 21 Oct 2026 12:48:00 +0000

# SOGo: Adding an attendee to an existing event does not notify the existing attendees

**Component:** SOGo Calendar — attendee list modification
**Severity:** Medium — existing attendees are never informed about new participants
**Observed:** 2026-10-19

**Environment:**
- SOGo 5.12.11 (running under Mailcow 2026-09a)

## Summary

When the organizer adds a new attendee to an existing event, **only the new attendee** receives the invitation. Existing attendees receive **no message at all** — not even one containing the changed attendee list. Their mailboxes keep the old ICS attachments; they learn about the new participant only through calendar sync, if at all.

Google Workspace and Microsoft Exchange send an updated invitation to existing attendees when the attendee list changes ("X has been added to the meeting"). RFC 5546 likewise treats a change of the attendee list as a modification of the iCalendar object to be communicated to the attendees.

## Reproduction

Works with three SOGo accounts:

1. Organizer O creates an event with participant P1.
2. O adds participant P2 to the event (SOGo Web UI).
3. Check P1's mailbox and calendar.

## Actual behavior

- P2 (new attendee): receives the full invitation with the correct current state (both ATTENDEEs, same UID). OK.
- P1 (existing attendee): receives **no message**. The ICS attachments in P1's mailbox remain the old ones (listing only P1 as ATTENDEE).
- The server-side event state is updated (P2 is visible in the event view); P1's CalDAV-synced calendar shows P2 correctly after sync.
- Side finding: `SEQUENCE` was not incremented for this modification (see also the separate SEQUENCE report).

## Expected behavior

All existing attendees receive an updated invitation with the changed ATTENDEE list (and incremented `SEQUENCE`), so participants who work via e-mail are informed that another person has been added — comparable to Google Workspace and Exchange.

## Impact

Existing participants are never told via e-mail that the event has grown by one person. In organizations where invitations are read by e-mail (planning, hierarchy, relevance or confidentiality of the added participant), this is misleading. With CalDAV-only clients the gap stays invisible — which is exactly why it goes unnoticed.

## Suggested fix

On attendee-list modification, send all existing attendees an updated invitation (current event state, new ATTENDEE list, incremented SEQUENCE) in addition to the invitation sent to the new attendee.

0006260: SOGo: Incoming REPLYs (accept/decline) are not automatically recorded in the organizer's calendar

Wed, 21 Oct 2026 12:46:47 +0000

# SOGo: Incoming REPLYs (accept/decline) are not automatically recorded in the organizer's calendar

**Component:** SOGo Webmail / Calendar — processing of incoming calendar replies
**Severity:** Medium — organizer sees stale attendee status; hidden manual workflow step
**Observed:** 2026-10-19, two independent cases (internal and external acceptance)

**Environment:**
- SOGo 5.12.11 (running under Mailcow 2026-09a)

## Summary

When a participant's reply (`METHOD:REPLY`) arrives in the organizer's mailbox, SOGo **does not update the attendee status in the calendar automatically**. The status remains `NEEDS-ACTION` until the organizer opens the REPLY mail in Web UI and manually clicks "update status".

Google Calendar, Microsoft Exchange/Outlook, and standard CalDAV clients all process incoming REPLYs automatically — the manual click in SOGo is a workflow gap.

## Reproduction

Works with two SOGo accounts:

1. Organizer A invites participant B to an event.
2. B accepts the event (in SOGo or in an external client, e.g. Gmail/Thunderbird).
3. A checks his SOGo calendar **without** clicking anything in the mailbox.

## Actual behavior

- The event still shows B as `NEEDS-ACTION`; the calendar entry's `LAST-MODIFIED` does not change.
- Only after manually opening the REPLY mail in SOGo Web UI and clicking "update status" does the status switch to `ACCEPTED` — same UID, no duplicate.
- Second case (external participant, accepted in Gmail): exactly the same behavior — also recorded only after the manual click.

## Expected behavior

A REPLY arriving in the organizer's mailbox is applied to the calendar automatically (status update, `LAST-MODIFIED` bumped, no duplicates) — as in Google Calendar, Exchange/Outlook, and CalDAV clients. The manual click should at most remain a fallback.

## Delimitations (not bugs)

- The REPLYs were well-formed (`METHOD:REPLY`, `PARTSTAT=ACCEPTED`, correct UID, addressed to the organizer).
- The recording itself works correctly — only the automatic trigger is missing.

## Impact

Organizers see wrong/stale attendee statuses (e.g. "pending" instead of "accepted") until they know about and perform the manual step. In busy mailboxes the REPLY mail is easily missed, leaving statuses silently wrong.

## Suggested fix

Process incoming `METHOD:REPLY` messages for events organized by the local user automatically at mail delivery time — using the same correlation rules (UID + attendee address) that the manual "update status" button applies.

0006259: SOGo: SEQUENCE not incremented on series cancellation (METHOD:CANCEL) — external clients reject the cancel

Wed, 21 Oct 2026 12:44:09 +0000

# SOGo: SEQUENCE not incremented on series cancellation (METHOD:CANCEL) — external clients reject the cancel

**Component:** SOGo Calendar (event modification / cancellation)
**Severity:** High — external participants silently keep stale events
**Observed:** 2026-10-19

**Environment:**
- SOGo 5.12.11 (running under Mailcow 2026-09a)
- External reference client for observation: Google Calendar (enforces SEQUENCE version ordering)

## Summary

When an organizer reschedules a single occurrence of a recurring event and then cancels the entire series, the `METHOD:CANCEL` message for the base series contains **no SEQUENCE property** (implicit 0) — even though participants had just received `SEQUENCE:1` for the single-occurrence change. Clients that enforce version ordering (Google Calendar does) discard the CANCEL as an older version (0 < 1) and **keep all occurrences**. SOGo participants remove the series correctly.

## Reproduction

Works on a fresh instance with two SOGo accounts and one Google mailbox:

1. The organizer (SOGo) creates a recurring weekly series (e.g. 4 occurrences) with two participants: one SOGo user and one Google mailbox. Both sides receive the series correctly (same UID, same RRULE).
2. The organizer reschedules **a single occurrence** of the series in the SOGo Web UI (e.g. 19:00 → 20:00).
- SOGo sends the exception instance (`RECURRENCE-ID`, same UID) with `SEQUENCE:1`.
- Both participants process it correctly; Google shows the affected occurrence at the new time.
3. The organizer then cancels the **entire series**.
- SOGo sends `METHOD:CANCEL` to all participants for the base-series UID.
4. Check: the `SEQUENCE` property in the CANCEL message (raw mail) and the result in Google Calendar.

## Actual behavior

- The CANCEL for the base series contains **no SEQUENCE property** (implicit 0).
- SOGo participant: series is removed completely.
- Google Calendar: **nothing is removed** — all occurrences remain in the calendar. Google discards the CANCEL because the implicit 0 is lower than the last version it saw (1).

Delimitations:

- Google had applied the step-2 single-occurrence change correctly — only the CANCEL is discarded. Pure version-ordering behavior, not a general interop problem.
- The missing reply button in the CANCEL mail is normal (RFC 5546 requires no reply to CANCEL).

Additionally observed in the same deployment:

- **Cancelling a single (non-recurring) event:** the CANCEL carried `SEQUENCE:1` — i.e. a copy of the last state, not an increment by one.
- **Adding an attendee:** SEQUENCE was left unchanged.

## Expected behavior

RFC 5545 §3.8.7.4: SEQUENCE "MUST be updated with a new value that is incremented by one" whenever the iCalendar object is revised. The CANCEL for a series must carry a SEQUENCE greater than any SEQUENCE previously issued for that UID (base event **or** exception instances), so that all clients accept the cancel as a newer version.

## Impact

If an organizer modifies one occurrence of a series and later cancels the series, every external participant (Google/Outlook/Apple) keeps the old occurrences indefinitely. Without manual cleanup or explicit communication, the cancellation is lost for them — unacceptable for production use.

## Suggested fix

Always increment SEQUENCE by one when generating any revised component, including `METHOD:CANCEL`, and ensure the CANCEL for a series carries at least the maximum SEQUENCE previously issued for that UID (including exception instances).

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

Tue, 20 Oct 2026 13:22:19 +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

0006258: Changes to "Description" fail to trigger updated invite to be sent

Sun, 18 Oct 2026 08:08:02 +0000

I noticed that when I change the "Description" for an invite (that often contains the "agenda" for a meeting), the SOGo backend does NOT trigger an updated invite to be sent out to participants.

This is a very serious problem, because participants will not get notified about an updated agenda.

0006256: SOGO doesn't start with "tlsVerifyMode=None"

Fri, 16 Oct 2026 09:56:12 +0000

After updating to 5.12.12 , I had issues with LDAP due to a self signed cert but attempting to add "?tlsVerifyMode=None;" as indicated in the News entry seems to prevent SOGO from starting up. Nothing was logged in the SOGO log either. I was able to resolve this by adding the cert as trusted on the server. Is there some issue preventing this tlsVerifyMode from working properly as described?

0006257: Cyrillic "б" and "ж" act as recipient separators in the To field unless the UI language is Russian (#4042 fix is incomplete)

Fri, 16 Oct 2026 07:31:19 +0000

In the message composer, typing "б" or "ж" with the Ukrainian keyboard layout in the To/Cc/Bcc field doesn't insert the letter. Instead, the text typed so far is turned into a recipient chip, and the letter is lost. Contacts with these letters in their names can't be searched or entered.

This is the same problem as 0004042, fixed in commit c2eed78 ("use different email separator keys depending on locale"). That fix removes the comma and semicolon separators only when the interface language is "ru". On the Ukrainian layout, "б" and "ж" share physical keys with "," (keyCode 188) and ";" (keyCode 186), so the bug still occurs with any other interface language.

Tested:
- UI language Ukrainian + Ukrainian layout -> bug
- UI language English + Ukrainian layout -> bug
- UI language Russian + Ukrainian layout -> works correctly

0006255: Unused tags in search filter & horrific bug report system

Tue, 13 Oct 2026 09:13:45 +0000

Dear SOGo Team,

This problem is known and discussed for years (and probably easy to solve), but it was never solved:

All tags ever used appear in the tags search filter, thus making it potentially very long and full of unused or even already deleted tags.

The search filter by tags should only show currently used tags in the currently opened mails folder.

Btw, you make it very hard to report bugs or submit suggestions:

- The Github project is a mess (there seems to be no official way here to report bugs or suggestions to SOGo, while most known open source software providers use mainly Github to collect bugs and suggestions)

- The bug system here is also a mess: even if you take the time to register an account (as there's no way to use Github or some other existing login), you then are assigned a "read only" status, making it impossible to report a bug or suggestion immediately. That's really annoying - why to you redirect us to this bug system and let us register there, if in the end you don't allow us to post something? Furthermore, there's not even a free text search function in this antiquated bug report system. You ask users here to check if a bug already exists, but the 90s style system doesn't even allow to conduct a free text search... so how should we check without manually parsing dozens or hundreds of pages and bug report titles?

Thanks for your consideration and potential reply!

0006254: CalDAV stores and serves back duplicate RRULE and VALARM properties unchanged

Mon, 12 Oct 2026 14:45:03 +0000

Some CalDAV clients upload recurring events whose master VEVENT repeats the same RRULE many times, and whose master and RECURRENCE-ID overrides repeat byte-identical VALARMs. SOGo stores these objects as received and returns them through CalDAV to every other client, so one faulty client spreads the damage to every device that syncs the calendar.

Seen on a production server (mailcow, SOGo 5.12.11), across 14 mailboxes:
- one VEVENT with 298 identical lines RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=WE
- one object with 1185 identical VALARMs (631 KB)

Effect on other clients: Thunderbird shows the same reminder many times and cannot display the recurrence ("Repeat details unknown"); Android Etar can join the repeated RRULEs into one rule and crash while parsing the event.

The duplicates come from a Thunderbird bug that appends one RRULE/VALARM copy per offline edit playback (https://bugzilla.mozilla.org/show_bug.cgi?id=1713625, fixed for Thunderbird 155, not in 140 ESR; also https://bugzilla.mozilla.org/show_bug.cgi?id=1999085). SOGo does not create them, but it keeps redistributing them after the client is fixed.

RFC 5545 section 3.8.5.3 says RRULE SHOULD NOT occur more than once, and the recurrence set from multiple RRULEs is undefined. Multiple VALARMs are legal (section 3.6.1), so only alarms that serialize identically are duplicates. Distinct alarms must be kept (see 0004600).

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

Mon, 12 Oct 2026 08:27:11 +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.

0006252: A Big Thank You & 9 Feature Requests to Make SOGo a 10/10 (PWA Sessions, UI Tweaks, and Workflow)

Sat, 10 Oct 2026 15:25:00 +0000

Dear SOGo Team,

I wanted to take a moment to share my thoughts and express my immense gratitude. Together with Mailcow, I have found something truly exceptional in SOGo. Thanks to your work, I now host all my emails on my private server and only use AppleMail/iCloud for receiving and sending, without storing any data there. I’ve tested many solutions (Betterbird on Linux, Nextcloud, and several commercial competitors), but SOGo fulfills almost all my wishes. You are currently a solid 9/10 for me!

I want to highlight a crucial advantage that makes SOGo a major player in my eyes: the perfect web-based experience. I run SOGo and Mailcow on a uGreen 6011pro (2x2TB SSDs) via Docker/VMs, with a secondary NAS as a backup in another apartment. My whole family accesses our self-hosted apps securely via Wireguard. We use a wide variety of devices—from a 12-year-old notebook to an 8-year-old smartphone and various iPads. We access SOGo purely through the web interface (organized via a Homarr dashboard).
The greatest benefit? Zero data is stored on the local devices. Everything is accessed centrally, updates are managed in one place, and privacy is fully protected. It runs incredibly fast and flawlessly across all devices. Amazing job!

To make SOGo a perfect 10/10 for my family and me, I have a few feature requests. It would be fantastic if some of these could be implemented, perhaps as optional toggles for those who want them:

Global Search by Default: I would love an option to search all folders and messages by default, without having to manually switch the search scope every time.

Persistent Mobile Sessions (PWA): We use SOGo as a bookmark on our iPhone home screens. Currently, we have to log in with our password multiple times a day. In the age of Progressive Web Apps, a "Remember me" token (e.g., for 7 or 30 days) is essential for a smooth mobile experience.

Mobile Layout Tweaks: I've noticed a few minor layout bugs and inconsistencies when using SOGo on a mobile browser.

Keyboard Shortcuts / Fast Archive: Archiving an email currently takes about 5 clicks (Move -> Move to -> Account -> Scroll down -> Archive). A quick shortcut or a 1-click button to move emails directly to the Archive would be a huge workflow improvement.

Collapsible Left Sidebar: The left sidebar (Inbox and folders) takes up quite a bit of space, even though my folder names are short. It would be great to be able to shrink it or collapse it into a narrow strip of icons, rather than hiding the entire bar completely.

Auto-Add Contacts on Reply: If I reply to someone, it would be highly practical if their email address was automatically added to my contacts so they appear in auto-complete the next time I compose a message.

Inline Media Previews: It would be great to view PDF attachments, photos, or play audio files directly in the browser beneath the email text, without having to download them first.

Contact Photos in Mail View: If I have a photo assigned to a contact in the address book, it would be visually helpful to see that photo next to their emails in the mailbox.

AI Integration: As a forward-looking feature, optional AI tools (e.g., to translate emails into other languages or summarize long threads) would be amazing.

Thank you again for your hard work and for providing such an outstanding piece of software!

Best regards,
Paul

0006253: Release repository for Debian 12 bookworm not working anymore

Wed, 07 Oct 2026 10:24:15 +0000

On the release repo for Debian 12 bookworm we can no longer get updates for SOGo and SOPE.

0006201: Calendar invite: email has invalid message id

Wed, 07 Oct 2026 09:16:04 +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

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

Sun, 04 Oct 2026 06:50:55 +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

0006248: Cannot subscribe to child calenders with Sogo connector

Tue, 29 Sep 2026 10:35:37 +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.

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.

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.