Aaron Stone wrote:
On Fri, Dec 15, 2006, Rod K <[EMAIL PROTECTED]> said:
We have a legacy system running qmail/vpopmail with a couple thousand
users that we'd like to migrate. With vpopmail having an aliased
domain, the user can sign in as [EMAIL PROTECTED] or
[EMAIL PROTECTED] Due to some legacy issues, we have 3 domains
aliased together and various users using any of the 3 aliased domains in
their login.
If you can convince people to log in without the domain, then you can
write aliases for each user in the form 'username@' -> 'username' which
will catch mail for each user on every domain. This may introduce
migration headaches in the future if you have to re-segregate your logins
by domain, say if your organization merged with another organization.
Unfortunately, that is not a workable option. First, too many users to
notify, second, username collisions.
I've thought of creating a view in PG that would be the union between
dbmail_users and a select joining dbmail_users and dbmail_aliases that
would return userid as the alias. This would allow a login using an
alias. Of course, I'd have to rename the dbmail_users and give the view
that name, along with some rules to handle INSERT, UPDATE, DELETE on the
view.
That would be an interesting approach, and I would be excited to see if it
worked well for you. Certainly this would be a good way to leverage the
database to do some interesting integration work for us.
In fact, I'd even like to think that this would be a *preferred* way to
approach integration with an existing login table.
I would think so, too. However, I'm concerned that another select on
dbmail_users, somewhere in the dbmail code, could have a problem with
some results returned from the view. For instance, SELECT userid FROM
dbmail_users WHERE user_idnr=5 would return multiple rows.
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
