What is current CommSuite support for non-ASCII passwords?

Question

Hello all,
Some of our users managed to change their passwords to non-ASCII strings (via replication from MSAD by ISW) and no longer have access to their communications services.
While replicating the problem, I have set a (UTF-8 non-ASCII) string as my password in DSEE directly, and *can* log in to Convergence with this password. However, if I change the working password to a non-ASCII string from Convergence itself - it is accepted during the secondary password check, there is no error returned, SOME password is apparently saved into the LDAP directory, but neither of the original non-ASCII plaintext strings can be used for login back into Convergence. Restoration of access is only doable by admin at this point.
Checking email by IMAP from Thunderbird no longer works with a changed non-ASCII password (including the state when it still works for Convergence).
Delegated Admin has an explicit check for non-ASCII characters in the password and refuses to set a misbehaving one.
I see that among the standards supported by CommSuite, there is IMAP4rev1, and RFC 5255 refers to it as the reason that non-ASCII passwords and usernames are for now not supported, though this is expected to be a temporary state of things, and software can prepare for the future by implementing checks for valid UTF-8 strings as well.
https://wikis.oracle.com/display/CommSuite/Messaging+Server+Supported+Standards
http://tools.ietf.org/html/rfc5255
5.1.  Unicode Userids and Passwords
   IMAP4rev1 currently restricts the userid and password fields of the
   LOGIN command to US-ASCII.  The "userid" and "password" fields of the
   IMAP LOGIN command are restricted to US-ASCII only until a future
   standards track RFC states otherwise.  Servers are encouraged to
   validate both fields to make sure they conform to the formal syntax
   of UTF-8 and to reject the LOGIN command if that syntax is violated.
   Servers MAY reject the LOGIN command if either the "userid" or
   "password" field contains an octet with the highest bit set.
   When AUTHENTICATE is used, some servers may support userids and
   passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows
   that.  However, such userids cannot be used as part of email
   addresses.
So, the main question at this point is: does or does not all of the CommSuite stack support non-ASCII passwords?
If no - please confirm, so we can instruct the users to not create problems for themselves (and maybe manage to set up some policy to not accept non-ASCII passwords to MSAD/DSEE in the first place).
If yes - what should be done to enable support in Convergence/IMAP/SMTP/XMPP/WCAP/WABP/... services - perhaps, setting the LANG/LC_ALL locale environment variables or equivalent JVM flags for UTF-8 in server startup scripts, etc.? (I know that DSEE ldapsearch requires either envvars or a command-line flag for charset encoding of values, so I figure similar quirks may be relevant for some other software)
Thanks in advance for either response,
//Jim Klimov

Answer 1

I can't respond for the suite, but the Messaging Server product should work with UTF-8 usernames and passwords as long as the standard SASL authentication mechanisms that are documented to use UTF-8 are used (e.g. SASL PLAIN). IMAP LOGIN may work fine with UTF-8 as well even though that's non-standard. We do not implement SASLprep, however, so the strings provided by the client to the server must be identical UTF-8 strings for authentication to succeed. If they are provided in a different decomposition, different canonical form or non-standard charset, that's not supported and will fail. We don't test this scenario extensively, so you may encounter bugs (that we'd have to prioritize and fix as with other bugs). Messaging Server recently implemented a restricted option (broken_client_login_charset) for a customer who was stuck with broken clients that sent ISO-8859-1 for the IMAP login command arguments.