Problem Space Description
Kolab has long supported "group ACLs" on IMAP folders through LDAP roles (the nsrole attribute on a user entry). In folder settings management, a user would type in the name of a group, select the group, and effectively set an ACL for group:<name>.
Roles may not always be in use in an organization's LDAP, and roles in fact are not available in LDAP technologies other than the Netscape-based varieties (389, RHDS, etc.), such as OpenLDAP.
Another type of group that is equally scalable is available: the static, mail-enabled distribution group -- a list of individuals (uniqueMember) with its own recipient attribute (mail). A memberOf attribute on the original user entry would point to the groups the user is a member of. The memberOf attribute however is maintained by a plugin or configuration option that may not be enabled.
How would Kolab support the use of group ACLs in a scenario whether neither roles nor the memberOf (plugin-based) attribute are available?
Implementation Design Considerations
To enable the use of Group ACLs on IMAP folders in more deployment scenarios, Kolab could make Cyrus IMAP support the use of the ldap_member_method called filter, with the user name canonification process allowed to continue as intended.
Side-notes:
- Nested groups would not be supported.
- It is the least scalable approach to group membership resolution and is not recommended.
- The results are cached -- the effects of group membership changes may not affect the use of IMAP folders immediately.