Limit emails kept on server per account
The IO's on forgotten emails or catch emails can get out of control and damage the server.
An amazing option is to set an overall limit of emails allowed on the server for a given email address.
For example email@your-main-domain.com would have a 10k email limit. Just like sending limits or space limits this overall email limit would avoid rogue email addresses from using hundreds of thousands inodes and degrading the performance of the server.
It would in the in the WHM and not seen by the users. In the email limit section you could search emails to limit one by one or have the ability to batch several emails to a limit. It would also have a default limit that would be set for each new account on the server.
Or you could just add an overall email limit per package in the create and manage packages section. This might be useful for offering an upgrade to customers.
I just think it would need to be set per account without cvhanging the package as well.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
I can't say that I've ever run into I/O issues on Maildir due to the number of inodes (number of messages) within an account. One of the huge benefits of our move from mbox to Maildir many years ago was that each message was in its own file versus one giant storage file. This means that, even if there are a million messages, the only way those million messages affect anything is if some request is made by the connecting client to act on all million of those messages.
I'd like to hear feedback from other providers on if they've experienced this, as I've yet to observe it.
Regardless, the functionality you're looking for exists in Exim. It's called "quota_filecount". (Exim Documentation)
The biggest problem with utilizing this is that it is not the same type of directive as "quota". By this, I mean that "quota" accepts an expression, which permits us to tell Exim to look in /home/$user/etc/$domain/quota and dynamically pull the quota limit on a per-email address level.
With "quota_filecount", it only accepts a raw integer. This means that it's limited to a server-wide enforced single limit, designing hundreds/thousands of separate transports (one per mail account), or trying to build some custom in-house subroutines in exim.pl to figure this out and re-invent the directive as a custom implementation.
The massive transports would likely bring Exim to its knees performance wise. The pure custom implementation would have me concerned that the I/O spent on enforcing the cap (needing to be calculated on each mail delivery) would be more expensive than whatever I/O you're seeing.
In short, if a server-wide all encompassing single inode cap is insufficient, then this needs significantly more research into its viability. In either case, I'd like to see how interested others are in something like this and if there is value in it.
I can't say that I've ever run into I/O issues on Maildir due to the number of inodes (number of messages) within an account. One of the huge benefits of our move from mbox to Maildir many years ago was that each message was in its own file versus one giant storage file. This means that, even if there are a million messages, the only way those million messages affect anything is if some request is made by the connecting client to act on all million of those messages.
I'd like to hear feedback from other providers on if they've experienced this, as I've yet to observe it.
Regardless, the functionality you're looking for exists in Exim. It's called "quota_filecount". (Exim Documentation)
The biggest problem with utilizing this is that it is not the same type of directive as "quota". By this, I mean that "quota" accepts an expression, which permits us to tell Exim to look in /home/$user/etc/$domain/quota and dynamically pull the quota limit on a per-email address level.
With "quota_filecount", it only accepts a raw integer. This means that it's limited to a server-wide enforced single limit, designing hundreds/thousands of separate transports (one per mail account), or trying to build some custom in-house subroutines in exim.pl to figure this out and re-invent the directive as a custom implementation.
The massive transports would likely bring Exim to its knees performance wise. The pure custom implementation would have me concerned that the I/O spent on enforcing the cap (needing to be calculated on each mail delivery) would be more expensive than whatever I/O you're seeing.
In short, if a server-wide all encompassing single inode cap is insufficient, then this needs significantly more research into its viability. In either case, I'd like to see how interested others are in something like this and if there is value in it.
I can't say that I've ever run into I/O issues on Maildir due to the number of inodes (number of messages) within an account. One of the huge benefits of our move from mbox to Maildir many years ago was that each message was in its own file versus one giant storage file. This means that, even if there are a million messages, the only way those million messages affect anything is if some request is made by the connecting client to act on all million of those messages.
I'd like to hear feedback from other providers on if they've experienced this, as I've yet to observe it.
Regardless, the functionality you're looking for exists in Exim. It's called "quota_filecount". (Exim Documentation)
The biggest problem with utilizing this is that it is not the same type of directive as "quota". By this, I mean that "quota" accepts an expression, which permits us to tell Exim to look in /home/$user/etc/$domain/quota and dynamically pull the quota limit on a per-email address level.
With "quota_filecount", it only accepts a raw integer. This means that it's limited to a server-wide enforced single limit, designing hundreds/thousands of separate transports (one per mail account), or trying to build some custom in-house subroutines in exim.pl to figure this out and re-invent the directive as a custom implementation.
The massive transports would likely bring Exim to its knees performance wise. The pure custom implementation would have me concerned that the I/O spent on enforcing the cap (needing to be calculated on each mail delivery) would be more expensive than whatever I/O you're seeing.
In short, if a server-wide all encompassing single inode cap is insufficient, then this needs significantly more research into its viability. In either case, I'd like to see how interested others are in something like this and if there is value in it.
I can't say that I've ever run into I/O issues on Maildir due to the number of inodes (number of messages) within an account. One of the huge benefits of our move from mbox to Maildir many years ago was that each message was in its own file versus one giant storage file. This means that, even if there are a million messages, the only way those million messages affect anything is if some request is made by the connecting client to act on all million of those messages.
I'd like to hear feedback from other providers on if they've experienced this, as I've yet to observe it.
Regardless, the functionality you're looking for exists in Exim. It's called "quota_filecount". (Exim Documentation)
The biggest problem with utilizing this is that it is not the same type of directive as "quota". By this, I mean that "quota" accepts an expression, which permits us to tell Exim to look in /home/$user/etc/$domain/quota and dynamically pull the quota limit on a per-email address level.
With "quota_filecount", it only accepts a raw integer. This means that it's limited to a server-wide enforced single limit, designing hundreds/thousands of separate transports (one per mail account), or trying to build some custom in-house subroutines in exim.pl to figure this out and re-invent the directive as a custom implementation.
The massive transports would likely bring Exim to its knees performance wise. The pure custom implementation would have me concerned that the I/O spent on enforcing the cap (needing to be calculated on each mail delivery) would be more expensive than whatever I/O you're seeing.
In short, if a server-wide all encompassing single inode cap is insufficient, then this needs significantly more research into its viability. In either case, I'd like to see how interested others are in something like this and if there is value in it.
I was just about to create feature quest but noticed this and so will just add to this.
What you have to take into account is if a customer has 100k emails and so do it can cause issues for the backup server when doing compressed backups. Even cause an issue with incremental when running for the first time.
In short, high inode usage for emails can cause higher server load on production server hosting the sites and the backup servers during some tasks.
We run https://storagespider.com and can see how much issues it can cause when small email account in filesize but contain 50k plus emails can cause problems. A lot of providers usually include around 250k inodes for the complete account by default and because of this I have seen some accounts easily use up to 100-150k because of containing spam or the customer is using the account for archiving.
It would be could if we could limit inode usage for emails too and offer different plans like
Up to 1k emails
Up to 3k emails
Up to 5k emails
Up to 10k emails
Up to 20k emails
and so on....
I wonder whether this would be best checked by cPanel or CloudLinux given CloudLinux?
I was just about to create feature quest but noticed this and so will just add to this.
What you have to take into account is if a customer has 100k emails and so do it can cause issues for the backup server when doing compressed backups. Even cause an issue with incremental when running for the first time.
In short, high inode usage for emails can cause higher server load on production server hosting the sites and the backup servers during some tasks.
We run https://storagespider.com and can see how much issues it can cause when small email account in filesize but contain 50k plus emails can cause problems. A lot of providers usually include around 250k inodes for the complete account by default and because of this I have seen some accounts easily use up to 100-150k because of containing spam or the customer is using the account for archiving.
It would be could if we could limit inode usage for emails too and offer different plans like
Up to 1k emails
Up to 3k emails
Up to 5k emails
Up to 10k emails
Up to 20k emails
and so on....
I wonder whether this would be best checked by cPanel or CloudLinux given CloudLinux?
Replies have been locked on this page!