Hi, here's yet another thing which caused spurious authentication failures; luckily I was accidently in debug mode looking for something else when I found the cause for some failed auth: +++- entering policy redundant {...} [sql-imap-hash] expand: %{User-Name} -> pgloden [sql-imap-hash] sql_set_user escaped user --> 'pgloden' rlm_sql (sql-imap-hash): Reserving sql socket id: 7 [sql-imap-hash] expand: (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='%{SQL-User-Name}') -> (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='pgloden') rlm_sql_mysql: query: (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='pgloden') rlm_sql: Failed to create the pair: Non-hex characters at QX rlm_sql (sql-imap-hash): Error getting data from database [sql-imap-hash] SQL query error; rejecting user The query works just fine and returns a base64-encoded SSHA1 hash of a user's password. The base64 blob happens to start with the two characters "0X" (and then continues with QX, which is in the error message). It seems like the query response parser tries to be overly clever and thinks that anything starting with 0X is a hex number and needs decoding. This, of course, fails. Needsless to say that the schema doesn't suggest an integer at all, it's a varchar(168). The workaround right now for us is to set the hashed password, see if it happens to start with 0X, and if so, try with a different salt. That is obviously not very ideal. I would appreciate if 2.2.1 could stop hex-decoding non-hex values :-) I only saw this right now on yesterday's GIT; no idea if we've been hitting the wall with this earlier. The users in question didn't phone up our helpdesk yet, so maybe this crept in very recently? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473