possibility to create mail box > 2gb

youhost shared this idea 2 years ago
Completed

There is a limit on mailboxes size set to 2GB, it would be sometimes useful to have the possibility to override this limit as some people need larger mailboxes.

Best Answer
photo

This is now available in 11.48+

In 11.48, 64bit machines will have a 4TB mailbox quota limit.

The 2GB limitation on mailbox quotas is not a limit that we (cPanel) arbitrarily enforce. This is a limitation of the Exim email daemon. There are multiple discussions you can find online that explain the technical reasons behind why Exim's design (mostly related to 32-bit design) prevents quotas from being set to precisely 2GB or higher.

Comments (20)

photo
1

This is now available in 11.48+

In 11.48, 64bit machines will have a 4TB mailbox quota limit.

The 2GB limitation on mailbox quotas is not a limit that we (cPanel) arbitrarily enforce. This is a limitation of the Exim email daemon. There are multiple discussions you can find online that explain the technical reasons behind why Exim's design (mostly related to 32-bit design) prevents quotas from being set to precisely 2GB or higher.

photo
4

Hello, the 2GB mailbox quota makes it almost impossible to use quotas on imap accounts. I found talk about making exim work with 64 bit integers that dates back to 2005. If since then exim still hasn't implemented quota support for over 2GB then maybe it's time to look for a better solution. I vote for finding a way to get around this. I see 3 ways this could be done :

1) Patch exim on 64 bit systems

2) build an alternative quota system

3) support another software than exim

photo
2

This needs to be fixed, we're in 2014 nobody wants a 2 GB mailbox, and unlimited is way to much can lead to server abuse, performance issues etc.

photo
1

Btw, isn't cpanel using Dovecot this days? Now I'm confused. Is this a GUI glitch?

photo
2

TCB13 wrote:

Btw, isn't cpanel using Dovecot this days? Now I'm confused. Is this a GUI glitch?
Exim still has a limitation with delivering email to accounts with quotas over 4 GB.

photo
3

Kenneth Power wrote:

Exim still has a limitation with delivering email to accounts with quotas over 4 GB.
However unlimited seems to work fine. Seriously, I can't wrap my head around this things. We're all paying WHM/cPanel and it's not cheap, maybe you guys can spare a programmer or two to patch this know issues on the open source that power cPanel.

Thank you.

photo
1

Is it exim on all systems or only exim on 32 bit systems that has this limitation ?

photo
2

Please make this a primary priority!! 2GB is very little these days and unlimited it's a recipe for kaos. Please, If the blame is on exim, go patch exim. That's why it's open source right?

photo
2

Nowadays all my clients need accounts over 2GB

Please make this a priority update ASAP

photo
1

exim should be able to support much larger quotas on 64 bit systems. The remaining problem is that raising the limit would still break 32 bit systems and the transferability of accounts to those systems.

32 bit systems

# exim -bV| grep off

Size of off_t: 4

64 bit systems

# exim -bV| grep off

Size of off_t: 8

photo
1

If it's a matter of 64 vs 32 bit couldn't cPanel add a tweak setting that defaults to 2GB and that sysadmins can increase if they want to ?

If exim on 64 bit systems is already compatible with more than 2GB then on 64 bit systems it's just a UI limit.

Adding a tweak setting would solve this issue, and if exim 64 bit is currently limited to 4GB for example allow us to increase this value when exim is compatible with more.

So for current 64 bit users (IE users who aren't on old servers or small VPS's) please add the ability to set the maximum quota.

When setting the maximum quota, you can either have a big warning that this is user responsability or detect if system is 64 bit and if not disallow the change.

Thanks

photo
1

monarobase wrote:

If it's a matter of 64 vs 32 bit couldn't cPanel add a tweak setting that defaults to 2GB and that sysadmins can increase if they want to ?

If exim on 64 bit systems is already compatible with more than 2GB then on 64 bit systems it's just a UI limit.

Adding a tweak setting would solve this issue, and if exim 64 bit is currently limited to 4GB for example allow us to increase this value when exim is compatible with more.

So for current 64 bit users (IE users who aren't on old servers or small VPS's) please add the ability to set the maximum quota.

When setting the maximum quota, you can either have a big warning that this is user responsability or detect if system is 64 bit and if not disallow the change.

Thanks

Unfortunately, its not as simple as adding a new tweak setting unless we were to drop support for 32 bit machines. After a short analysis, the bare minimum scope of work includes at least the following:

  • Create a uapi to get the default email quota which would differ on 64 vs 32 bit
  • Provide legacy wrapper api calls for old themes for the new default email quota api call
  • Create a uapi to get the maximum email quota which would differ on 64 vs 32 bit
  • Provide legacy wrapper api calls for old themes for the new maximum email quota api call
  • Update all internals that know about the 32 bit maximum to know about the 64 bit maximum as well
  • Update all tools to know about the new email quota
  • Test exim to ensure it can truly handle the increased quotas on 64 bit systems
  • Ensure all systems that write maildirsize files can handle the increased quotas on 64 bit systems
  • Ensure that dovecot can handle the increase quotas in maildirsize files on 64 bit systems
  • Ensure that courier can handle the increase quotas in maildirsize files on 64 bit systems
  • Update all UIs to dynamically allow for the 64 bit or 32 bit limit depending on the system type
  • Update all JS api calls to know about the new 64 bit limits.
  • Update all the validation systems to know about the 64 or 32 bit limit depending on the system.
  • Built a migration tool into the transfer system to change limits on accounts that are transferred from other machines to meet the maximum of the system they are being transferred to.
  • Update the tweak setting to handle the new default email quotas on 64 bit systems
  • Update the tweak setting to handle the new maximum email quotas on 64 bit systems

