This object is in archive!
EXIM Bandwidth limit check
Needs Feedback
Bandwidth limit check for EXIM, same as for HTTP
Bandwidth limit check [?]
Automatically suspend HTTP service for accounts that exceed their
bandwidth limit. Disabling this will disable all bandwidth notifications
and treat all accounts as having unlimited bandwidth.
Basically when you suspend the HTTP service, it should also suspend email
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.
Is this really a desirable feature for server owners? I personally would be terrified of any server that had such an option enabled.
In the shared hosting industry, customers almost never anticipate or expect hitting a bandwidth limit. Most are new to the concept of hosting. This is why the current form of suspension for shared hosting is a lenient one that suspends the primary service (their web hosting) but allows for critical items (like receiving email) to still occur. That way, when they do pay for the higher limit or roll over to the next month, that mail is still there and their penalty for bumping against the limit is temporary and low.
Enforcing a limit like you've advised shifts the state from "Bandwidth limit" to "Bandwidth punishment" in my eyes. Refusing mail during the overage state and causing a catastrophic failure of services for that customer seems a bit harsh at the shared hosting level.
In my opinion, if the user(s) in question are consuming beyond excessive bandwidth while still in a suspended state they should be treated as exceptions to the norm and handled manually.
However, I do want to hear if this is indeed a desirable feature by server owners. I could be blatantly wrong in my opinion and be the minority opinion amongst server owners.
Is this really a desirable feature for server owners? I personally would be terrified of any server that had such an option enabled.
In the shared hosting industry, customers almost never anticipate or expect hitting a bandwidth limit. Most are new to the concept of hosting. This is why the current form of suspension for shared hosting is a lenient one that suspends the primary service (their web hosting) but allows for critical items (like receiving email) to still occur. That way, when they do pay for the higher limit or roll over to the next month, that mail is still there and their penalty for bumping against the limit is temporary and low.
Enforcing a limit like you've advised shifts the state from "Bandwidth limit" to "Bandwidth punishment" in my eyes. Refusing mail during the overage state and causing a catastrophic failure of services for that customer seems a bit harsh at the shared hosting level.
In my opinion, if the user(s) in question are consuming beyond excessive bandwidth while still in a suspended state they should be treated as exceptions to the norm and handled manually.
However, I do want to hear if this is indeed a desirable feature by server owners. I could be blatantly wrong in my opinion and be the minority opinion amongst server owners.
Is this really a desirable feature for server owners? I personally would be terrified of any server that had such an option enabled.
In the shared hosting industry, customers almost never anticipate or expect hitting a bandwidth limit. Most are new to the concept of hosting. This is why the current form of suspension for shared hosting is a lenient one that suspends the primary service (their web hosting) but allows for critical items (like receiving email) to still occur. That way, when they do pay for the higher limit or roll over to the next month, that mail is still there and their penalty for bumping against the limit is temporary and low.
Enforcing a limit like you've advised shifts the state from "Bandwidth limit" to "Bandwidth punishment" in my eyes. Refusing mail during the overage state and causing a catastrophic failure of services for that customer seems a bit harsh at the shared hosting level.
In my opinion, if the user(s) in question are consuming beyond excessive bandwidth while still in a suspended state they should be treated as exceptions to the norm and handled manually.
However, I do want to hear if this is indeed a desirable feature by server owners. I could be blatantly wrong in my opinion and be the minority opinion amongst server owners.
Is this really a desirable feature for server owners? I personally would be terrified of any server that had such an option enabled.
In the shared hosting industry, customers almost never anticipate or expect hitting a bandwidth limit. Most are new to the concept of hosting. This is why the current form of suspension for shared hosting is a lenient one that suspends the primary service (their web hosting) but allows for critical items (like receiving email) to still occur. That way, when they do pay for the higher limit or roll over to the next month, that mail is still there and their penalty for bumping against the limit is temporary and low.
Enforcing a limit like you've advised shifts the state from "Bandwidth limit" to "Bandwidth punishment" in my eyes. Refusing mail during the overage state and causing a catastrophic failure of services for that customer seems a bit harsh at the shared hosting level.
In my opinion, if the user(s) in question are consuming beyond excessive bandwidth while still in a suspended state they should be treated as exceptions to the norm and handled manually.
However, I do want to hear if this is indeed a desirable feature by server owners. I could be blatantly wrong in my opinion and be the minority opinion amongst server owners.
One could argue the exact opposite of what you are saying with regards to HTTP being a critical service and the bandwidth limit is a bandwidth punishment :)
In most cases customers would respond to the bandwidth notifications and request more bandwidth, but in the case I experienced, a specific email account was compromised and the webmail interface was used to send out spam in excess of 300% of the accounts monthly limits within a matter of minutes.
And yes this is the exception to the rule, and is exactly why you want an automated system to block the traffic.
The feature request is for an additional "tickbox", not linking exim to the same "tickbox". This would give the server admin the ability to make a choice on how he wants bandwidth limits applied, neither, either or both.
Some clients only use the mail hosting option, without any web traffic. So they would actually never experience a limit in bandwidth
Im more than willing to run any custom script/solution, but couldn’t find anything out there.
When you are connected to a high speed backbone, you don’t want to rate limit everything, you want to run at full speed, which is why you implement & monitor bandwidth limits for those instances where something "adhoc" happens, so that it does not bring the entire server down.
One could argue the exact opposite of what you are saying with regards to HTTP being a critical service and the bandwidth limit is a bandwidth punishment :)
In most cases customers would respond to the bandwidth notifications and request more bandwidth, but in the case I experienced, a specific email account was compromised and the webmail interface was used to send out spam in excess of 300% of the accounts monthly limits within a matter of minutes.
And yes this is the exception to the rule, and is exactly why you want an automated system to block the traffic.
The feature request is for an additional "tickbox", not linking exim to the same "tickbox". This would give the server admin the ability to make a choice on how he wants bandwidth limits applied, neither, either or both.
Some clients only use the mail hosting option, without any web traffic. So they would actually never experience a limit in bandwidth
Im more than willing to run any custom script/solution, but couldn’t find anything out there.
When you are connected to a high speed backbone, you don’t want to rate limit everything, you want to run at full speed, which is why you implement & monitor bandwidth limits for those instances where something "adhoc" happens, so that it does not bring the entire server down.
Replies have been locked on this page!