Sam Varshavchik wrote:
Roger B.A. Klorese writes:
They're properly called "dynamic groups" -- that is, a list whose membership is defined not as a static list of addresses but as a dynamic LDAP query that is evaluated at runtime.
And what exactly is do âdynamicâ about it? If it's another LDAP query, that reads another set of addresses, why can't those addresses simply be defined for the original alias?
For administrative reasons. Overhead of managing static mailing lists get extremely large when mail aliases are intensively used through an organization.
For example, imagine an organization which has the following mailing lists: * a mailing list for all users except those who are in the "outsiders" and "dismissed" organizational units; * a separate mailing list for each organization unit (e.g. "sales", "helpdesk") * a separate mailing list for each local branch (e.g. "detroit", "washington")
Adding and removing users becomes an administrative nightmare where a user must be manually added to/removed from multiple mailing lists.
With dynamic groups, one can instead specify members by an LDAP filter.
E.g. to specify a mailing list of all employees from Washington:
ldap:///dc=example,dc=com,o=Company??sub?(&(dc=washington)(objectclass=CourierMailAccount))
I see. This sounds reasonable.
This shouldn't be too difficult to implement, so you (or whoever made this proposal) should feel free to proceed with it. This is a simple matter of adding a new configuration setting, and making the appropriate changes to ldapaliasd.c. It might be as simple as making a minor tweak to the first half of search_maildrop() which manufactures the LDAP query. If done right, the second half, which processes the LDAP query results, might not require any changes.
There's no need to worry about removing duplicate addresses.
pgp00000.pgp
Description: PGP signature