We would not be comfortable with anything less then the above as setting a warning like you suggested above would not be sufficient to prevent quotas above the maximum from being set on 32 bit systems. When exim encounters a quota above the 32bit limit it bounces the message it is attempting to deliver. This would not be an acceptable risk as we want to ensure we do the needful to avoid leading anyone down a path that would result in data loss.

photo
1

What about just detecting during cpanel install if system is 64 or 32 bit.

You currently set the limit to 2GB because you know this is the maximum 32 bit systems can handle.

Once you have tested if 64 bit systems can handle say 5GB or maybe 8GB... Wouldn't you just have an internal flag, if 64bit then, if not then...

We regularly have requests for this, our competitors offer limits like 5GB per account, with IMAP being the default option in most software and the only option in windows 8 Mail, we regularly have requests for higher limits.

Customers don't want to risk all email accounts stopping working or risk their website from working don't like using the unlimited setting but can't fit inside the 2GB setting.

We can't wait multiple years for cPanel to drop 32 bit support. Please do this checks you mentioned and increase the limit.

photo
1

Haven't tested this, but looks hopefull :

http://help.directadmin.com/item.php?id=342

So cpanel would need to provide a 64 bit veresion for exim on systems that are compatible with large file support.

Once this is done, you would just have to check which version of exim is installed.

I haven't been able to find any info about the maximum quota size after this, but we would like to have quotas as high as 100GB, no point in a new maximum quota of 4GB, we would sill get requests for having higher limits.

20 GB would currently be an understandable limit for most users at the time being, but maybe not in 5 years.

With imap it's easy to require 40+ GB for a single account but still limit it to maybe 60GB so it can't fill up a cpanel account with a 120GB quota.

Ok so the issue here is the transferability from a 64 bit cpanel server to a 32 bit cpanel server ?

We stopped our last 32 bit server that was 6 years old about a year ago. I can't see why someone would move an account from a recent 64 bit server to an old 32 bit server. It's not safe to restore someone elses full backup so apart from adding a warning to say any quotas over 2GB will default to unlimited I don't see an issue here from a users perspective.

cPanel cannot stop supporting 32 bit systems. Users can't wait for cPanel to stop supporting centos 6 to get e-mail quotas working on normal sized imap accounts.

photo
2

The team working on this completed the investigation to ensure that all supported software works with the larger quota limits on 64 bit systems. The investigation did reveal that transferring an account with quotas over the 2GB limit to a 32bit system from a 64bit system can cause all new email to be bounced under some circumstances.

They have started on developing the tool to migrate mailbox quotas that exceed the maximum allowed when migrating accounts from 64 bit systems to 32 bit systems. Once that work is completed we will add API calls to get the limit based on the system and adjust all the interfaces to make use of the increased limits on 64 bit systems.

We are planning on implementing a 4 TB limit on 64 bit systems, and raising the default to 32GB on 64 bit systems.

photo
1

Great news ! I know some customers who will be delighted :)

photo
1

cpanelnick wrote:

The team working on this completed the investigation to ensure that all supported software works with the larger quota limits on 64 bit systems. The investigation did reveal that transferring an account with quotas over the 2GB limit to a 32bit system from a 64bit system can cause all new email to be bounced under some circumstances.

They have started on developing the tool to migrate mailbox quotas that exceed the maximum allowed when migrating accounts from 64 bit systems to 32 bit systems. Once that work is completed we will add API calls to get the limit based on the system and adjust all the interfaces to make use of the increased limits on 64 bit systems.

We are planning on implementing a 4 TB limit on 64 bit systems, and raising the default to 32GB on 64 bit systems.

Why just 32 GB? I guess a reasonable future proof default limit would be something like 1 TB. I guess there is someone somewhere needed a 100 GB email account... So if your'e doing software changes do them in a way we won't get back to this any time soon.

Thank you.

photo
1

TCB13 wrote:

Why just 32 GB? I guess a reasonable future proof default limit would be something like 1 TB. I guess there is someone somewhere needed a 100 GB email account... So if your'e doing software changes do them in a way we won't get back to this any time soon.

Thank you.

The on 64 bit default quota will be 32GB (unless overridden by the admin setting a default in Tweak Settings), the actual limit will be 4TB.

photo
1

I don't see the point of having a default of 32GB, we will be setting it back to 250 MB, all we wanted was to be able to set higher limits when required.

Our first hosting plan comes with 16 GB space so a default of 32 GB seems pointless.

With the tweak setting it will be easy to fix, however I would be interested to know why you want to set the default to such a high limit..

photo
2

There should be a third option in voting, "Yes, I want this since 6 years. Do it fast"

I am glad to see this thread and little disappointing with 11 votes ONLY hitting this request.

I highly agree with TCB13 on patching EXIM asap if all blame goes to EXIM. How difficult or time consuming it can get....!

If cPanel can't catch up with basic logical needs then it's sad to pay premium bucks, and we should better move to some open source or cheaper alternates.