You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The actual reason why the domain is shown as not protected is that something had messed up related APS resources and that caused the protection to "break". In order to restore everything the protection procedure has to be re-executed. But during the protection the "add domain to the spamfilter" step fails due to the error like:
mx.example.com cannot be a destination.
Such spamfilter API behavior is correct as it prevents possible email loops but the thing is that the domain is already in the spamfilter and all it's email is being processed.
Removing a problematic domain from the spamfilter and re-executing the protection procedure would solve this but it's not always a convenient option.
So in order to resolve such cases a workaround has to be implemented which would not cause the whole protection procedure to fail if the "add domain" step has failed due to an inappropriate destination.
Since existing procedures are not broken and a new branch in the protection procedure needs to be implemented this issue does not classify as a bug.
Version information
APS version 2.0-17.
Steps to replicate
1.Client logs in via APS
2. He gets an error after logging in
3. He cannot login again via aps
Actual result
The domain is not shown as protected and the user cannot login anymore
Expected result
The user should be able to login and the domain status should show as protected
Other notes
Attached screenshots, without the 3rd one as it contains logs.
WHMCS: #609912
The text was updated successfully, but these errors were encountered: