---- Original Message ---- From: Jesse Norell <dbmail-dev@dbmail.org> To: dbmail-dev@dbmail.org Subject: RE: [Dbmail-dev] capabilties (was Re: [Dbmail] Disable an account) Sent: Mon, 3 Jan 2005 15:05:03 -0700 (MST)
> What had been discussed previously, iirc, was along the lines of: > > - A status table that basically held an enable/disable and a text > message (to be returned in smtp bounce, webpage error, etc.) > > ID Enabled Message > 1 1 Status OK. > 2 0 Administratively disabled. > 3 0 Account suspended: Delinquent in payment > 4 0 Account disabled for spamming. > 5 0 Account suspended: Policy Violation > > etc. (obviously check your liability if you go telling the world > that user X doesn't pay their bills, etc. :) > > - A capabilities table for specifying what a user/alias/group can or > cannot do. > > capability table: > ID Capability Description > 1 pop3 Access to POP3 > 2 imap4 Access to IMAP4 > 3 insert Can receive messages (SMTP/LMTP) > 4 forward Allowed offsite mail forwarding > 5 webmail Allowed to use webmail > > capabilities table: > > user_idnr alias_idnr client_idnr capability status > 123 null null 1 1 > 123 null null 2 2 > null 333 null 3 2 > null 333 null 4 1 > null null 444 5 1 > 666 null null 1 4 > 666 null null 2 4 > 666 null null 3 4 > 666 null null 4 4 > 666 null null 5 4 > > > You'd then make functions to check permissions using > the generic capability name (eg. "pop3"). That's not the most elegant > setup, right offhand, and may not have been exactly it, but something > along those lines. > Ok, I just remembered a bit more :) .. it seems that the users and aliases tables were actually modified to include a capabilities id, not vice-versa. That way you could make a generic profile for a class of user (eg. one allowed pop3, smtp and forwarding, not imap or webmail) and just have one capabilities set (ie. one row for each capability's status), and set that for all users of that class. Eg. capabilities table: capability_idnr capability status 1 1 1 1 2 1 1 3 1 1 4 1 1 5 1 2 1 1 2 2 0 2 3 1 2 4 1 2 5 0 That doesn't allow group capabilities, though, nor anything to do with limitting by ip addr, etc., but that is what I rember being discussed. It makes adding custom/local capabilities very simple without any schema change, which was one of the primary goals, but could probably be improved upon. -- Jesse Norell jesse @ kci.net
