On Tue, Jun 03, 2014 at 02:28:22PM +0000, Andr? Schild wrote: > 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:...". > 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"? > 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. 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. -- Viktor.
