UNLOCK the Percentage and Number of Failed or Deferred Messages a Domain May Send Per Hour
The following two outgoing mail settings must both be met before the server triggers a protective action and blocks the outgoing mail temporarily so your domain/IP/server doesn't end up blacklisted. This is a huge problem and imposes huge limitations on what these two options should be useful for.
1) Number of failed or deferred messages a domain may send before protections can be triggered
2) Maximum percentage of failed or deferred messages a domain may send per hour
Naming conventions for easy tracking:
- Number of failed or deferred messages a domain may send before protections can be triggered (max#)
- Maximum percentage of failed or deferred messages a domain may send per hour (max%).
- Both of these conditions are reached and the server temporarily blocks the outgoing mail from a domain (block).
- Successfully sent messages (S)
- Failed / deferred sent messages (FD).
- % of failed / deferred sent messages (FD%)
I'll explore a few of the scenarios:
DEFAULT:
max# - 5
max% - Unlimited (100%)
In this scenario for the block to occur server needs only to send FD in an hour, no S can be present. I would say this would be the worst scenario. Especially if you're a high-sending domain, you could send hundreds of FD and block would never occur.
HIGH max%:
max# - 5
max% - 60%
S - 430
FD - 7
FD% - 1.6
LOW max%:
max# - 5
max% - 1%
S - 430
FD - 7
FD% - 1.6
Imagine if your total sent mail is 3/h, 70/h, 800/h, 3000/h, there is no way to set up a ratio of max% and max# that would be anywhere near useful to encompass all of these. This seems so odd! Because both conditions must be met, this max% option is pretty much useless besides the default scenario (100%), which BTW is the worst scenario, where your server stops successfully sending mail and only sends FD messages.
SOLUTION 1:
Permanently unlock (not required to be met at the same time) these two max% and max# so the block can be triggered when either one of them is met.
SOLUTION 2:
Add a new checkbox option that locks/unlocks max% and max# for triggering the block.
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.
SOLUTION 3:
The probably least painless one to implement is to allow decimal percentages for max%. This way it can be set very low, for example, 0.1% or 0.01% so it would effectively "pass the baton" to the max# to dictate the block protection regardless of the volume of outgoing mail.
SOLUTION 3:
The probably least painless one to implement is to allow decimal percentages for max%. This way it can be set very low, for example, 0.1% or 0.01% so it would effectively "pass the baton" to the max# to dictate the block protection regardless of the volume of outgoing mail.
Let's pick a number of FDs that put us on the blacklist. For example 20.
max% 1% would be fine for up to 500/h because it will match the max# 5. But with each increasing hundred the number 5 will be increased by 1. So for:
1000/h block occurs at the 10th FD - still OK
2000/h block occurs at the 20th FD <===== BREAKING BAD :)
3000/h block occurs at the 30th FD - arguably BAD
5000/h block occurs at the 50th FD - BAD
10000/h block occurs at the 100th FD - BAD
So for higher traffic than 1000/h, to maintain the number of allowed FDs, 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 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 max% accordingly.
Let's explore the max% 5%.
100/h block occurs at the 5th FD - OK
300/h block occurs at the 15th FD - arguably OK
400/h block occurs at the 20th FD <===== BREAKING BAD :)
500/h block occurs at the 25th FD arguably BAD
1000/h block occurs at the 50th FD - BAD
3000/h block occurs at the 150th FD - BAD
5000/h block occurs at the 250th FD - BAD
10000/h block occurs at the 500th FD - BAD
Let's explore the max% 10%:
100/h block occurs at the 10th FD - still OK
200/h block occurs at the 20th FD <===== BREAKING BAD :)
300/h block occurs at the 30th FD - arguably BAD
500/h block occurs at the 50th FD - BAD
1000/h block occurs at the 100th FD - BAD
3000/h block occurs at the 300th FD - BAD
5000/h block occurs at the 500th FD - BAD
10000/h block occurs at the 1000th FD - BAD
So the higher max% screws up the higher traffic quicker, and low traffic gets screwed as well. For example, max% is 50% and the traffic is 5000/h and it drops suddenly in the next hour to 80/h which will trigger the block only at the 40th FD.
Let's pick a number of FDs that put us on the blacklist. For example 20.
max% 1% would be fine for up to 500/h because it will match the max# 5. But with each increasing hundred the number 5 will be increased by 1. So for:
1000/h block occurs at the 10th FD - still OK
2000/h block occurs at the 20th FD <===== BREAKING BAD :)
3000/h block occurs at the 30th FD - arguably BAD
5000/h block occurs at the 50th FD - BAD
10000/h block occurs at the 100th FD - BAD
So for higher traffic than 1000/h, to maintain the number of allowed FDs, 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 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 max% accordingly.
Let's explore the max% 5%.
100/h block occurs at the 5th FD - OK
300/h block occurs at the 15th FD - arguably OK
400/h block occurs at the 20th FD <===== BREAKING BAD :)
500/h block occurs at the 25th FD arguably BAD
1000/h block occurs at the 50th FD - BAD
3000/h block occurs at the 150th FD - BAD
5000/h block occurs at the 250th FD - BAD
10000/h block occurs at the 500th FD - BAD
Let's explore the max% 10%:
100/h block occurs at the 10th FD - still OK
200/h block occurs at the 20th FD <===== BREAKING BAD :)
300/h block occurs at the 30th FD - arguably BAD
500/h block occurs at the 50th FD - BAD
1000/h block occurs at the 100th FD - BAD
3000/h block occurs at the 300th FD - BAD
5000/h block occurs at the 500th FD - BAD
10000/h block occurs at the 1000th FD - BAD
So the higher max% screws up the higher traffic quicker, and low traffic gets screwed as well. For example, max% is 50% and the traffic is 5000/h and it drops suddenly in the next hour to 80/h which will trigger the block only at the 40th FD.
Replies have been locked on this page!