I have no idea. @rsc check browser console for errors.

There was an upstream ticket that has been closed. https://github.com/roundcube/roundcubemail/issues/6376

@rsc; what is the size of the real estate so we can attempt to reproduce?

This can be reproduced reliably.

Confirmed.

This should now be resolved, please verify.

oh, I was to overhasty. The patch still works, it was my mistake. This should be altered in the function "find_resource":

is there anyghing new about that?
I just tried to apply the patch to an actual kolab 16 with

In T2289#37694, @vanmeeuwen wrote:

The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.

Raising priority. Come on, please fix this - it's ridiculous!

Renaming the mailbox works as intended -- if the result attribute value changes, then so must the mailbox name. This is an effect of the username canonification processes applied in webmail+friends and Cyrus IMAP itself (using ptloader).

Fixed. Thanks for the report.

Duplicate of T4049.

The free-busy max. 16 weeks in the Future are "hard-coded" in /usr/share/kolab-freebusy/lib/Kolab/Freebusy/Utils.php
in the static functions periodEnd and periodEndDT the amount of weeks is set to 16 weeks. You can easy set this value to any other like 53 weeks for a whole year.

See above for a patch that implements option 2.

The above patch was the simple part; now we need a script that gets called when the package is upgraded and drops the respective tables. I assume it's okay to drop the tables whenever the PyKolab package gets an update - please veto if you disagree.

Okay, so we have to modify the database schema. In https://kolab.org/hub/topic/260/google-mails-rejected/4 it is suggested that the statistic table should also be altered, which looks plausible to me.

Raising priority because this bug causes data loss: emails are getting rejected.

I guess it's resolved.

Also, the download button points to https://git.kolab.org/tag/bug_reports/ while the image to its left directs to the correct URL.

This issue appears to be fixed on the client side, so I'm closing it.
On my test system, Kontact 5.7.3 identifies as "Kontact Kolab Resource 5/KOLAB".

I'm interested in this as well.

This can be done using the keyfile option.

I cannot reproduce the bug described in the first posting, so I'm closing this as resolved. Feel free to reopen this task if I've overlooked something.

By the way, OBS has an unfortunate tendency to get stuck when a lot of build jobs exist - such as right now. Maybe that issue is fixed in a newer OBS version as well?

Thanks for the detailed report. I'm working on getting this fixed.

Unfortunately it doesn't. I agree that using HTTPS should mitigate the MitM risk, but I still have to explicitly mark the repository as trusted for APT to accept it.

The weakness in SHA1 is a collision risk, not an active compromise vector.

Playing around with a custom-created key (osc signkey --create home:sicherha:Testproject) still yields a repository signed with SHA1 only.

Bumping priority because I'm getting closer to providing packages for Debian Stretch.

Temporary workaround:

1. Mark repository as [trusted=yes]
2. Follow https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872543#10
3. Hope you don't get MitM'd

This bug has been fixed for a long time - see https://obs.kolabsys.com/package/rdiff/Kolab:16/pykolab?linkrev=base&rev=18.