So, it's all very well adding gsasl support but if real world admins
can't use it to migrate from Cyrus SASL, then it's not providing a
viable alternative. I have nothing in particular against Cyrus, I just
want to make sure that we offer real options, with real competition.
sasldb2 stores passwords under a key composed of:
$usercode \x00 $realm \x00 "userPassword"
I've added a new lookup type "dbmjz" to exim, on the "dbmjz" branch. It
interprets the key as an Exim list and joins the list items together
with ASCII NUL characters to form the lookup key. This key, with
embedded NULs, is then safely passed to the DBM routines and the result
retrieved. Embedded NULs in the result will still cause problems
elsewhere, as may leading and trailing whitespace.
So I've tested this with both of:
auth_cram:
driver = gsasl
public_name = CRAM-MD5
server_realm = imap.spodhuis.org
server_password = ${lookup{$auth1:$auth3:userPassword}dbmjz{/usr/local/etc/sasldb2}{$value}fail}
server_set_id = ${quote:$auth1}
server_condition = yes
auth_cram_own:
driver = cram_md5
public_name = CRAM-MD5
server_secret = ${lookup{$auth1:imap.spodhuis.org:userPassword}dbmjz{/usr/local/etc/sasldb2}{$value}fail}
server_set_id = $auth1
It all works fine for me. I use extended ACLs to grant user:exim:r--
access to the sasldb2 file.
Documented, but no test suite additions yet.
Feedback welcome,
-Phil
