Hi Sven,
Ansible lineinfile only means to change one line matching the regex. So the file /usr/sbin/guam is not a copy of the executable but just plain text marked as executable:

Thanks for testing! I am not firm with ansible and got problems to follow your instructions...

Hello folks,
good news. I managed to restore functionality on my systems with a workaround. I just copied the old versions of guam-libs and erlang-eimap and adjusted it's executable /usr/sbin/guam . Afterwards login is possible again and iRony is working. The old and new versions will reside next to each other in the libs folder. Any update of guam will disable the workaround but leave the old versions around so we have to delete them then.
Unfortunately I'm not an erlang programmer nor understanding the whole architecture well enough to actually provide a fix for the most recent version.
But now that we know the bug is definitely in one of these two packages, maybe someone else can?
Have a nice weekend

Guam logs:
2020-11-07 07:20:13.817 [error] <0.396.0> Supervisor {<0.396.0>,kolab_guam_listener} had child session started with {kolab_guam_session,start_link,undefined} at <0.18081.1> exit with reason no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in context child_terminated
2020-11-07 07:20:13.818 [error] <0.18185.1> gen_server <0.18185.1> terminated with reason: no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178
2020-11-07 07:20:13.819 [error] <0.18185.1> CRASH REPORT Process <0.18185.1> with 0 neighbours exited with reason: no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in gen_server:terminate/7 line 826
2020-11-07 07:20:13.819 [error] <0.396.0> Supervisor {<0.396.0>,kolab_guam_listener} had child session started with {kolab_guam_session,start_link,undefined} at <0.18185.1> exit with reason no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in context child_terminated
2020-11-07 07:20:13.819 [error] <0.18130.1> gen_server <0.18130.1> terminated with reason: no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178
2020-11-07 07:20:13.819 [error] <0.18130.1> CRASH REPORT Process <0.18130.1> with 0 neighbours exited with reason: no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in gen_server:terminate/7 line 826
2020-11-07 07:20:13.819 [error] <0.396.0> Supervisor {<0.396.0>,kolab_guam_listener} had child session started with {kolab_guam_session,start_link,undefined} at <0.18130.1> exit with reason no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in context child_terminated
2020-11-07 07:20:13.826 [error] <0.18128.1> gen_server <0.18128.1> terminated with reason: no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178
2020-11-07 07:20:13.826 [error] <0.18128.1> CRASH REPORT Process <0.18128.1> with 0 neighbours exited with reason: no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in gen_server:terminate/7 line 826
2020-11-07 07:20:13.826 [error] <0.396.0> Supervisor {<0.396.0>,kolab_guam_listener} had child session started with {kolab_guam_session,start_link,undefined} at <0.18128.1> exit with reason no match of right hand value {error,closed} in kolab_guam_session:accept_client/1 line 178 in context child_terminated

Happens as well on CentOS 7 after installing the current guam update guam-0.9.8-1.3.el7.kolab_16.x86_64

I did some more testing with roundcube debug on:

Webmail interface shows the following message:

I am now seeing this as well, opened a new issue: T6073

I really need help with roundcube ...

Manually placing this file on my server resolved the issue for me, thanks for the quick response!

I just realized that the file has been lost when I did the manual merge. So, It was my fault. Fixed in d6660105443ff5. A new package will take a while.

Ouch. @fjl could you provide the missing file.

Looks like this commit is to blame: https://git.kolab.org/rI1ef542efa9983a0c32ce182e33b597d4649a7dcd

Looking at the email source the for the invitation there's this part (IDs changed, so it's not proper link to test with):

@sicherha-admin

If you're doing the DKIM signing with amavis, here's a possible fix (taken from https://git.dotlan.net/dhoffend/ansible-role-kolab/blob/master/templates/amavis/65-dkim.j2#L17):
$signed_header_fields{'received'} = 0;

I didn't know that wallace created generate calender placeholder. Do they have an update for this? Hoping that they fix it as soon as possible.

https://www.google.com/

Any thoughts about how to fix this issue?

we are at kolab 3.4 . during creating new user Archive folder is not getting created.. Initially it was creating only Inbox. after doing repair of annotations.db from twoskip to skiplist . It again started created all folders except Archive. Need the solution.

I've had this problem on debian 8,9 and 10

This driver is not a high prio for us. Patches welcome.

Currently, the calendar uses the database backend:

The new_event method starts in database_driver and it starts _update_recurring. In this _update_recurring there is a calendar_recurrence object that creates Horde_Date_Recurrence on initialization where the problem is. :)

Yes, it using plugins/calendar/drivers/database/database_driver.php.

Ok, I was testing a different case. However, this case also works with Kolab backend. I assume that you're using the database driver. Is it right?

Any info? :) Is there anything I can help you to resolve this bug ?

Did attached screen help you repeat the error?

I think that the screen from the application will explain the problem better :)

It works for me with Kolab backend, although the event info dialog displays "Repeat: Every 1 month(s), forever ". When I edit the event Recurrence form looks correct and the event is displayed properly on the 3rd Thursday as defined. So, I see only a problem with the "Repeat" text not being complete.