Paul J Stevens wrote:
This can be done in 2.1.x, which however is not advisable yet for
production installs.
[EMAIL PROTECTED] wrote:
So I am considering using LDAP for auth with DBMail.
Can someone explain how distribution lists would work with DBMail/LDAP?
i.e. [EMAIL PROTECTED] to all users in the sales department. Right
now I configure this as an LDAP mailAcceptingID with multiple maildrops.
Is this information held in LDAP or SQL?
definitely in ldap.
And you would recommend using LDAP for auth over sql? I here in large
installations it is just faster. I do like the idea of one central
database for both messages and auth. I'm especially interested in using
replication of one or both as to sync to a hot backup for failover.
If LDAP is the schema configuration adaptable to existing setups?
yes. Check the example config in 2.1.x. I've used
dbmailForwardingAddress which can hold multiple mailForwardingAddress
attributes. Those are meant to illustrate the minimum requirements of an
ldap object. You can easily change those into something else.
So I know that 2.1.x is not considered production. Is this something
that other people are using this way though with out too many problems?
Also is 2.1.x the only version with "stable" LDAP support?
Specifically I have a Kolab/Postfix configuration that I would likely want
to adapt to DBMail LDAP configuration.
is mailAcceptingID an attribute? and if so of a special objectClass?
mailAcceptingID is essentially "alias". It is part of an LDAP schema we
put together a few years ago for a postfix-cyrus-LDAP solution. So yes
it is part of MVIUserClass that we created.... but comes from some
thread I found way back on a postfix list.
So if I'm correct with LDAP auth.. and the Distribution Lists captured
in LDAP, the actual mailrouting to the lists would all happen in
Postfix, or other MTA, and DBMail would just receive the mail after it
had been distributed by Postfix to the proper mailboxes. Correct?
Basically DBMail wouldn't be doing the work, just using the same schema
as Postfix.
Thanks for your reply,
Kevin Baker
