Now I see where's the problem:

1. @vanmeeuwen, a side of the main reason of the issue (see below). There must be some bug somewhere because imap SELECT on a folder that has 'lr' for anyone should not fail.
2. If you consider this code

# exclude shared and other user's namespace
if ns_other is not None and folder.startswith(ns_other) and '_delegated_mailboxes' in user_rec:
    # allow shared folders from delegators
    if len([_mailbox for _mailbox in user_rec['_delegated_mailboxes'] if folder.startswith(ns_other + _mailbox + '/')]) =
        continue
# TODO: list shared folders the user has write privileges ?
if ns_shared is not None and len([_ns for _ns in ns_shared if folder.startswith(_ns)]) > 0:
    continue

You will see that if user_rec['_delegated_mailboxes'] is not set (which is the case here) no other user folders will be excluded. So, my proposed fix is:

--- a/wallace/module_invitationpolicy.py
+++ b/wallace/module_invitationpolicy.py
@@ -796,7 +796,9 @@ def list_user_folders(user_rec, type):

No, user smith@domain.tld doesn't have any delegates in LDAP.

Or to be more precise (according to the traceback). It does not even tries to write to the folder, but just tries to select it (and then search for an object). I'm not sure why select fails while the folder is 'lr'.

Is there delegation setup between these users? For me it looks like there is, but delagtor's calendar folder is non writable and the code does not check that trying to write to it.

@vanmeeuwen, this is still broken. Could you take a look?

Fixed in 6046b4085ae.

The code that does not support these is:

$subnet = ip2long($subnet);
$mask = -1 << $bits;
$subnet &= $mask;  // just in case the supplied subnet wasn't correctly aligned
if (($ipbin & $mask) == $subnet) {
    return true;
}

in Utils::checkIpRange().

Fixed by 0c02d0d45c6 in roundcubemail-plugins-kolab [master].

