Smart email account quota to adjust to Summary Disk space available

[ruzbehraja]

Although this has been a very common issue, I was unable to find any similar threads.

The Problem:
The Email account quota's do not restrict themselves to the Summary Disk Quota which has been allocated to the Cpanel Account.

This means that a user who has taken 50MB from me, still has the option to set the quota of all 5 of his email accounts to 250 MB each.



When any one of his accounts reach 50MB, his mails will stop, even though when he logs into the email account section in cpanel, he will see only 50 / 250MB used.

This tends to give a wrong impression to the user, especially if the email quota is showing unlimited or the max (2048 MB) and his actual cpanel disk limit is much less.


The Solution:
When allocating email account quotas, cpanel should dynamically be able to determine, how much actual space can be allocated.

Eg: If the cpanel disk quota is 1000 MB

After creating 1 email account of 250 MB, it should allow me to create the next email id with a quota of only 750MB or less.

If I have created 2 accounts of 500 MB, then it should not allow me to create a third email address, until I reallocate the space, so that there is no overspill.

I hope I am clear.

Any more thoughts on this are welcome.

[cPanelDavidG]

This is a scenario I was discussing a few weeks ago with our Product Manager. There are a variety of different ways this can be implemented, item 3 below seems to be the closest to what you describe.

1. Only focus on the quota of the account and ensure email quotas do not exceed that.
2. Accounting for disk space already consumed on the cPanel account. Meaning if you had an account with a 1000 MB quota, but 950 MB of that quota was used, the largest email account that would be permitted to be created is 50 MB.
3. Accounting for disk space that will potentially be consumed on the cPanel account. For example, if you have an account with a 1000 MB quota, and you create an email account with a 950 MB quota, then theoretically that 950 MB could fill up - so the maximum permitted size for the next email account would be 50 MB.
4. A combination of 2 and 3.

[ruzbehraja]

1. Only focus on the quota of the account and ensure email quotas do not exceed that.

1. Does not make sense.
Eg:
CPanel Account Quota = 50MB

Email Id 1 = 50 MB max.
Email Id 2 = 50 MB max.
Email Id 3 = 50 MB max.
Email Id 4 = 50 MB max.

In this case is email id 1 exceeded 50MB, then all the other ids would suffer.

2. Accounting for disk space already consumed on the cPanel account. Meaning if you had an account with a 1000 MB quota, but 950 MB of that quota was used, the largest email account that would be permitted to be created is 50 MB.

2. This can be misleading too, because if it is a new account, nothing may be used, at the same time, at the time of creating it, if users had downloaded their mail and the usage had come down, more space could have been allocated.

3. Accounting for disk space that will potentially be consumed on the cPanel account. For example, if you have an account with a 1000 MB quota, and you create an email account with a 950 MB quota, then theoretically that 950 MB could fill up - so the maximum permitted size for the next email account would be 50 MB.
4. A combination of 2 and 3.

4. Probably a combination of 2 and 3 should help.

[cPanelDavidG]

That was essentially our line of reasoning (that #4 would likely be the best), but wanted to open it up for public discussion to ensure that's what people wanted.

The main downside to #4 we've seen so far is if there was some huge disk consumption for temporary data, that would skew things.

[gkgcpanel]

I like the idea. However, we sell packages with strawman options... IE: 5GB of disk space (and hoping that not everyone will use all 5GB)... So we can advertise that our package gives you 5GB of disk space, 1000 email accounts, at 10MB per email account max for $3.99/month, but we don't want them to be able to have unlimited or 250MB mail spools.

The next package would give them 25GB of disk space, 2000 email accounts with 50MB per email account...

We want to hard code each package to a limit of 10MB or 50MB or 100MB etc.. and not allow the users to change it. An upgrade to the next package would be required in order to get more mail spool space.

Right now, we are accomplishing that by creating our own templates. But each time a new version is released, we have to spend hours if not days re-creating the templates with those changes that we have made to hard code the quota for mail spools to their respective packages.

So while I like the idea discussed by the orignal poster (above) by dynamically determining, how much actual space can be allocated, that would work fine for small packages (IE: 50MB of disk space for the entire cPanel account). But for large disk space packages (IE: 5GB), that still really wouldn't work. We don't want someone with 5GB of disk space to use 10MB for their website/databases and then 4990MB of quota for email... That would simply fill up with spam/junk so quickly...

We're trying to get users to download their email on a regular basis and not store their email on the server indefinitely.

Make sense?

[HostCenter IL]

It's a good idea, and if it's complicated to implement, I believe that a great first step would be to allow the ability to properly delete email via webmail when the account is over quota. Currently this is not possible, and it does not allow customers who don't know how to delete email otherwise to fix their quota problems even if they want to.

[cPanelDavidG]

I like the idea. However, we sell packages with strawman options... IE: 5GB of disk space (and hoping that not everyone will use all 5GB)... So we can advertise that our package gives you 5GB of disk space, 1000 email accounts, at 10MB per email account max for $3.99/month, but we don't want them to be able to have unlimited or 250MB mail spools.

The next package would give them 25GB of disk space, 2000 email accounts with 50MB per email account...

We want to hard code each package to a limit of 10MB or 50MB or 100MB etc.. and not allow the users to change it. An upgrade to the next package would be required in order to get more mail spool space.

Right now, we are accomplishing that by creating our own templates. But each time a new version is released, we have to spend hours if not days re-creating the templates with those changes that we have made to hard code the quota for mail spools to their respective packages.

So while I like the idea discussed by the orignal poster (above) by dynamically determining, how much actual space can be allocated, that would work fine for small packages (IE: 50MB of disk space for the entire cPanel account). But for large disk space packages (IE: 5GB), that still really wouldn't work. We don't want someone with 5GB of disk space to use 10MB for their website/databases and then 4990MB of quota for email... That would simply fill up with spam/junk so quickly...

We're trying to get users to download their email on a regular basis and not store their email on the server indefinitely.

Make sense?

It sounds like your specific needs are best met by the feature request where one specifies a numerical limit to email account quota rather than this thread which attempts to more aggressively avoid email-over-quota scenarios.

[gkgcpanel]

It sounds like your specific needs are best met by the feature request where one specifies a numerical limit to email account quota rather than this thread which attempts to more aggressively avoid email-over-quota scenarios.

Right. Either way works for me. I think the numerical limit is the easiest of these to implement. I like the other idea too and certainly would not mind having it.