On Tue, Jun 03, 2014 at 03:31:28PM +0000, Andr? Schild wrote: > > I recommend "proxy:ldap:..." rather than "ldap:...". > > This will just improve resource usage, but not change behaviour, correct?
Yes. > > > server_host = ldap://openldap1.server > > > version = 3 > > > search_base = ou=groups,o=mailhosting > > > query_filter = (&(mail=%s)(objectclass=groupOfUniqueNames)) > > > leaf_result_attribute = mail > > > special_result_attribute = uniquemember > > > > What's in "ldap_accountsmap.cf"? > > server_host = ldap://openldap1.server > search_base = o=mailhosting > query_filter = > (&(objectClass=JammMailAccount)(mail=%s)(accountActive=TRUE)(delete=FALSE)) > result_attribute = mail > bind = no This leads to identity mappings that terminate virtual expansion. Because it is listed ahead of aliases, the aliases are never seen. > version: 1 > > dn: cn=g1,ou=Sogo,ou=groups,o=mailhostingobjectClass: extensibleObject > objectClass: top > objectClass: groupOfUniqueNames > cn: g1 > uniqueMember: mail=a.sch...@aarboard.ch,jvd=schild.ws,o=mailhosting > uniqueMember: mail=langenth...@client.ch,jvd=client.ch,o=mailhosting > uniqueMember: mail=langenthal...@client.ch,jvd=client.ch,o=mailhosting > mail: g...@client.ch > > > The ldif of the failing expand/alias: > version: 1 > > dn: mail=langenthal...@client.ch,jvd=client.ch,o=mailhosting > objectClass: JammMailAlias > objectClass: top > accountActive: FALSE > lastChange: 1363865527 > mail: langenthal...@client.ch > maildrop: langenth...@client.ch > cn: xxxxxx > userPassword:: xxxxxxxxxxxxxxxxxx You again left out the account LDIF. > > Your design lookups too complex. If you give every user a maildrop, and > > give > > no groups a maildrop, the whole thing simplifies to one > > lookup: > > > > server_host = ldap://openldap1.server > > version = 3 > > search_base = o=mailhosting > > query_filter = mail=%s > > leaf_result_attribute = maildrop > > special_result_attribute = uniquemember > > > > The lookup key is "mail", the result is always a "maildrop" (whether the > > address is an "alias" or not). Group objects have uniquemember DNs that > > ultimately have maildrops. > > We don't have groups with maildrops, so this should be ok. > Does this still apply, when the accountsmap returns the mail attribute as > shown above? Give users a maildrop, and lose the accountsmap identity mapping. You can implement the user/group/alias mapping in a single table as suggested. -- Viktor.