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.

Reply via email to