Hi Rick,

Thanks for bringing this to our attention! I've made the development team aware. We'll provide updates here as they are available. 

Rick,  which API call are you invoking that is not enforcing the password change?  Additionally, are you using system admin credentials or domain/user credentials when invoking the API?

Rick, after much code review in SmarterMail 15, 16, and 17, we noted that the code is working as intended.  If a system admin creates or modifies a password, the password requirements would be exempt from the checks.  The argument could go either way as to whether or not this should be the case.  Because of this thread and the ensuing discussions, we have changed this behavior in SmarterMail 17.  Password creation/modification must adhere to the password requirements.  API calls will fail and state the reasons if the passwords are non-compliant.

Sorry I did not answer sooner. The problem with allowing un-checked password changes via API was that to manage smartermail in a control panel, the API was being called as an admin, so users were able to override the password requirements simply by adjusting panel settings which then allowed them to set weak passwords or re-use old passwords.

Glad to hear this is being adjusted in 17. Thanks!