I see. If you have a requirement not to change the LDAP schema and existing data, then your options are limited.
> Granted, and I agree that generating lists of users based on > an attribute value on the user entry is much better. But this is > not compatible with the way many products manage groups. There > are also administratively defined limits on the number of entries > returned. Unless you bind as your administrative user, if you've got > large groups then you're also going to bog down the directory server. Not really. Fetching N entries bogs the server down much less than fetching a single N-attribute-sized group entry + the N entries. The problems with static groups relate to the server reading the entire group as an atomic blob into memory, and some O(N^M) code which can result in high CPU usage processing the entry. Some of that code was fixed, I forget exactly when. You might fail to retrieve the complete set of members due to hitting the administrative limit. That would be bad. Typically mail servers do bind as the administrative user for this reason. Later NSDS versions are able to impose different limits for different bind DNs, which fixes this problem. You can also use VLV to step through the returned entries such that you can resume the traversal if for some reason it has to be aborted mid-flight. > The ideal solution is a mailing list manager that can generate, > from time to time, a list from LDAP and cache it. Then the > list can be mailed frequently without much penalty on the LDAP > side. I'm going to have this built into our MLM package. For Yes, if the LDAP operation to fetch the list content completes, and completes within a resonable time, then this will work well. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
