Re: [Exim] OT: Need some feed back on Exchange as an SMTP se…

On Sat, Apr 03, 2004 at 08:00:28PM +0200, Tony Earnshaw wrote:
> fre, 02.04.2004 kl. 22.15 skrev Bruce Richardson:
>
> [...]
>
> > LDAP is effectively read-only. It's trivial to search any given LDAP
> > directory for e-mail addresses: you don't have to understand the
> > structure of the specific directory because you just do a subtree
> > search. But there is no standard for updating LDAP directories.
>
> This just isn't so. I'm an LDAP aficionado, this server is running
> Openldap 2.2.8 and my Ximian Evolution client (this MUA) can update LDAP
> to the extent that I as the LDAP admin decree. It's not LDAP that can
> not be updated, added to, managed by clients, it's a shortcoming of the
> client.

Yes, that is what I meant. I'm well aware of the capabilities of the
LDAP protocol but e-mail clients do not even try to treat LDAP
directories as anything but readonly. One reason why they don't try is
because they don't know what they should be updating, what kind of
records they should be adding. It's easy for a client to search any
arbitray LDAP directory because you just need to search for records with
e-mail properties (and allow a user-definable search filter). This is
great, it allows you to treat almost any LDAP directory as an
addressbook. OTOH, how do should the e-mail client designers provide
for updating arbitrary directories in ignorance of the structure?
Evolution doesn't answer this question, it demands its own schema.

I'm well aware that the LDAP protocol allows for writing to directories
as well as reading from them: if you seach the Linux Magazine archives
you'll find LDAP articles with my name on them. What is lacking is a
standard for writeable LDAP address books. Evolution has developed its
own schema but nobody else is using it afaik. I don't want to be tied
to Evolution any more than I do to Outlook, so that does me no good.

Besides, I still say that a proper database is a more natural place to
store that information than an LDAP client. The problems that LDAP
presents simply stop being problems if clients look to the database. If
different clients expect different data structures, this is trivially
solved with views. I could support as many different e-mail clients as
I liked. Why should I waste valuable time on synchronising data between
a database and an LDAP directory when it makes to have all our data in
the proper datastore. How should I support e-mail clients that can
update LDAP directories but use different schema and want to add
different types of records? Why should I bother when synchronising
causes inevitable delays and discrepancies?

As it is, we use a webmail client that can store its configuration and
address data in any database supported by the PHP DBI abstraction layer.
This gives us much more power and flexibility (to extend the
capabilities of the mail client, to define our own groups and
heirarchies) than any current LDAP technology can.

--
Bruce

I see a mouse. Where? There, on the stair. And its clumsy wooden
footwear makes it easy to trap and kill. -- Harry Hill