Univention Bugzilla – Bug 41937
Dovecot/IMAP authentication with non-ASCII password
Last modified: 2019-01-03 07:18:39 CET
IMAP seems to only support ASCII for username and password: <http://www.dovecot.org/list/dovecot/2008-November/035267.html> Although IMAP 3051 "Formal Syntax" says: login = "LOGIN" SP userid SP password userid = astring password = astring astring = 1*ASTRING-CHAR / string string = quoted / literal literal = "{" number "}" CRLF *CHAR8 ; Number represents the number of CHAR8s CHAR8 = %x01-ff ; any OCTET except NUL, %x00 <https://tools.ietf.org/html/rfc3501#section-9> So it seems to be possible to have all bytes except 0x00 in username/password. But the encoding (i.e. the way to correctly convert those bytes into characters) is still undefined, as the charset can only be specified for search commands and body responses. Testing with Windows 7 & Thunderbird: Using a password with non-ASCII characters leads to a one-byte-per-character in the Dovecot logs. Login with Python imaplib works if the password bytes are the UTF-8 encoding of the password, it fails if they are the ISO 8859-1 encoding. It probably only works with UTF-8 only because it is the same encoding as used by crypt(3) on the server, Dovecot seems to treat the received bytes as opaque bytes instead of as characters (i.e. decoding them according to encoding). There is also RFC 5738 <https://tools.ietf.org/html/rfc5738#section-5> but Dovecot does not seem to support it. The string u'euro€umlautäöü' entered as the password in Thunderbird on Windows 7 lead to the following bytes being received by dovecot 'euro\xacumlaut\xe4\xf6\xfc' . This seems like an ISO 8859 based encoding, but I could not find any encoding that has "€" as 0xAC. Possible solutions: Patch Dovecot to correctly decode passwords and try a few different encodings if username/password are not valid UTF-8. Patch Dovecot to advertise the "UTF8=USER" capability because UTF-8 currently works "by accident" and hope that the clients support it. Investigate other authentication methods for correct handling of characters (, but PLAIN support is required by the standard…).
Reported by customer in #2016080821000205
There was a discussion about this problem on the dovecot list with a workaround for SQL-auth-backends: http://www.dovecot.org/list/dovecot/2008-November/035278.html The problem with password encoding (described earlier in the thread) is that most clients do not encode the password to 7bit, but simply send them however the OS feels like (most often Windows-1252). The IMAP-server has no way of knowing the clients encoding, and must save and compare the password as given → binary. So if a user always uses the same client and OS → same encoding, there would be "no problem". What's the encoding UCS stored password in? Maybe we could modify our PAM module pam-univentionmailcyrus to reencode the clients password and try again?
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.