So actually, a bit more careful grepping and only user.c is a consumer of
the db...alias functions! Everyone else just uses auth_check_user(), which
does resolve aliases but also does so recursively, until either an address
is found to be a forward, exec, or a numeric user account.
I do still thin
Aaron,
First, I applaud your work on the auth separation. It's a key feature for large
scale software.
I am currently part of the macs project on Source Forge (http://macs.sf.net).
Grossly oversimplified, it is a single sign-on system. As I have been using
dbmail (with much delight) for over
Here's another idea that builds upon this, with fewer changes... since I
can think of at least one potential auth mechanism that won't work well
with aliases - PAM - and so perhaps we should do a combination effort:
Each db implements the alias function as db_...alias...
All calls to the ...alias
Hi,
As I get further along on the LDAP auth module, I've noticed that the
alias table functions are all in the db.h and not in the auth.h
abstraction. Since the "native LDAP" posixAccount and MS's Active
Directory "user" classes both include the possibility for multiple mail
and mailAlternate attr
