Yay! - Someone else in my position! Yes - we definitely should support multi-domain customers, or from my perspective -- duplicate usernames. Dbmail should only care about the user_idnr, so that it's up to dbmail-smtp, dbmail-pop3d and dbmail-imapd to resolve the supplied "arguments" (including say 'ip customer connecting to') to a particular user_idnr.
Having a look through the auth/authsql.c code -- it looks like a bit too much of the code is still geared around referring to the username rather than the user_idnr. This will affect viability of both our needs. I could be wrong as I've only had a brief glance -- but the resolution of delivery email address seems to match against usernanes. ([EMAIL PROTECTED] -> "usernamea" rather than "3352"). If this could be matched instead against a user_idnr, then the possibility of having two "mark" usernames with different "domains" or whatever other secondary key you came up with would work. I personally would love to see this happen. What would be the possibility of getting this implemented, guys? /Mark > New: userid field only contains the username part, without > domain and > introduce a new domainid (int) filed tied to a new domain table. > > 1) When an account is created by the cli, it first check to > see if the > domain exist, and if not create one, use the domainid returned to > insert the new user. > > 2) Instead of single queries to seek/validate users, a simple join is > used. > > We already have to do this to better manage accounts in a > multi-domain > settings and seeing that dbmail 2 is geared toward much larger setups > (with chances of multidomain email hosting increasing), > perhaps it's a > good time to make the db layer separate the relationship between a > username and the domain that the username falls under? This change > would increase the complexity of small setups but for large > setups is a > great time saver. > > What do you guys think? Good or Bad, or just Ugly?
