Ilja Booij wrote:
I'd like to see this worked out in detail. We've been thinking about
this before, and I remember something about it not being as simple and
straightforward as one would've liked..
For instance:
where do you store domain aliases? (or do we already have a solution for
that that I'm not aware of?)
That's easy.
add a user to the ldap-tree with the proper forwarding:
dn: uid=foobar,ou=People,dc=foo,dc=nl
cn: foobar
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: dbmailUser
objectClass: top
uid: test
uidNumber: 20000
gidNumber: 100
mail: @foobar.nl
mailForwardingAddress: [EMAIL PROTECTED]
mailForwardingSaves: 0
Of course the proper queries will have to be added. But I think this'll work.
There is another way of doing it, but that involves some duplication of
information.
No aliases table should be required when using ldap. The users table should be 'passive' only: it should be
perfectly safe to delete * from dbmail_users, without losing any functionality. Only cached information. Of
course, any foreign key conditions pointing to the users table have to be dropped as well.
We can keep a simpler dbmail_users table around, without things like
password information. This would help us, because we can still use
foreign keys etc to get rid of all mailboxes and messages a user has
when removing the user.
I don't think that would be wise. Using ldap I'll manage my users in ldap. Ldap won't notify dbmail when an
account is removed. So you'd have to go into the users table manually anyway. Unconnected users are quite
uninteresting. Unconnected mailboxes and their possibly massive content of messages and blocks very much more
so. I guess dbmail-util -r will be around for some time yet, and that why db_icheck_mailboxes is in the
have-to-fix list.
OTOH, we would have to come up with a way of updating data between LDAP
and DB.
That is unavoidable. But I'd vote for a uni-directional liaison. kiss: One
Master, One Slave :-)
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
