Comments inline... Thomas Mueller <[EMAIL PROTECTED]> said:
> 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? Oh, duh. But I guess that's OK, because think about it from the other direction: if there were a clients table and a boolean flag in the users table, we'd either have to join any queries of the clients table against the users table to make sure that we don't include system users, or just make a client to hold the system accounts anyway. Might as well go for it. > > 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. I am very strongly in favor of this. IMHO, a top priority for 2.1. > > > 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 ;-) ). I am very strongly in favor of this, too! > > > and how we're going to ensure that the internal user account is properly > > represented by the authentication provider. > > That's harder. Yeah, something tells me that we'll just have to play it by ear for LDAP. We're sort of in a transition period right now on that front; we really need to be using dlopen() for the database and authentication providers. If we were, we could just use authsql.so for system accounts and either authsql.so or authldap.so for user accounts. > > > 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) > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
