Issue SOGo CalDAV not working with Thunderbird nor OutlookCalDavSynchronizer

[Lars Appel]

Server operating system version

Ubuntu 22.04.3 LTS

Plesk version and microupdate number

Version 18.0.55 Update #1

I cant get Thunderbird nor OutlookCalDavSynchronizer to work with SOGo Webmail's CalDAV calendar on an Ubuntu 22.04 LTS server with Plesk Obsidian 18.0.55.

I tested this with Thunderbird 115.3 and Outlook 2016 + OutlookCalDavSynchronizer 4.4.1 using Windows 10.
I also tested it with Thunderbird 102.15.1 using Ubuntu 22.04 Desktop.
For now I would focus on Thunderbird as it's open source and free to use so everyone can use it for testing.
I'm also pretty sure that, it it works with Thunderbird it'll also work with Outlook + OutlookCalDavSynchronizer

Whats the Problem:
I can add the calendar to Thunderbird but the appointments are not displayed.
If a add an appointment, it is actually added the the calendar (I can see it in SOGo webmail) but it is not displayed in Thunderbird.

By going through the logs of Thunderbird (and OutlookCalDavSynchronizer) I found the Problem which is a known and fixed (in later version) bug in SOGo.
The bug in SOGo is known as ID: 0005416 with the description "sogo mysteriously adds XML-encoded UTF-8 BOM to calendar-data & getetag REPORT replies"
See here: 0005416: sogo mysteriously adds XML-encoded UTF-8 BOM to calendar-data & getetag REPORT replies - SOGo | BTS
Which is exactly what I found observing the logs.

This issue seems to be fixed in SOGo Version 5.8.0 released Nov 30, 2022 but Ubuntu 22.04 LTS still uses 5.5.1
Ubuntu 23.04 (non LTS) uses SOGo Version 5.8.0 but unfortunately it's not available thru jammy-backports.

As SOGo Webmail seams to be the only viable option Plesk currently provides allowing the use of CalDAV (Horde hasn't been updated/patched since 2020) I need to get this working somehow.

Is it Possible for Plesk to Provide a recent version (4.8.x) of the pakages "sogo-activesync", "sogo-common" and "sogo" for Ubuntu 22.04 ?
Any suggestions or workarounds that I could try?

Thanks in advance

 

[Peter Debik]

@AYamshanov

 

[Lars Appel]

Do you have any updates on this?

 

[AYamshanov]

This issue seems to be fixed in SOGo Version 5.8.0 released Nov 30, 2022 but Ubuntu 22.04 LTS still uses 5.5.1
Ubuntu 23.04 (non LTS) uses SOGo Version 5.8.0 but unfortunately it's not available thru jammy-backports.

The extension installs SOGo packages from repositories (stable from OS vendors; nightly version from the SOGo repository), it does not use any different repositories. In Plesk, we do not plan to re-pack or backport the SOGo package.

So, it means availability of the fix for "The bug in SOGo is known as ID: 0005416" (as well as new versions of other SOGo related packages) is depends on how fast new builds will be available through existing repositories.

 

[Lars Appel]

The extension installs SOGo packages from repositories (stable from OS vendors; nightly version from the SOGo repository), it does not use any different repositories. In Plesk, we do not plan to re-pack or backport the SOGo package.

So, it means availability of the fix for "The bug in SOGo is known as ID: 0005416" (as well as new versions of other SOGo related packages) is depends on how fast new builds will be available through existing repositories.

Well that's unfortunate but it is what it is. I'll se if I can get Ubuntu to update the package or contribute an updated version myself.
If that's not possible, I'll try to find a workaround and if I do I'll share it here.

The problem may be related to the server or clients settings. Ensure that the server is properly configured for CalDAV and ensure that clients are using the correct credentials and server URLs.

I don't think so, we checked the server and client settings multiple times, until we discovered that there is a bug in the Version of SOGo Ubuntu 22.04 is using.
There where some changes in the gnustep-base 1.28.0 package that made SOGo add "& #65279" (without the "") to the calendar XML data.
SOGo fixed that bug in Version 5.8 but Ubuntu 22.04 is still using 5.5.1.
As we could confirm that mysterious string as well, I am pretty sure that's the problem.