Interesting. When can we expect to have the missing feature implemented?

It is working now.

Is this still an issue, or did the increase of filehandles configuration resolve the issue?

Closing this as a config issue.

Just to confirm: It was a faulty PHP-Mailer-Version that caused this issue.

Looks like it is not implemented at all, https://git.kolab.org/diffusion/P/browse/master/pykolab/auth/ldap/__init__.py;9d70f9d837c50e0b74b69d7e8b69c93294dd767a$1735

I finally found the culprit. Differential updated.

Done.

I applied the fix into Kolab Winterfell installation, and I still see "infinite" processing loop with the same traceback. I restarted wallace and kolabd.

It was already fixed in master, but not in release-1.1. Done in 8e2fdee671.

root@debian:~# dpkg -l apache*
Desired=Unknown/Install/Remove/Purge/Hold

+++-======================-================-================-=================================================
ii apache2 2.4.10-1.1 amd64 Apache HTTP Server
un apache2-api-20120211 <none> (no description available)
ii apache2-bin 2.4.10-1.1 amd64 Apache HTTP Server (binary files and modules)
ii apache2-data 2.4.10-1.1 all Apache HTTP Server (common files)
un apache2-doc <none> (no description available)
un apache2-mpm-event <none> (no description available)
un apache2-mpm-itk <none> (no description available)
ii apache2-mpm-prefork 2.4.10-1.1 amd64 transitional prefork MPM package for apache2
un apache2-mpm-worker <none> (no description available)
un apache2-suexec-custom <none> (no description available)
un apache2-suexec-pristin <none> (no description available)
un apache2-utils <none> (no description available)
un apache2.2-bin <none> (no description available)
ii apache2.2-common 2.4.10-1.1 amd64 Transitional package for apache2

What is the web server software that is installed (prior to setup-kolab)?

This is also the case for the wheezy installation

The installation is left in a non working state and with this truncated /etc/imapd.conf (the same every time):

It was committed to -3.2 in rRPKa9f51f2d4d0e69c9

I always do this. I just skipped it in comment as the customer is interested in KE14 now. 073961a1b66076f10b

Can we make sure this commit lands in the -3.2 stable branch as well?

Please ensure the fix also lands in release-1.2.

I missed that we actually can't get specific folder type of other user folder because it is stored in a private folder annotation. I don't really like the idea of recognizing folders by their name, which as I understand, you propose.

=?iso-8859-15?Q?Stellenausschreibung-=C4nderung:_16-2509-075, IT@M, A10/E9_TV=F6D?=

This is not a valid header value according to RFC2047. Encoded-word can't contain spaces. What client created this?

yes, I understand what you mean and would not have expected anything else

may be, but the view is the view for this certain user, so if user A uses special folders of user B nothing would hurt user B because the special folder mapping of user A would be required here.

It is not possible at the moment. Note that in IMAP it is possible to have many shared and other users namespaces. So, it might be problematic in such environments. However, maybe we could assume we have only one of each in Kolab. Still, replacing the namespace name with localized label in all places, may be not a simple task.

Well, what is special for one user don't have to be for the other. I could agree with an icon change, but not label.

"the implementation" here is cyrus.

Since I'm not sure if roundcubemail does that already cyrus may not be the source of the umlauts problem.

This fits for labels and icons and doesn't work with shared folders too

To disable Settings section of the UI I propose to set:

$config['kolab_auth_admin_rights'] = array(
    'settings' => 'entry:delete',
    '*' => 'entry:read',
);

Note that with this LDAP effective rights will be used and kolab_auth_group/kolab_auth_role_value will be ignored. You can also change 'entry:delete' to 'attrib:kolabDelegate:write' (or use some other attribute).

Just because I was asked for " ​what is in your: $config['kolab_auth_admin_rights'] = array()" here the kolab_auth.inc.php we use

ok, thank's, I've missed that

Shared folders are handled differently. We've been there. See find_folder_resource() in line 192.

For normal mailboxes and users I'd be happy with the implementation as I read it.

We'll test it in Kolab Enterprise 14 repos if available.

Created a patch. This is untested and it's not my decision if it is proper aproach.

Thanks for your effort. As soon as the changes are available in Winterfell, I'll be happy to test it.

As Jeroen already wrote, I think that is absolutely correct, it "should use" this

[cyrus-sasl]
result_attribute = mail

but the filter "-d 9" uses is

(&(&(objectclass=kolabinetorgperson)(objectclass=mailrecipient)(mail=*))(|(mail=pitb.mse@domain.de)(alias=pitb.mse@domain.de)))

so it includes "alias" into the search and I don't know why.

I may would have agreed, but after roundcube provides a "helpdesk-login" function and independently of that provides delegation or password plugins performing such LDAP "edit" tasks, someone using the heldesk-login feature should either

• get a warning that those plugin functions are just readonly and not an adminstration frontend replacement

or

• find any edit functionality involved by those plugins disabled

or

• have just no access to those plugins (Could you please give me a hint how to disable delegate from settings?)

or

• enable edit/admin/helpdesk tasks for "helpdesk-login" usage by what ever possible action/task

rather than setting the timeout unconditionally, it should set the timeout only for if immediate:

Can you please elaborated why REJECT does not make sense?
There is a use when reservation requests to meeting room should be allowed to particular users only. VIP car is allowed to certain users to be reserved is yet another case I can think of.
Please share all the logic behind resource reservation then.

As discussed with Jeroen REJECT does not make much sense for resources. So, I don't see anything in the code that would need to be fixed now. Consider updating documentation to be more precise.

Returning to the original question. No, it is not possible to prevent this with configuration. So, you have to investigate why a mailbox exists for alias attribute in the first place.

Ehh. So, different value for immediate? What values?

Neither delegation nor password resets for a user should go through Roundcube. Roundcube, after all, is not an LDAP administration interface.

Line 444 should be claused similarly to line 431 (by line 430)

sync-mailhost-attr should use the (one) result attribute (cyrus-sasl, result attribute), not the mail attributes.

Again, the resources module is a different module from the invitation policy. I read this ticket as concerning the invitation policy. I'm not sure how the resources module got in to the mix.

Confirmed. I tried SASL proxy authentication here, but didn't work for me. @vanmeeuwen is additional "service user" (i.e. new config options for DN and password) the only solution?

As I understand setting kolabinvitationpolisy: ALL_REJECT for resources does not work as for users, i.e. does not respond with Declined status.

The resources module is a different one from the invitation policy module. This ticket concerns the invitation policy module.

In rPd71e26c1a we added 10 second timeout (OPT_TIMEOUT option). I'm curious if we shouldn't use OPT_NETWORK_TIMEOUT and/or greater OPT_TIMEOUT value. Jeroen, what was your intention?

sync-mailhost-attr uses auth.find_folder_resource() and auth.find_recipient() methods which indeed use attributes defined in mail_attributes. Sync command uses hardcoded 'mail' attribute, so I suppose we should use 'mail' only here too.

In addition it is not clear what ALL_MANUAL policy means for resources. There is nobody behind the resource, so nobody can manually react to the reservation request. Even more, resource is calendar, so it has no mail type folder to deliver request.