SOGo | BTS - Issues

0006244: Possible SQL connection leak/regression in SOGo/SOPE 5.12.10

Mon, 07 Sep 2026 06:53:28 +0000

Summary
=======

After upgrading SOGo and SOPE from version 5.12.9 to 5.12.10, idle MariaDB connections opened by `sogod` progressively accumulate.

The connection count does not appear to return to a small stable pool. It can eventually reach MariaDB's `max_connections` limit, after which SOGo starts returning HTTP 501 responses for multiple CalDAV and CardDAV requests and becomes unavailable.

Using the same configuration, database, workload and number of workers, downgrading SOGo and SOPE to 5.12.9 restores the previous behaviour: unused SQL connections are released and the number of connections remains stable.

All customer names, domains, addresses, credentials and public IP addresses have been replaced or omitted from this report.

Environment
===========

- Affected SOGo version: 5.12.10
- Affected SOPE version: 5.12.10
- Comparison SOGo version: 5.12.9
- Comparison SOPE version: 5.12.9
- Installation method: source build from the corresponding official Git tags
- Container base image: Debian stable-slim
- Database: MariaDB 12.3.3
- Reverse proxy: nginx
- Deployment: Docker Compose
- Number of SOGo workers: 10
- Number of mail accounts: approximately 10
- Client protocols: mainly CalDAV and CardDAV
- SOGo and MariaDB run in separate containers on the same Docker network

Both versions were tested with the same SOGo configuration, MariaDB configuration, worker count and normal client workload.

Relevant SOGo configuration
===========================

Sensitive values have been replaced with placeholders.

```
WOWorkersCount = 10;
WOWatchDogRequestTimeout = 10;
WOListenQueueSize = 50;

SOGoProfileURL =
"mysql://sogo:@mariadb:3306/sogo/sogo_user_profile";

OCSFolderInfoURL =
"mysql://sogo:@mariadb:3306/sogo/sogo_folder_info";

OCSSessionsFolderURL =
"mysql://sogo:@mariadb:3306/sogo/sogo_sessions_folder";

OCSAdminURL =
"mysql://sogo:@mariadb:3306/sogo/sogo_admin";
```

An additional SQL user source reads account information from a view in another database. Its database name, table/view name, domain and credentials have been omitted.

Relevant MariaDB configuration
==============================

The following MariaDB settings were identical during both tests:

```
max_connections = 300
wait_timeout = 3600
interactive_timeout = 3600
```

Symptoms with SOGo/SOPE 5.12.10
===============================

With version 5.12.10, idle MariaDB connections belonging to the `sogo` database user progressively increased.

The connections appeared in `information_schema.PROCESSLIST` as:

```
USER DB COMMAND
sogo sogo Sleep
```

Example measurements:

```
Time Idle SOGo connections Longest current idle time
15:00 15 535 s
15:01 16 595 s
15:02 17 655 s
15:03 18 715 s
15:05 20 835 s
15:08 23 1016 s
15:17 33 1606 s
15:18 34 1666 s
15:20 36 1786 s
15:23 38 1966 s
15:27 42 2206 s
15:29 44 2327 s
15:30 46 2387 s
15:32 47 2493 s
15:39 53 2927 s
15:40 55 2987 s
15:42 56 3108 s
15:44 58 3228 s
15:45 58 3288 s
```

The number therefore increased from 15 to 58 idle connections in approximately 45 minutes.

During the measurements, MariaDB showed very little active work:

```
Threads_running = 1
Connection_errors_max_connections = 0
Max_used_connections = 69
```

This suggests that the connections were not caused by blocked or long-running queries. Most connections were sleeping.

Production impact
=================

During an earlier occurrence, the progressive accumulation eventually reached MariaDB's connection limit.

MariaDB then logged errors similar to:

```
Aborted connection 0 to db: 'unconnected'
user: 'unauthenticated'
host: 'connecting host'
(Too many connections)
```

At the same time:

- SOGo became inaccessible;
- CalDAV and CardDAV synchronizations failed;
- SOGo returned HTTP 501 for multiple users;
- calendar, calendar inbox and address-book DAV resources were affected;
- unrelated mail components using the same MariaDB server also experienced connection failures.

The container health check could still report SOGo as healthy because a simple unauthenticated HTTP request continued to receive a response, while authenticated DAV operations failed because no SQL connection was available.

Restarting SOGo or MariaDB temporarily restored service, but the connections began accumulating again with version 5.12.10.

Comparison with SOGo/SOPE 5.12.9
================================

SOGo and SOPE were rebuilt from the 5.12.9 tags.

Only the SOGo container was recreated. MariaDB was not restarted, and its configuration was not changed.

The SOGo container reported:

