Improving and simplifying email mailbox quota management in ISPConfig
I'd like to open a dialog about how mailbox quotas are handled in ISPConfig. Let's walk through a common use-case.
I set a 10000MB quota in a client template, named "Basic Web Hosting". I apply this template to a client.
I create 10 new mailboxes for the client, and do not assign an explict quota to any mailbox. The 10 users share the 10000MB; the quota is not "divided evenly", which means that one user is able to consume 9000MB, leaving the other 9 users to share 1000MB.
I realize that I can "hard-code" each user's quota to be, for example, 1000MB. But then, resources may be "wasted" if one user hardly uses email, but 1000MB are being "reserved" for him, and one user requires a lot of large attachments but is limited to 1000MB. Also, this approach requires me to recalculate all users' quotas for the client in question, manually, each time a new mailbox is created (or whenever the client template quota is changed).
Ultimately, I'm looking for some type of "dynamic quota renogotiation" behavior that would allow for at least two different quota management schemes:
1.) All users share the client quota. (This "mode" is possible already.)
Benefits: Simple setup and limited or no maintenance; adding mailboxes or changing the client template poses no real risks.
Risks: There is nothing to stop an individual user from consuming the entire quota, thereby causing other users to go over-quota and not receive mail.
2.) All users split the client quota evenly; a 10000MB quota for 10 users means that each user will be guaranteed 1000MB. When new mailbox users are created, or the client template quota is changed, each user's quota is recalculated (divided evenly).
Benefits: Provides guaranteed resources for each user.
Risks: Users with lower storage requirements may "waste" disk space that another user under the same client could better-utilize. Also, a potential problem arises when a new mailbox is added or the client template quota is changed; if any user is near his quota, the quota recalculation could cause him to be over-quota instantly. (I have no suggestion for addressing this problem at the minute.)
Are there additional schemes that might be useful?
Has this issue been discussed internally (or externally) already? Has someone elucidated clearer, more complete plans to implement something like what I describe?
Last edited by cbj4074; 10th June 2013 at 22:56.