> > Recently we also implemented ldap groups which are expanded by postfix. > > This works fine, unless the group expands to some email alias destinations. > > Virtual(5) alias expansion is performed recursively in cleanup(8) for all > recipient addresses. Recursive local aliases(5) expansion happens later, in > local(8), only for recipient addresses that are routed to the "local" > transport > (typically recipients whose domain is listed in $mydestination). > > Virtual(5) alias expansion stops when a lookup key resolves to itself. > > > virtual_alias_maps = > > ldap:/etc/postfix/ldap_expand_groups.cf, > > ldap:/etc/postfix/ldap_accountsmap.cf, > > ldap:/etc/postfix/ldap_expand_alias.cf > > I recommend "proxy:ldap:..." rather than "ldap:...".
This will just improve resource usage, but not change behaviour, correct? > > > 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 > > > The ldap_expand_alias.cf > > > > server_host = ldap://openldap1.server search_base = o=mailhosting > > query_filter = (&(objectClass=MailAlias)(mail=%s)(accountActive=TRUE)) > > result_attribute = maildrop > > bind = no > > Post an example group member address that fails to be resolved. Sending a mail to [email protected] returns with this error: <[email protected]> (expanded from <[email protected]>): host 127.0.0.1[127.0.0.1] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) The ldif of the group version: 1 dn: cn=g1,ou=Sogo,ou=groups,o=mailhostingobjectClass: extensibleObject objectClass: top objectClass: groupOfUniqueNames cn: g1 uniqueMember: [email protected],jvd=schild.ws,o=mailhosting uniqueMember: [email protected],jvd=client.ch,o=mailhosting uniqueMember: [email protected],jvd=client.ch,o=mailhosting mail: [email protected] The ldif of the failing expand/alias: version: 1 dn: [email protected],jvd=client.ch,o=mailhosting objectClass: JammMailAlias objectClass: top accountActive: FALSE lastChange: 1363865527 mail: [email protected] maildrop: [email protected] cn: xxxxxx userPassword:: xxxxxxxxxxxxxxxxxx > > 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? André
