SOGo | BTS - Issues

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

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

Wed, 07 Oct 2026 12:29:24 +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

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.

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.

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