On Nov 19, 2008, at 8:14 PM, David Jonas wrote:
When using proxy_maybe CRAM-MD5 authentication fails when the
connection is proxied. Is this expected behavior? Is proxy_maybe too simplified
for this case?
Fails how?
We're using SQL so I could rewrite the query with IFs to fake proxy_maybe and return the password as NULL and nologin as Y, but if
it works that way couldn't it work with proxy_maybe?This works:
password_query =
SELECT NULL AS password, host, CONCAT(user,'@',domain) AS destuser
'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy
FROM accounts WHERE class='pop' AND domain='%d'
So all servers are using this authentication? It works because it lets
users log in using any password.
This doesn't work if proxied and CRAM-MD5 auth:
password_query =
SELECT
CONCAT(user,'@',domain) AS user, password,
host, 'Y' AS proxy_maybe,
target AS userdb_home, uid AS userdb_uid, gid AS userdb_gid
FROM accounts WHERE
class='pop' AND domain='%d' AND user='%n'
LIMIT 1
The problem is that Dovecot doesn't know the plaintext password for
logging into the remote server. It can't be extracted from CRAM-MD5
authentication. Are you storing plaintext passwords in the "password"
field? If so, you could return "password as pass" (as well as the
password field itself). If you're not using plaintext passwords,
you'll have to use a master password (see http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy)
.
(I suppose in theory Dovecot could also implement CRAM-MD5 client
functionality and use the stored CRAM-MD5 hash to log into the remote
server, but this wouldn't work with many other auth mechanisms, such
as DIGEST-MD5, so I don't want waste time on coding a CRAM-MD5-only
solution.)