On Tue, Nov 18, 2008 at 05:51:05PM +0200, Timo Sirainen wrote:
On Nov 18, 2008, at 5:32 PM, Fredrik Grönqvist wrote:
Is there a setting that "forces" the authentication daemon to
convert the provided password to a specific charset before the
comparison takes place, or how should one handle this?Dovecot doesn't know the character set that the client is using, so it
can't do charset conversion reliably. So the possibilities would be:a) UTF-8 vs. another 8bit charset can be detected pretty well by
checking if the input string is valid UTF-8 or not. So there could be
a setting to specify the fallback charset.b) Just brute force through all the configured charsets and test the
password against all of them.I don't really like either solution and I don't have much interest in
coding those myself. Feel free to do it yourself though, I might even
accept patches. :)
It seems like this is a limitation in the IMAP protocol. From RFC 3501:
Characters are 7-bit US-ASCII unless otherwise specified. Other character sets are indicated using a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET]. CHARSETs have important additional semantics in addition to defining character set; refer to these documents for more detail.
The SEARCH command has this optional CHARSET flag (to search in messages in non-ascii charsets) but it seems like the LOGIN command should accept only 7-bit ASCII arguments...
Geert