Hello, > ---------------------------------------------------------------------- > aaron - 15-Oct-04 18:25 CEST > ---------------------------------------------------------------------- > With this response, let's pop over to the mailing list for a little while. > But, I'm thinking, columns strikes me as a bad idea. It means a database > upgrade for every new feature that we might want to control. Instead, we > can add a permissions table that grants or removes privileges to the > various daemons. With client_idnr in the mix, we can do things like say, > "Client X pays for POP3, Client Y pays for IMAP and Client Z pays for > both." > > We should consider how/if this will interact with the user account and > client account suspensions feature that has been so often requested.
A while back (pre1.0ish) Ryan Butler and I hashed this issue fairly well over irc and had a gameplan... maybe even the db schema setup. But that's been a couple years ago :). Basically it was a general capabilities setup per account and per alias. It should be done in a very generic way so everyone can add their own capabilities easily. Some that come to mind right offhand are: delivery (recieve from inject/lmtp) pop3 imap4 webmail (for native clients like weDBmail) enable/disable notifies/auto_replies (eg. on public free mail systems) You could extend it to a lot of things like pop-before-smtp (to force specific users to sasl) and other stuff, but I'm sure there'd have to be a practical reason to impliment it (but it'd be simple to stick a capability check function in a lot of places). On a site level, it could be used to flag which users should have spam or virus scanning, which users are allowed to create their own email forwards, etc., etc. -- Jesse Norell [EMAIL PROTECTED] is not my email address; change "administrator" to my first name. --