```
SOGO_VERSION=5.12.9
RestartCount=0
```

The process tree contained:

```
1 sogod master
10 sogod workers
```

All workers had the same parent process and the same start time. No container or worker restart occurred during the following measurements.

Results with version 5.12.9:

```
Time Idle SOGo connections Longest current idle time
15:46 14 33 s
15:47 14 93 s
15:48 14 153 s
15:49 14 213 s
15:50 14 273 s
15:51 6 323 s
15:52 5 383 s
15:53 6 443 s
15:54 5 503 s
15:55 5 563 s
15:56 6 623 s
15:57 6 683 s
15:58 6 743 s
15:59 6 803 s
16:00 5 863 s
16:01 5 923 s
16:02 6 984 s
16:03 6 1044 s
16:04 6 1104 s
16:05 5 1164 s
16:06 6 1224 s
16:07 5 1284 s
16:08 9 1344 s
16:09 9 1404 s
16:10 9 1464 s
16:11 8 1524 s
16:12 8 1584 s
16:13 7 1644 s
16:14 8 1704 s
16:15 8 1765 s
16:16 7 1825 s
16:17 7 1885 s
16:18 6 1922 s
```

After an initial reduction from 14 connections, the SOGo connection count remained between approximately five and nine connections for more than 30 minutes under normal activity.

At the end of this observation:

```
SOGo idle connections = 6
Total application connections = 11
Threads_running = 1
Connection_errors_max_connections = 0
SOGo container restarts = 0
```

`Aborted_clients` did not increase during the 5.12.9 observation.

The increase previously seen in `Aborted_clients` occurred when the 5.12.10 container was deliberately stopped and recreated as 5.12.9. It did not continue after 5.12.9 was started.

Interpretation of MariaDB TIME
==============================

For a connection in the `Sleep` state, the `TIME` column represents its current idle duration, not its complete lifetime.

Some individual connections remained idle for more than 1,800 seconds with version 5.12.9. This is not itself considered abnormal because the total number of connections remained small and bounded.

The significant difference is the connection-count behaviour:

```
SOGo/SOPE 5.12.10:
15 to 58 idle connections, with continued growth

SOGo/SOPE 5.12.9:
14 initially, then stable between approximately 5 and 9
```

The MariaDB `wait_timeout` was 3600 seconds for both tests.

With 5.12.9, most unused connections were released after approximately five minutes, well before the MariaDB timeout. With 5.12.10, the number continued increasing while older idle connections remained present.

Database monitoring query
=========================

The same query was used for both versions:

```sql
SELECT
NOW() AS measurement,
COUNT(*) AS connections,
MIN(TIME) AS shortest_idle_time,
MAX(TIME) AS longest_idle_time,
SUM(TIME >= 3300) AS near_timeout,
SUM(TIME >= 3600) AS beyond_timeout
FROM information_schema.PROCESSLIST
WHERE USER = 'sogo'
AND COMMAND = 'Sleep';
```

Global MariaDB status was monitored using:

```sql
SHOW GLOBAL STATUS
WHERE Variable_name IN (
'Threads_connected',
'Threads_running',
'Max_used_connections',
'Connection_errors_max_connections',
'Aborted_clients',
'Aborted_connects'
);
```

Expected behaviour
==================

SQL connections opened by a fixed number of `sogod` workers should be reused or released. The total number of connections should remain bounded under a small and stable workload.

Actual behaviour
================

With SOGo/SOPE 5.12.10, idle SQL connections progressively accumulate. During a previous occurrence, they contributed to exhaustion of MariaDB's connection limit and caused DAV requests to fail.

With SOGo/SOPE 5.12.9, using the same configuration and ten workers, the SQL connection count quickly decreases and remains bounded at approximately five to nine connections.

Steps to reproduce
==================

1. Configure SOGo with a MariaDB backend and multiple standard SOGo database URLs.
2. Configure ten `sogod` workers.
3. Start SOGo/SOPE 5.12.10.
4. Generate normal CalDAV and CardDAV activity from several user accounts.
5. Monitor sleeping connections for the `sogo` MariaDB user.
6. Observe that the number of idle connections progressively increases.
7. Rebuild SOGo and SOPE from the 5.12.9 tags without changing the configuration.
8. Recreate only the SOGo container.
9. Repeat the same monitoring under normal client activity.
10. Observe that the number of idle SOGo connections decreases and remains bounded.

Possible affected component
===========================

The issue may be related to SQL channel retention, reuse or cleanup in SOGo/SOPE 5.12.10, possibly in the GCS channel manager or MySQL/MariaDB channel implementation.

Questions
=========

Could you please confirm:

