I agree, an LDAP interface would be most useful. I'm implementing a user
interface (don't ask why ) to listserv where all of the listserv
options/data/listnames are being stored in  an ldap directory. The user
interface retreives the data from the ldap directory and displays it to
the user. The user changes their options/subscribes/unsubscribes from
the interface and the data is reflected back into the ldap directory,
and the rdbms. It's a real pain to have to keep this data in multiple
places, but the ldap directory contains required  data that has no
business being in the listserv rdbms, and is necessary for the
interface.
An LDAP interface should be considered.

"Alan S. Dobkin" wrote:

> This question was asked and answered about a year ago on this list,
> but I am hoping the answer may have changed over time....  ;-)
>
> My understanding is that LISTSERV 1.8d has built-in DBMS support
> for two main functions:  1) as a data store for list membership
> information, and 2) as a back-end for ad hoc mail-merge jobs.
>
> Both of these functions, and especially the latter, would be
> tasks well-suited for an LDAP-based directory service.  In the
> first case, the list membership information could be stored as
> attributes within person and/or group directory entries, allowing
> for dynamic updates of e-mail addresses, full names, etc., based
> on current directory data.  In the second case, LDAP search
> filters (queries) could be utilized to dynamically generate
> DISTRIBUTE jobs for mail-merge and mass-mailing applications.  An
> example of this at a university would be to send e-mail to all
> current sophomore students with an English major and a 3.5 GPA
> or higher (assuming this information is stored in the directory).
>
> LDAP-based directories, utilities, and interfaces are now widely
> available, and many organizations already provide this service
> to their customers (internal and/or external) for other purposes,
> such as online phone book applications.  If LISTSERV could take
> advantage of this capability, instead of requiring a conventional
> RDBMS application to be created, it would provide a great benefit
> to its users.  Please consider this a request for such a feature.
>
> Thanks,
> Alan
>
> --
> Alan S. Dobkin, Operating Systems Analyst
> Windows NT Group, Enterprise Systems Support
> Information Technology Division, Emory University