create account error
Account Creation Status: failed
| Invalid value “200” for the “max_email_per_hour” setting. |
-
Hey there! I'm able to set this to 200 on a test machine with no issues. Is it possible that you are logged in to WHM as a reseller account and you are hitting a restriction on that reseller account? If not, do you see any additional details inside the main cPanel log at /usr/local/cpanel/logs/error_log?
0 -
I'm having the same error on editing a package where I want to set a higher max_email_per_hour setting than the one set in "Max hourly emails per domain" in Tweak Settings. I want to have a default 100 e-mails per hour setting, forced for all accounts and for reseller ones and only have some special packages with more e-mails allowed. This used to work before, but now it raises the specified error.
0 -
aluputi - I never heard back from the OP and I wasn't able to reproduce the error. If you can get me specific steps about how I can reproduce this I'd be happy to test again, or you're always welcome to submit a ticket so we can see this in real-time on your machine. You can also check /usr/local/cpanel/logs/error_log to see if there is more information there.
0 -
Please try the following steps:
1. Set "Max hourly emails per domain" in "Tweak Settings" to 100.
2. Try to edit an account / a package and set "Maximum Hourly Email by Domain Relayed" above 100.You will receive the specified error, I think there's a validation that "max_email_per_hour" must be lower than the value set in "Tweak Settings" but this should be allowed.
Thanks!
0 -
The "Maximum Hourly Email by Domain Relayed" setting in the Edit a Package interface can set a lower maximum hourly email limit than the Max hourly emails per domain setting, but cannot set a higher limit.
0 -
What quietFinn said - does that help clear things up?
0 -
No, it doesn't. Please try to understand the usability cause of the issue and not only from a technical point of view. I want to setup a general 100 e-mail per hour limit for the server, but I want to allow certain accounts / packages to have a higher limit. This can't be done anymore because of the validation issue that doesn't allow a higher value to be set.
This used to work and has been working for years, I've noticed the issue only a few months ago.
By the way, lowering the general value in "Tweak Settings" below the ones from packages works, so the validation doesn't go both ways, but after that all packages with higher values give the specified error on any change.
0 -
Would you not be able to just create a different package for the account?
0 -
How could you create a package with higher e-mail count since it throws the error, that being the main issue we're discussing here?
Sorry but I feel I'm talking to an AI...
0 -
I think the best option at this point would be a feature request, since I don't believe our team intends that value to be overridden. And I was misread the earlier comment that led me to my "package" reply.
I can bring this up with the team during our next features meeting (Friday) and see what they say if you'd like!
0 -
Yes, please do! As I've said, this used to work and this kind of usage is normal. Setting a default limit must allow setting higher or lower specific values, where needed.
0 -
I've got it on the list and I'll be sure to let you know!
0 -
I believe this to prevent resellers from setting higher values in packages.
0 -
This is exactly why maximum e-mails in "Tweak Settings" is set to 100 and not higher, because I don't want resellers to be able to create packages with higher limits. In "Reseller Privileges" I have unchecked "Create Packages with Custom Email Limits" so all the reseller packages have the 100 e-mails limit.
But I want to have some packages with higher values, hence the requirement to be able to set higher limits in packages than the default ones, as root.
0 -
I spoke with the team about this and they let me know we do not intend to allow users to bypass that global limit. The best option here would be to raise the global limit to the highest you would ever need and then create packages with lower limits specifically for the account(s) in question.
I'm sorry I don't have better news on this one for you.
0 -
That's very unfortunate, how can I restrict the limit of reseller packages to a lower value? If I set the highest possible value in "Tweak Settings" I don't want the resellers to be able to have that limit.
Also, there is a bug, if there are packages that already have a higher limit, lowering the value in "Tweak Settings" doesn't show any error. The validation should go both ways, not only on editing packages. As a workaround, this is how I'm setting higher package limits, by lowering the "Tweak Settings" value after modifying packages.
0 -
I think that gets us down to a better feature request - "Allow 'Max hourly emails per domain' to be adjusted at the reseller level" as that currently is not an option. That's something that I can see us doing, and I've submitted the request to bring it up with the team.
There isn't a direct correlation to this value in packages, with the closest being "Maximum Hourly Email by Domain Relayed" but they aren't entirely the same, so I'm not sure I'd call that an issue since "Maximum Hourly Email by Domain" isn't a package option. Would you also like that to be a package option as well? It would still be limited by Tweak Settings, but should give you more control.
0 -
I think it would be a good idea to be able to set different (lower) limits for the resellers.
Since "Maximum Hourly Email by Domain Relayed" is limited to the value of "Max hourly emails per domain", being able to set this lower than the highest value from packages leads to "invalid" ones, that don't pass validations on future editing.
For example, having "Maximum Hourly Email by Domain Relayed" set to 300 in packages doesn't restrict me setting "Max hourly emails per domain" to 100 in "Tweak Settings", but any editing of the package will show an error regarding this, even if the value hasn't changed. So, I think this validation should go both ways.
Also, in the above described situation, which would be the limit of the package? 100, as set in "Tweak Settings" or 300 as set in the package?
0 -
The value can't be set higher *globally* in a package, so the Tweak Settings value should take precedence.
0 -
Update - I talked with the team again about that package and apparently the core of the issue is the way that Exim handles this behavior, and having specific user-level filtering for the number of emails per domain would be a major change to how things are handled in Exim. Since that is the case, there aren't going to be changes to this option to allow for resellers to have a different value at this time.
As far as the package conflicts mentioned above, I do get the confirmation box that a higher number for the "Maximum Hourly Email by Domain Relayed" setting than the Tweak Settings "Maximum Hourly Email by Domain" is an invalid configuration, although that error message could certainly be more user friendly. I've created case CPANEL-49348 for our team to make that error message a bit better.
As far as the Tweak Settings validation of existing values in packages, I've created case CPANEL-49350 to have the team look into that. I can't say for sure if that's something they'll want to add, because then we could probably make the case that a *lot* of the adjustments in Tweak Settings could have additional validation added, but I've linked this thread to the case and I'll let you know if I hear anything on my end.
0 -
The cpanel article has a flaw, I don't know when this rule was created, but it broke packages that had already been created and even when editing the error, regardless of whether you enter a value above or below what is configured in Tweak Settings.
If this is happening to you:
1) Access the server via SSH
2) Go to /var/cpanel/packages/
3) List packages using 'ls'
4) Manually edit the package that has the problem, remove the MAX_EMAIL_PER_HOUR line
5) Save the file
6) On the WHM package edit screen, change the maximum emails per hour value and saveYou will now be able to create accounts again
0
Please sign in to leave a comment.
Comments
21 comments