Setting use_https to true does has not the desired effect. The created URL now contains the scheme "https", but it still uses port 80. Other parts of the application now complain about errors like this one:

That's the problem. The error in question hasn't happened to me, so i don't know the exact steps to reproduce. What I've heard is that "it just happens automatically". When the recipient gets the calendar invitation email, the placeholder event is automatically created in the calendar (per kolab policy settings), and when the recipient user tries to accept/reject the invitation from the kolab roundcube webmail *calendar* application he gets the Internal Server Error and the PHP Fatal Error and the stack trace I posted can be found from the logs.

Fixed. You now would need to set use_https to true or file_api_uri to full chwala api path.

The fix is in roundcubemail-plugins-kolab repo.

Fixed in rRPKce9ac27d783d.

Looks like rC21f6abd52a929 broke compatibility with Roundcube 1.2. Looks like we have now 3 options:

1. Revert the change and wait with Roundcube 1.3 support until it's in Kolab, then apply it again
2. Copy blank.tiff to blank.tif in roundcubemail package
3. Use chwala URL to access these files.

But this object has valid dates. So, how do I reproduce the issue?

I hope I didn't screw up the xml while removing private info.. but here goes:
http://pasik.reaktio.net/kolab-webmail-calendar-internal-server-error.xml

I can't reproduce the issue by importing the .ics file. Could you provide the object in xml format (i.e. the message from imap folder)?

Sorry took a while, but now it happened again..:

Net_Sieve taken over. So, we can keep using pear/Net_Sieve. Note that for PHP7 support version 1.4.0 is required.

https://github.com/pear/Net_Sieve/pull/5 for reference. However, I'll try to take over the package and backport our fixes to it anyway.

The original Net_Sieve author abandoned the package and didn't want to fix it. That's why we forked. As for the pdo, openssl, session, json, pcre, these are php extensions, I didn't check package names for them.

Roundcube 1.2:

• don't require pear's MDB2, Mail_mimeDecode, nor DB,
• don't require php-mcrypt,

An update (-kolab6) should be available for both libkolabxml and libkolab (or php-kolabformat and php-kolab respectively).

Fixed.

Fixed.

On PHP7 (Ubuntu Xenial) we see:

[10-May-2017 12:57:43 Europe/Berlin] PHP Deprecated:  Methods with the same name as their class will not be construc
tors in a future version of PHP; Net_Sieve has a deprecated constructor in /usr/share/php/Net/Sieve.php on line 93
[10-May-2017 12:57:43 Europe/Berlin] PHP Warning:  array_merge(): Argument #1 is not an array in /usr/share/php/Net/
Sieve.php on line 312

these are fixed in the Roundcube's fork of Net_Sieve. We should provide that in packaging.

apt-get install kolab works with Winterfell repository. I think it is misleading to have instructions for Kolab 16 at https://docs.kolab.org/installation-guide/index.html. So, we should fix the packages or remove that part of documentation.

Sorry, I was too fast. It installed only postfix and stopped. It also fails on kolab-webadmin.

The following packages have unmet dependencies:
 kolab-webadmin : Depends: libapache2-mod-php5 which is a virtual package and is not provided by any available package.

I am getting this issue on vanilla Kolab 16 installation but after dropping the policy_result table it gets recreated.

The best would be to see the whole message. You can remove private data.

Which parts of the XML are important? I can try to find it..

Is there a chance we can see the original event data in XML form or as iCal export? Anyway, I suppose a needed fix here will be to remove the timezone string in brackets before passing it to the DateTime constructor.

Just in case, more rpm versions:

So the actual issue seems to be if there are multiple recipients in the calendar invitation email then wallaced only creates the placeholder calendar event for the *first* recipient only.

Yes, i'm pretty certain this is the actual issue i've been seeing.

Sounds like a bug. So, this is the explanation of the initial issue, yes?

Another test was now done by sending a calendar invitation from Exchange 2010 to Kolab 16.1.

Oh, it seems --debug=8 syntax doesn't seem to work. This works instead:

This seems to be related to what email platform the sender is using. I tested the same procedure using google gmail.com as a sender, and kolab seems to work properly in that case, and updates the not-yet-accepted calendar invitation just like it should.

Yeah, with *_SAVE_AND_FORWARD it should probably update existing unresponded invitation event.

Done in 99cd2b17522.

Actually the change need to be backported from master to roundcubemail-plugins-kolab-3.2 branch.

To reproduce the issue just try to rename a file over WebDAV.

So same issue, with slightly different results: multiple commands sent together, which is allowed by the IMAP spec indeed, and then the client ends up waiting for responses that do not come as expected. Thanks for the report.

I've encountered another bug with guam. This time It's "eM Client" for Windows. I've activated the client debug log (in eM Client) and after sending a XLIST and SELECT command in TLS/SSL mode (it looks like the client sends 2 commands at once) the connections gets into some kind of stale mode. It's no longer working. Hard to tell without decrypting network traffic.

I was able ro reproduce the error:

1. I received a meeting invite.
2. I accepted the invite
3. I clicked Update in my calendar.
4. The webinterface showed saving for about 3 minutes

4.1 Mail and calendar was locked during this time

5. After recovery 3 minutes mail was working and the calendar was updated

Are there any other related patches? I searched and was unable to locate similar issues.

I'm not able to reproduce the issue anymore.

This was fixed in 66310b2fc46138.

Still considering what to be done with this.

Connecting with cli imap client "mutt" you can see this behavior because it always presents the full folder list (in the left folder view (patched) version as well when you want to switch the folders.

I could narrow it a bit down towards multiline input (IMO). The single commands are processed and filtered correctly. In the moment you or the client issues multiple IMAP commands at once guam isn't able to intercept and split it correctly.

I spoke too soon, after posting the above comment, the system would not allow me to log in. No calendar entries we made by anyone.

I have implemented T1988 patch, and the problem cannot be replicated.

@vanmeeuwen No, this is not a duplicate. The issue still persists with pykolab code from git-master. See Bifrost T16075 for the same issue.

This should be documented here, shouldn't it?
https://docs.kolab.org/upgrade-guide/kolab-16.html

This is likely a duplicate of T1988

The patch for the plugin package in Kolab:16 is waiting for review

I have the same syptoms on a fully updated kolab16 on centos7.
Rebooting the sever starts things going for a while until ldap is blocked again.
If it happens Roundcube login does not work and sending mails via kontact is blocked.

Hi machniak, the current build 16 that we are using already has the fix:
https://git.kolab.org/rP54cb493d655bb67719572acd934994161c3751af

We need more recent roundcubemail-plugins-kolab package.

According to Florian Eder, this has been tested and is working.