Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

As the 750+ packages are now rebuilding, I'm going to declare this issue as resolved. Please reopen / create a new ticket should some discrepancies persist.

Now that we have the GPG key thing in the OBS sorted, perhaps it is time to rebuild all of Kolab:16 indeed, and refresh what is referred to as community.asc.

So, that got poked in the face... Happy bug-hunting!

I don't remember where to do this in a way that fixes it permanently, so I've hot-fixed it.

@machniak; since we can reproduce this on webmail.kolabsys.com, I can verify there's no discernible error in the console.

In T4241#62348, @rsc wrote:

Closing this as invalid is not nice.

Disabled registration through third part providers, disabled trusting email addresses associated with those providers.

We currently have a problem with the OTP-20 compatibility of most of the erlang packages. Who would have guessed?

The week number is already included in the miniature calendar on the left-hand side, for both month and week views.

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

This can be reproduced reliably.

This should now be resolved, please verify.

I don't know what to do about it, to be honest. There doesn't seem to be any modules or settings that protect against this type of thing, as far as I could find.

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).

A few more remarks.

In D577#6587, @machniak wrote:

In send_update_notification() we send mail in a loop trying up to 5 times if an error occurrs. But this is the only place where we do this. I think it would make sense to do this in all cases, i.e. in _sendmail(). I see also we don't call smtp.quit() consistently. Once we do this on success only, once we do this on error too.

Looking good, except for the corner-case of an errmsg over an un-"captured" exception.

May I have a reference?

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