Aaron Stone wrote:
DBMail's authldap was designed to work with three well-known and working
LDAP schemas: inetOrgPerson, qmail-ldap and Exchange. All three keep
aliases together with user accounts, as does DBMail, both now and at the
time I wrote the authldap module. So this is a natural. Separating them
out might give huge new opportunities for people who go through the effort
of making it work, but they can *already* do that. So all separating would
do is kill what works now and is simple and straightforward to use.
Works now? Whatchewtalkinbout? Not authldap I presume :-/
My point is/was that authentication is a different beast from delivery. Separating them is not just about
opportunities, it's about design. And it's not about losing functionality. Backward compatibility must be
maintained if at all possible.
Authenticating from PAM would be neat, but unfortunately it isn't such a
great database of user information beyond what's in a typical /etc/passwd
file.
It will also allow people who have huge existing userbases to use dbmail without having to change anything in
their authentication setup, nor in their email delivery setup for that matter except for those users they wish
to serve with dbmail.
Having pam will also give admins the tools to manage access to dbmail through tcp-wrapper using
/etc/security/access.conf.
It will simply make dbmail a better unix citizen... imo.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