1. Whether SQL channel management changed between SOGo/SOPE 5.12.9 and 5.12.10?
2. Whether there is a known regression affecting MySQL/MariaDB connection cleanup?
3. Whether a new configuration option is required in version 5.12.10?
4. Whether additional debug logging can be enabled specifically for GCS or SQL channel allocation and release?

Complete sanitized configuration files, longer monitoring data and debug logs can be provided if required.

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

0006168: Signature duplication when switching identities while composing email

Mon, 20 Jul 2026 08:40:36 +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.

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.

0006231: Conversation threading is broken: replies are displayed as separate messages instead of a single thread

Mon, 13 Jul 2026 12:45:08 +0000

When using SOGo (via Mailcow), email conversation threading does not work correctly. Replies to an existing email are displayed as separate messages in the inbox rather than being grouped into a single conversation.

The expected behavior is that SOGo should group all messages belonging to the same conversation using the standard email headers (Message-ID, In-Reply-To, and References), similar to Gmail and other modern email clients.

This issue makes it difficult to follow email conversations because every reply appears as a new entry in the message list.

0006230: Events can't be created when language is set to Japanese

Mon, 13 Jul 2026 11:52:50 +0000

The default short data format "01-Jul-26" gets translated to "01-7月-26" which fails validation. Clicking on the date opens an empty almost no-width dropdown with nothing to select. There is no way to input a correct date and therefore no way to save the event.

Opening the browser console shows the following errors after clicking:

TypeError: e.getFullYear is not a function
Angular 23
angular.js:15697:16
TypeError: t.getDate is not a function
Angular 34
angular.js:15697:16
TypeError: t.getDate is not a function
Angular 34
angular.js:15697:16
TypeError: t.getDate is not a function
Angular 34
angular.js:15697:16
TypeError: t.getDate is not a function
Angular 34
angular.js:15697:16
TypeError: t.getDate is not a function
Angular 34
angular.js:15697:16

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

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

Summary:
When a user attempts to export a mail folder via the web UI ("Export" on a mailbox/folder) where the resulting archive is roughly 14-16 GiB in size, the export fails after approximately 19-20 minutes. The browser is redirected back to the inbox with a generic "nginx cannot connect to upstream" error page.

Root cause (as best I can determine):
The nginx access/error logs show SOGo returning an invalid, negative Content-Length header once the export completes:

nginx-mailcow-1 | 2026/07/01 16:27:11 [error] 18#18: *476769 upstream sent invalid "Content-Length" header: "Content-Length: -1778931325" while reading response header from upstream, client: [redacted], server: [redacted], request: "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/2.0", upstream: "http://[redacted]:20000/SOGo/so/[user]/Mail/0/folderINBOX/exportFolder"

nginx-mailcow-1 | [redacted] - - [01/Jul/2026:16:27:11 +0100] "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/2.0" 502 2015 ...

sogo-mailcow-1 | Jul 1 16:27:11 [container] sogod [99]: [ERROR] <0x...[WOHttpTransaction]> client disconnected during delivery of response for (len=0): the socket was shutdown

sogo-mailcow-1 | Jul 1 16:27:11 [container] sogod [99]: [redacted] "GET /SOGo/so/[user]/Mail/0/folderINBOX/exportFolder HTTP/1.1" 200 0/0 1253.452 - - 103M - 15

The reported Content-Length value (-1778931325) is consistent with a 32-bit signed integer overflow: adding 2^32 to that value yields approximately 2.34 GiB, which strongly suggests the export archive's byte size is being stored/reported in a 32-bit signed integer field, wrapping to a negative value once the true size exceeds 0000015:0000002 GiB (2,147,483,647 bytes). nginx correctly rejects the resulting header as invalid, which surfaces to the end user as a generic 502/connection failure with no indication of the true cause.

Expected behavior:
The export should either complete successfully regardless of size, or SOGo should stream/chunk the response (e.g., via chunked transfer encoding) rather than relying on a Content-Length value that appears to be limited to a 32-bit signed range.

Additional notes:
- We ruled out request timeouts (WOWatchDogRequestTimeout was raised from the default and the failure still occurred at the same point, 0000018:0000019-20 minutes in, consistent with export size rather than time elapsed).
- We ruled out memory exhaustion (SxVMemLimit raised; no OOM kills observed via docker stats/dmesg during the failed export).
- nginx's own proxy/read timeouts are already set to 3600s in our configuration, ruling out nginx-side timeout as the cause.

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

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

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

But`apt update` reports error yesterday:

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

Questions:

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

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

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

I setup SOGo using MySQL authentication:

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

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

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

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

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

0006112: Automatically add external meeting invitations to calendar

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

Dear SOGo team,

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

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

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

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

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

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

Thank you very much for your time and great work!

Best regards,
Anton Sapanovskiy
Bug Tracker Username: sapanovskiy