I verified with the code that if the original event would specify SCHEDULE-AGENT=CLIENT for the attendee it would be properly recognized by SabreDAV classes and the CANCEL would not be sent. So, what we need is to store this initial SCHEDULE-AGENT value in custom properties of Kolab format (or extend the format of https://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Attendee).

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

Could be. I've tried to create new meeting and looking at the Caldav I see that ATTEDEE is:

ATTENDEE;CN=ks@fsi.io;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:
 mailto:ks@fsi.io

So looks like SCHEDULE-AGENT is gone.

However, https://tools.ietf.org/html/rfc6638#section-3.2.1.2 says that CANCEL is sent when an event was modified and previous scheduling was done by the server (default if SCHEDULE-AGENT is not specified). So, probably the issue is in recognizing the previous state.

@vanmeeuwen, what's your take on this?

Hmm, the user who has been reporting this issue uses some mobile email client in addition to the kolab roundcubemail, so it *might* be related to mobile client, but I'm not sure really..

Any thoughts/plans about fixing this issue? Users hit this issue very often, because currently kolab auto-updates only the *first* recipient calendar..

I can confirm that. In my test it does not find messages even if they use UTF-8/8bit encoding, i.e. no decoding is required. Maybe squatter handles that better, I don't know.

Still can't find the way to reproduce the issue. Another source informed us that it had the same issue and there was CalDAV client involved. I reviewed the code and I don't see what actions could lead to such invalid timezone entries. Here's a patch that we could use, but I think the issue is in another place:

--- a/plugins/calendar/calendar.php
+++ b/plugins/calendar/calendar.php
@@ -1974,6 +1974,8 @@ class calendar extends rcube_plugin
    */
   private function write_preprocess(&$event, $action)
   {
+    $event['start'] = preg_replace('/\s*\(.*\)/', '', $event['start']);
+    $event['end']   = preg_replace('/\s*\(.*\)/', '', $event['end']);
     // convert dates into DateTime objects in user's current timezone
     $event['start']  = new DateTime($event['start'], $this->timezone);
     $event['end']    = new DateTime($event['end'], $this->timezone);

That looks like simple mistake in the code. Fixed in rRPKc2e8cc16abf3.

I was investigating a similar case - create event in Gmail and invite 2 attendees - one for user with Outlook and one for user in Roundcube. Both accept the invitation, but user who accepted it in Roundcube is not marked with a check box in Gmail.
it turns out, that Roundcube sends possibly wrong DTSTAMP in meeting acceptance iTip. Comparing responses I noticed that original invitation from Gmail has

METHOD:REQUEST
DTSTAMP:20170627T054332Z
CREATED:20170627T054331Z
LAST-MODIFIED:20170627T054331Z

Acceptance iTip coming from Outlook has:

METHOD:REPLY
CREATED:20170627T054452Z
DTSTAMP:20170627T054452Z
LAST-MODIFIED:20170627T054452Z

But Roundcube sends iTip with:

METHOD:REPLY
DTSTAMP:20170627T054331Z
CREATED:20170627T054331Z
LAST-MODIFIED:20170627T054331Z

It is one second behind from DTSTAMP value in invitation. If I send exactly the same response as Roundcube did, but modify DTSTAMP to be at least the same value as it was in invitation, then Gmail records the status of the attendee.
RFC5545 says that:

In the case of an iCalendar object that specifies a "METHOD"
property, this property differs from the "CREATED" and "LAST-
MODIFIED" properties.  These two properties are used to specify
when the particular calendar data in the calendar store was
created and last modified.  This is different than when the
iCalendar object representation of the calendar service
information was created or last modified.

I'm not sure I fully understand what they want to say here, but to me it looks like:

• DTSTAMP in REPLY should be later than it was in REQUEST
• DSTAMP should be different from CREATED and LAST-MODIFIED

Fixed.

no, I didn't

@adomaitis Looks like both DayOfWeek and Until are optional. In this case I think we just should not include DayOfWeek in the response. Did you test that?

PS: I saw that you're the one managing the packages (kolab-plesk) for the Plesk extension, that's why I ended up here. However, if that's something Plesk has to deal with, please let me know.

I understand that and I don't expect you to support 3rd party repos. I asked if it would be possible to change the dependencies to support higher PHP versions on CentOS 7.3 instead of limiting to PHP 5.4 only.

Third party repositories like Remi's are not supported.

Not exactly the same error, but we have already T2163.

1. So, the iTips differ not much. I don't think CLASS:PUBLIC is relevant.
2. I think it's possible. When the event time changes client could request "re-sheduling". You'd need to see what's in G's iTip in step 4.

In T2504#37355, @machniak wrote:

We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.

Back to your questions:

1. No idea. Check Itip payload.

Event which doesn't make GMail Calendar record attendee status as accepted

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN
CALSCALE:GREGORIAN
METHOD:REPLY
BEGIN:VEVENT
UID:i698fn56cjct6tvjt3sfa2m6j0@google.com
DTSTAMP:20170621T091446Z
CREATED:20170621T091446Z
LAST-MODIFIED:20170621T091446Z
DTSTART:20170622T040000Z
DTEND:20170622T050000Z
SUMMARY:KS Demo =C4=97
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
SEQUENCE:0
TRANSP:OPAQUE
STATUS:CONFIRMED
ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA=
NT;CUT
 YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld
ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com
END:VEVENT
END:VCALENDAR

Event which makes GMail record attendee status

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN
CALSCALE:GREGORIAN
METHOD:REPLY
BEGIN:VEVENT
UID:i698fn56cjct6tvjt3sfa2m6j0@google.com
DTSTAMP:20170621T091716Z
CREATED:20170621T091446Z
LAST-MODIFIED:20170621T091716Z
DTSTART:20170622T040000Z
DTEND:20170622T060000Z
SUMMARY:KS Demo =C4=97
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
SEQUENCE:0
TRANSP:OPAQUE
STATUS:CONFIRMED
CLASS:PUBLIC
ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA=
NT;CUT
 YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld
ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com
END:VEVENT
END:VCALENDAR

We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.

1-3 is fixed via merged D204.

Search for files with content "FLE Daylight Time" in /var/spool/imap/domain/ and provide a sample file.

Any tips how to best debug this issue?

Fixed.

Fixed.

Fixed.

Page refresh should fix the issue. This is a regression that is not so simple to fix. My first take on this failed.

While using constant folder identifiers would be good long term solution, in meantime I've found a simpler way. With rS57c38b7aede3 the device will correctly handle folder renames and re-synchronize folder hierarchy and renamed folder content. Closing.

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.

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

No, K16 is enough

Fixed in:

• chwala e412536b1b6 [master] and 04ff2737dc [chwala-0.4].
• roundcubemail-plugins-kolab f357819dd0 [master].

The issue with emails is a user-confusion issue: you get an email with an attachment, you save that attachment "to the cloud", and now the time is oddly different than the email. So it isn't that there is a bug with emails, but that the time differences cause problems for users.

I have pushed a commit to the feature/autodetect_ipv6 branch which turns on keepalive for the socket; there is a corresponding fix on the eimap (imap server connection code) side as well, though I'm not sure that is needed. Hopefully that will resolve the issue as it will try to keep the socket up as long as the other side is still there according to the OS settings for these timeouts. by default on Linux it is 2 hours, which should be plenty.

I'm not sure what issue do you have with email, but files are indeed stored with timestamps in UTC. The plugin displays the date as-is provided by chwala. It will be chwala's responsibility to convert it to user timezone (if provided). The timezone would need to be passed by Roundcube to chwala first.

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

It turns out mozldap ldapsearch tool uses nssdb for certificate verification and you can't turn it off. That means, that for mozldap ldapsearch you need to create nssdb databases and put ca certificate into this DB to make it work, otherwise you will get SSL initialization failed: error -8015 (unknown) error.
These are the steps I did:

Run mozldap ldap search with SSL enabled:

# /usr/lib64/mozldap/ldapsearch -x -h ldaphost -p 636 -b 'ou=People,dc=domain,dc=tld' -s base -D 'cn=Directory Manager' -w - -J '1.3.6.1.4.1.42.2.27.9.5.2:true:dn:cn=Directory Manager' '(objectclass=*)' -Z
SSL initialization failed: error -8015 (unknown)

Notice -Z at the end of commnd

Create NSSDB:

# certutil -N -d /path/to/nssdb

I used empty password for the database. Verify that it is created:

# certutil -L -d /path/to/nssdb

That is what I thought, but:
-H display usage information
mozldap ldapsearch is a bit different from openldap ldap client tools.

We should try to use -H instead of -h and -b for ldapsearch.

This could be more complicated than that. Unfortunately don't have enough time to investigate it deeper, but the above patch may influence how ldapsearch command is being issued by WAP. With the following patch I can login to WAP , but navigating inside WAP is inconsitent - sometimes shows user, sometimes not.

[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [INFO] (api) Vendor name is 389 Project
[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [DEBUG] (api) LDAP: Executing command: /usr/lib64/mozldap/ldapsearch -x -h ldaps://ldap.server:636 -p 636 -b 'ou=People,dc=domain,dc=tld' -s base -D 'cn=Directory Manager' -w * -J '1.3.6.1.4.1.42.2.27.9.5.2:true:dn:cn=Directory Manager' "(objectclass=*)" "*"
[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [DEBUG] (api) LDAP: Command output:array (
)
[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [DEBUG] (api) Return code: 91

This ldapsearch command doesn't work from command line either:

ldap_simple_bind: Can't connect to the LDAP server - Invalid argument

I may have some time later to look deeper into what is happening.

Solved by setting the timezone value in capitals in /etc/php.ini

Yes, there are errors about the timezone settings:

That is version of roundcubemail-plugins-kolab, there should be roundcubemail package too, but nevermind.

There are a lot of roundcubemail packages, can be a bit more exact about from which package you would like to know it? The version most mentioned is 3.3.0-4.1

Fixed in 1b605db5f721f.

What roundcubemail package version? Could you provide a sample eml file? Any error in log?

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

Hi.
We have the same problem. Is there a workaround available?

You're right.

The doc shows a few parameters:

1. $config['fileapi_seafile_host'] = "files.example.com";

--> but the dialog box "add external storage" requires a server hostname...

Yes.

ok. I followed the doc:
https://kolabsys.com/howtos/use-seafile-with-chwala.html