SOGo | BTS - Issues

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

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

Mon, 17 Aug 2026 13:55:58 +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

0006237: Certificate for demo.sogo.nu is invalid

Mon, 17 Aug 2026 08:48:32 +0000

Since 2026-08-13 the certificate for the SOGo demo site is invalid. (see screenshot).
Please change it to a valid one.

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.

0006235: Vacation message : one day difference with sieve script

Tue, 04 Aug 2026 17:07:14 +0000

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

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

0006067: User option to automatically add external invitations to personal agenda

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

Is there a way to add this, when invitations come from outside SOGo-managed domains, like Gmail does ?

It seems not possible to do this if a user is not connected on webmail, because it needs an active IMAP connexion.
But it would be nice to activate this as soon as a user reads an email where SOGo detects invitations, instead of relying on user interaction (buttons Accept / Decline / etc.).

Is it already on a roadmap ?

0006227: Broken encoding of display names containing a comma and square brackets

Thu, 02 Jul 2026 06:32:03 +0000

We have many users who use the format

, [department]

as their sender name (preferences: "Full Name").

SOGo does not quote the "display name" [see RFC 5322: https://www.rfc-editor.org/info/rfc5322/#section-3.4] (which is probably correct because it's not required here, I guess) when sending new messages or responding to messages with such a sender name. Instead it uses the "Q encoding" as transfer-encoding [see RFC 2047: https://www.rfc-editor.org/info/rfc2047/#section-4.2].

When encoding the display name the comma is interpreted as separator of multiple addresses and since the part before the comma is not a valid email address, "@MISSING_DOMAIN" is appended here to mark the "address".

The same display error occurs when the message was sent from a different mail client which does not quote the display name.
It does not occur (in the first place) when the display name is quoted (as e.g. Thunderbird does). But it does in replies to such messages: the recipient of the reply works when sending the message, but it's wrongly displayed when opening the reply in SOGo.

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

Wed, 01 Jul 2026 07:56:35 +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

0006118: Build packages for CentOS Stream 10?

Thu, 25 Jun 2026 08:54:05 +0000

Dear all,

CentOS Stream 10 was released in Dec 2024, any plan to build packages for it?

0006226: Wehn password recovery is not enabled, the login page returns 403 for the url "/SOGo/so/passwordRecoveryEnabled"

Tue, 23 Jun 2026 08:45:50 +0000

This is not optimal, as some servers are using 403 code to trigger IP address ban.
I suggest to use 204 instead, meaning "no content"