• Schedule db:expunge command

No, I tried registering handlers for Queue::JobProcessing and Queue::jobProcessed events via AppServiceProvider::boot(). The handlers were triggered, but the job object there is not the same as our job, and access to the job data requires instantiating the actual job from a serialized object string. Possible, but ugly.

Looks good. I suppose you tried something like this: https://git.kolab.org/rKa3448e46572c9bcba39702689d31e77bfeaa1d26, but it didn't give access to the email/walletId?

The message header is parsed!

As the fix sets encoding="utf8", does this mean all messages are utf-8 encoded here?

• Invitations policy
• Split itip handling into per-method classes

A test for IMAP::clearMailbox() would be appreciated.

Looks to me that the folders passed to the command need to be in Cyrus internal format user/{$localpart}/{$mailbox}@{$domain}. That's not very user-friendly. Also tests for the new IMAP methods would be welcome, less important for the command itself.

It's good enough, but I added some comments.

This diff consists of multiple commits that I've used for the migration. Since we're already using it like this I'd like to mostly just get it merged, but I'm open to small adjustments (the rest we can improve later on IMO).

Cleanup

You asked for hints!
The crash should not happen, but there are still to much variables included.
I just analyzed, the information I had.

• Don't require specific file name

• Support multipart/form-data file uploads, they don't need so much memory

I think for some of these jobs we should probably keep trying at an hourly or even daily interval. So if we e.g. have infrastructure issues over a couple of hours the system still eventually recovers without manual intervention.

this link of yours https://kb.kolab.org/2023/03/install-kolab-16-on-alma-linux-9/solar smash The package is missing when doing dnf install kolab.

• Set back SWOOLE_PACKAGE_MAX_LENGTH to 10MB

Yes, the user hr1@os-s.de does not exist in the LDAP. It is not a vaild usser. Therefore no authentication is possible. But this should not be a cause for saslauthd to fail and terminate, am I correct?
The kolab-saslauthd terminates. I reconfigured systemd to automatically restart the daemon because otherwise the login would fail for valid users as well.