Apparently the "Prevent Common Passwords" function in SmarterMail's Password Requirements is exclusive and not inclusive. Meaning that since the word "password" is listed in the \Service\common_passwords.xml this prevents the use of "password" for a password, but not "Password" or "paSSwOrd", "PASSWORD", "mypassword", or even "password1!". For another example "trustno1" is in the \Service\common_passwords.xml but "TrustNo1", "trustno1!", "donttrustno1", and "Itrustno1" are still all allowed as a new password.

Here's a suggestion:

Other than modify the common_passwords.xml to include every possible variation of the top 500 most common passwords, can there be an inclusive flag in the Password Requirements that prevents any entry in the common_passwords.xml to appear anywhere in the password as a string and is not case-sensitive? At the very least the Prevent Common Passwords absolutely should not be case-sensitive, IMHO.

Post-Script: Upon further consideration let's bump that suggestion up a notch and request that Prevent Common Passwords checks haveibeenpwned.com's NIST Digital Identity database of compromised passwords and blocks these from being used as a new password. The beta builds of Google Chrome and Mozilla Firefox now do this. Smartermail should too.