SOGo | BTS - Issues

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

Sat, 07 Nov 2026 04:01:22 +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.

0006269: CardDAV DELETE deletes a contact despite a non-matching If-Match

Fri, 06 Nov 2026 13:39:37 +0000

On SOGo 5.12.13, a DELETE request with a non-matching If-Match returns 204 No Content and deletes the contact. It should return 412 Precondition Failed and leave the contact unchanged.

This prevents clients from using If-Match to protect against deleting a contact modified by another client.

0006267: Nightly Debian packages not updating since 2026-11-02 despite repository metadata refresh

Fri, 06 Nov 2026 09:23:31 +0000

The nightly Debian repository for SOGo 5 appears to be in an inconsistent state. While the repository metadata database files are still being updated, the actual binary packages (.deb) have not been rebuilt or published for several days.
Evidence:
1. Package pool is stale: The directory https://packages.sogo.nu/nightly/5/debian/pool/bookworm/s/sogo/ shows that the latest .deb files (including sogo, sogo-activesync, sogo-dev, sogo-dbg) are all timestamped 2026-11-02 09:44. No newer builds are present.
2. Metadata appears refreshed: In contrast, the database directory https://packages.sogo.nu/nightly/5/debian/db/ shows files such as packages.db and checksums.db with a modification timestamp of the same date (2026-11-02 09:44), but the key issue is that the actual packages in the pool have not advanced beyond this date.
3. Version observed: The most recent package filename visible is sogo_5.12.12.2026110..., suggesting a build from around November 2, 2026.
Nightly .deb packages for Debian bookworm have not been updated since 2026-11-02. Users pulling from the nightly repository will not receive any builds newer than this date.
Please repair this.

0006266: Events with U+FFFE leads to invalid CalDAV XML

Wed, 04 Nov 2026 10:54:06 +0000

It's possible to enter the character U+FFFE () into event summaries and descriptions (other fields not tested) which leads to invalid or not well-formed XML in CalDAV (see attachment) where the character is encoded as . If I read RFC 5542 correctly this character should not be allowed in iCalendar events at all.

0006265: Rate limiting errors do not provided a Retry-After header to facilitate client failure recovery

Tue, 03 Nov 2026 16:25:52 +0000

A RetryAfter header should be added as part of the rate limiting in addition to HTTP error with code 429. This would help clients (here Thunderbird) to implement a better recovery strategy (wait and retry).

https://github.com/Alinto/sogo/blob/e2ce2bdb6ee01e875da40744f23b3e17008e36e2/Main/SOGo.m#L591

cf.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429
https://www.rfc-editor.org/info/rfc6585/#section-4

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

Tue, 03 Nov 2026 14:59:06 +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

0006264: ActiveSync: Organizer_Email is not XML-escaped, an organizer like `mailto:` breaks the whole Sync response

Sun, 01 Nov 2026 20:01:07 +0000

Seen on SOGo 5.12.12 (mailcow image ghcr.io/mailcow/sogo:5.12.12-1); the code is unchanged on master.

When an event's ORGANIZER contains characters that are special in XML, the
ActiveSync Sync response for its calendar is not well-formed. libwbxml then
refuses it and SOGo answers HTTP 200 with an empty body:

```
sogod [47]: <0x...[SOGoActiveSyncDispatcher]> Change detected during Sync, we push the content.
sogod [47]: [ERROR] <0x...[NSDataMalloc]> xml2wbxml failed: Parsing of XML Document Failed
sogod [47]: ... "POST /SOGo/Microsoft-Server-ActiveSync?Cmd=Sync&User=...&DeviceType=Android HTTP/1.1" 200 0/95 0.270 - - 0 - 13
```

The client takes the empty answer as "no change", so every item in the same
window is never delivered, and the sync stays stuck on that window on every
later request. CalDAV clients are not affected.

Doctolib (a large French medical booking service) sends invitations whose
organizer has angle brackets. Once such an invitation is imported (here with
Evolution), the calendar stops syncing over EAS:

```
ORGANIZER;CN=Doctolib:mailto:<no-reply@doctolib.fr>
```

**Cause:** in `ActiveSync/iCalEvent+ActiveSync.m`, the organizer email is
appended raw, whereas the attendee email a few lines below is escaped:

```objc
o = [organizer rfc822Email];
if (![self recurrenceId] && [o length])
{
[s appendFormat: @"%@", o];
```

```objc
[s appendFormat: @"%@", [[attendee rfc822Email] activeSyncRepresentationInContext: context]];
```

**Suggested fix:**

```objc
[s appendFormat: @"%@", [o activeSyncRepresentationInContext: context]];
```

It may be worth checking the other `appendFormat:` calls of the ActiveSync
representations for raw values too (any string coming from the iCalendar
data).

0006168: Signature duplication when switching identities while composing email

Wed, 28 Oct 2026 05:29:22 +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.

0005872: high cpu load and some looping behavior of apple devices connecting to sogo / mailcow

Mon, 26 Oct 2026 22:25:26 +0000

https://github.com/mailcow/mailcow-dockerized/issues/5045

0006262: Attachment 0f type *.ics sometimes just shown in mail, but not addable into calendar

Mon, 26 Oct 2026 12:46:50 +0000

I have problems with some kind of ics attachments from outside of my SOGo
world ... There is a guy sending me an appointment via mail, attached as a base64 encoded file:

Content-Type: text/calendar;
name=Kalender_002.ics
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=Kalender_002.ics;
size=5335

The content is shown inline of the mail correct, but the appointment cannot be
added to the calendar or downloaded as ics-file in SOGo. Roundcube gives the option do get the file an save it in local filesystem.

0006263: .p7s file appears attached in composer but is silently omitted from message, even when uploaded alone

Fri, 23 Oct 2026 13:56:09 +0000

SOGo Webmail gives the impression that a selected .p7s file has been added as an attachment, but the file is not actually attached to the message. No visible error or warning tells the user that the attachment is missing.

This also happens when the .p7s file is the only file selected in a new message with no existing attachments. The important symptom is the mismatch between the apparent success in the composer and the actual absence of the attachment.

The original case involved letter.pdf and its detached signature letter.pdf.p7s. The PDF attaches normally, but the signature is omitted. Selecting the signature alone produces the same failure, so the problem does not require the PDF to be present or a filename collision.

The .p7s file is a detached signature for a document. It is being attached as a file, not used to sign the email through SOGo's S/MIME functionality.

Expected result:
A file that appears successfully attached in the composer must actually be included as an attachment in the message, with its original filename and contents preserved. If the file cannot be attached, SOGo must clearly display an error instead of presenting apparent success.

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

Fri, 23 Oct 2026 13:11:30 +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

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).

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?

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.