Hi Aaron, > That's a really good point. Refencing my posts about a clients table, we could > also hardwire clientid 1 as the "internal client" and have only internal users > part of that client group. This makes me happier than a boolean column, which > I don't really like because we'd have to change every auth query to add "... > where users.system = 0" at the end.
I don't see the difference for auth queries? Then you have to add "... where users.clientid <> 1" at the end? But an extra table would have other advantages. A groups table could look like: group_idnr | groupid | maxmail_size users.client_idnr could be renamed to users.group_idnr and reference groups.group_idnr. A special group groups.group_idnr = 1 could hold all system accounts. That way group quotas could be implemented easily too in the future. > But there's also the interaction with LDAP and the proposals for configurable > SQL authentication queries (see pam_mysql / nss_mysql as an example of this > idea) That shouldn't be too hard. pam_pgsql, exim and PowerDNS have configurable queries too (they all share the same database on my system - would be nice if dbmail had tablename prefixes ;-) ). > and how we're going to ensure that the internal user account is properly > represented by the authentication provider. That's harder. > In any event, we need to come up with something good during the 2.1 series. > Clearly IC&S wants to get 2.0 out the door, and Ilja's solution to my hack > should work well enough despite the potential side effects like running a > per-user billing script and trying to send bill's to dbmail_internal -- which > might be a good thing, really. Just put IC&S' address in and hope that their > billing department doesn't pay close attention to invoices... :-P I'll try that and add 'Aaron Stone' as contact for billing questions to the bill ;-) -- MfG Thomas Mueller - http://www.tmueller.com for pgp key (95702B3B)
