Maximum Hourly Email Quota Suggestion?
1) I'm creating packages and I would like to know what is the optimal value for "Maximum Hourly Email by Domain Relayed" and "Maximum percentage of failed or deferred messages a domain may send per hour"?
2) What exactly is included in Hourly Email by Domain Relayed: sent and received mail from all inboxes on a domain? Is this monitored and limited for each domain separately?
3) I know this isn't strictly related but it ties in with creating packages: Can I get a suggestion for the number of "Max Passenger Applications"?
Here are the basic specifications for 4 packages that I want to create so you get the picture of what I'm shooting for 5-15-30-60 GB SSD and 1-5-10-20 domains.
-
Hey there! I wouldn't change these values based on packages, personally. The whole point of their existence is to help protect the server's IP reputation in case an account is compromised and the account starts to send spam. I would bet that 99% of cPanel users leave these set to the default values. 0 -
Hey Rex! Thank you. By default, Maximum Hourly Email is set to unlimited, pretty lenient. I just thought it would be wiser to limit it to some number. Can you please answer my 2) question about it? The Maximum percentage of failed sent per hour is 100%. Does that mean that if 100% of messages fail in an hour, the outgoing mail will be blocked? Pretty lenient too. Max Passenger Applications is 4. Any thoughts on this? How much impact can they have on the server? 0 -
For the "Maximum percent of failed or deferred messages a domain may send per hour" option: This option specifies the maximum percentage of failed or deferred messages that a domain may send per hour. This option only applies after the number of failed or deferred messages reaches the Number of failed or deferred messages a domain may send before protections can be triggered option"s value. So it is based off that other number. Details on how those features interact can be found here: 0 -
Max Passenger Applications is 4. Any thoughts on this? How much impact can they have on the server?
In a shared hosting environment, 4 per client should be more than sufficient. The impact each application will or can have is an unknown until the application is running in production, so it's best to try to minimize the overall amount of applications allowed.0 -
That was a great answer thank you! [QUOTE]This typically refers to both sent and received emails for all mailboxes within a specific domain. Yes, it should be monitored and limited for each domain separately.
Take a look at
While I'm learinng all this can we talk more about where and how in the WHM/cPanel interface can this be monitored?0 -
Hey there! I wouldn't change these values based on packages, personally. The whole point of their existence is to help protect the server's IP reputation in case an account is compromised and the account starts to send spam. I would bet that 99% of cPanel users leave these set to the default values.
For the "Maximum percent of failed or deferred messages a domain may send per hour" option: This option specifies the maximum percentage of failed or deferred messages that a domain may send per hour. This option only applies after the number of failed or deferred messages reaches the Number of failed or deferred messages a domain may send before protections can be triggered option"s value. So it is based off that other number. Details on how those features interact can be found here:
0 -
What specific situation are you trying to avoid? 0 -
I don't have enough knowledge on blacklisting triggers so I can't answer that. I just analyzed the math behind these options and it doesn't stick. No matter how you set the [COLOR=rgb(44, 130, 201)]max% it won't cover all the mail quotas properly. 0 -
You are correct that the default may not work well for some systems as that is set to unlimited. Changing that percentage is the way to go if you plan on setting up a shared server or don't have full control over all the email being sent from the server. We have a bit more information on this at the following page: How to Prevent Spam with Mail Limiting Features | cPanel & WHM Documentation Which says this: Your server will temporarily block outgoing mail from a domain if both of the following conditions are true: -The percentage of failed or deferred messages, out of the total number of messages that the domain sent, is equal to or greater than the percentage that you specify for the Maximum percentage of failed or deferred messages a domain may send per hour option. -The domain has sent at least the number of failed or deferred messages that you specify for the Number of failed or deferred messages a domain may send before protections can be triggered option.
Basically, you'd just want to use a lower percentage such as what is listed in your "low" example.0 -
Let's pick a number of [COLOR=rgb(184, 49, 47)]FDs that put us on the blacklist. For example 20. [COLOR=rgb(44, 130, 201)]max% 1% would be fine for up to 500/h because it will match the [COLOR=rgb(44, 130, 201)]max# 5. But with each increasing hundred the number 5 will be increased by 1. So for: 1000/h [COLOR=rgb(147, 101, 184)]block occurs at the 10th [COLOR=rgb(184, 49, 47)]FD - still OK 2000/h [COLOR=rgb(147, 101, 184)]block occurs at the 20th [COLOR=rgb(184, 49, 47)]FD <===== BREAKING BAD :) 3000/h [COLOR=rgb(147, 101, 184)]block occurs at the 30th [COLOR=rgb(184, 49, 47)]FD - arguably BAD 5000/h [COLOR=rgb(147, 101, 184)]block occurs at the 50th [COLOR=rgb(184, 49, 47)]FD - BAD 10000/h [COLOR=rgb(147, 101, 184)]block occurs at the 100th [COLOR=rgb(184, 49, 47)]FD - BAD So for higher traffic than 1000/h, to maintain the number of allowed [COLOR=rgb(184, 49, 47)]FDs, [COLOR=rgb(44, 130, 201)]max% needs to be decreased below 1%, which is not allowed since 1 is the minimum value. So with each new thousand, we will allow 10 more [COLOR=rgb(184, 49, 47)]FDs. One of the ways to solve this would be to allow decimal percentages. But that is also a quick fix because you would still need to manually monitor traffic and adjust [COLOR=rgb(44, 130, 201)]max% accordingly. Let's explore the [COLOR=rgb(44, 130, 201)]max% 5%. 100/h [COLOR=rgb(147, 101, 184)]block occurs at the 5th [COLOR=rgb(184, 49, 47)]FD - OK 300/h [COLOR=rgb(147, 101, 184)]block occurs at the 15th [COLOR=rgb(184, 49, 47)]FD - arguably OK 400/h [COLOR=rgb(147, 101, 184)]block occurs at the 20th [COLOR=rgb(184, 49, 47)]FD <===== BREAKING BAD :) 500/h [COLOR=rgb(147, 101, 184)]block occurs at the 25th [COLOR=rgb(184, 49, 47)]FD arguably BAD 1000/h [COLOR=rgb(147, 101, 184)]block occurs at the 50th [COLOR=rgb(184, 49, 47)]FD - BAD 3000/h [COLOR=rgb(147, 101, 184)]block occurs at the 150th [COLOR=rgb(184, 49, 47)]FD - BAD 5000/h [COLOR=rgb(147, 101, 184)]block occurs at the 250th [COLOR=rgb(184, 49, 47)]FD - BAD 10000/h [COLOR=rgb(147, 101, 184)]block occurs at the 500th [COLOR=rgb(184, 49, 47)]FD - BAD Let's explore the [COLOR=rgb(44, 130, 201)]max% 10%: 100/h [COLOR=rgb(147, 101, 184)]block occurs at the 10th [COLOR=rgb(184, 49, 47)]FD - still OK 200/h [COLOR=rgb(147, 101, 184)]block occurs at the 20th [COLOR=rgb(184, 49, 47)]FD <===== BREAKING BAD :) 300/h [COLOR=rgb(147, 101, 184)]block occurs at the 30th [COLOR=rgb(184, 49, 47)]FD - arguably BAD 500/h [COLOR=rgb(147, 101, 184)]block occurs at the 50th [COLOR=rgb(184, 49, 47)]FD - BAD 1000/h [COLOR=rgb(147, 101, 184)]block occurs at the 100th [COLOR=rgb(184, 49, 47)]FD - BAD 3000/h [COLOR=rgb(147, 101, 184)]block occurs at the 300th [COLOR=rgb(184, 49, 47)]FD - BAD 5000/h [COLOR=rgb(147, 101, 184)]block occurs at the 500th [COLOR=rgb(184, 49, 47)]FD - BAD 10000/h [COLOR=rgb(147, 101, 184)]block occurs at the 1000th [COLOR=rgb(184, 49, 47)]FD - BAD So the higher [COLOR=rgb(44, 130, 201)]max% screws up the higher traffic quicker, and low traffic gets screwed as well. For example, [COLOR=rgb(44, 130, 201)]max% is 50% and the traffic is 5000/h and it drops suddenly in the next hour to 80/h which will trigger the [COLOR=rgb(147, 101, 184)]block only at the 40th [COLOR=rgb(184, 49, 47)]FD. I've added a feature request to the Features forum, it's been 2 days and it's still on moderation. 0 -
My 2 cents: How many emails you want to allow per hour depends on the type of clients. If they have several users who email, you should set this to a high figure, otherwise, a low figure works well. I generally set at 300 or 500 for most domains and 1000 for active domains with several email users. Then I increase or decrease these values as required. The compromised email accounts get suspended fairly quickly saving the server from much damage. You should also monitor your server in Rbl lists regularly. 0 -
I reached out to the team and that has been approved! 0 -
Thank you Rex! I have one more question about the [COLOR=rgb(44, 130, 201)]max%[COLOR=rgb(0, 0, 0)]. We can set its value in Tweak Settings but there is also an option to set it in the Add/Edit Package interface. Does this override the global setting and how exactly? Documentation is unclear about this. For example, documentation is clear that "Maximum Hourly Email by Domain Relayed" from Add/Edit Package overrides the "Max hourly emails per domain" from Tweak Settings. 0 -
Yes, if it is configured in a package that would override the global settings. 0 -
One of my reseller trying to add a package but " Maximum Hourly Email by Domain Relayed " shows only 0 value but in Global settings it is set to 500, from which location it is taking up that 0 value. 0 -
One of my reseller trying to add a package but " Maximum Hourly Email by Domain Relayed " shows only 0 value but in Global settings it is set to 500, from which location it is taking up that 0 value.
What value do you have set for the reseller's package? If that is set to "0", that would be why.0
Please sign in to leave a comment.
Comments
17 comments