Hi,

We are trying to implement a highly secure mail server with user authentication restricted to SSL certificates only (not using passwords at all). Still, user information is stored in a LDAP directory. In this configuration LDAP is used to check whether the user is registered (and probably supply quota and other info), and actual authentication is done by SSL layer.

According to wiki, a "nopassword" extra field should be supplied, together with empty password. But there is no way to return an empty password from LDAP, as LDAP simply does not allow "empty attributes"; if an attribute is present, it is not empty. Supplying empty password as a static field (like this: pass_attrs = uid=user,=password=,nopassword) works an odd way, allowing empty password only, not "any password", and most MUAs (including our target Thunderbird) do not allow empty passwords.

Log excerpt follows ("1" was entered as a password during POP3 session; static empty password was configured as above):

Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): pass search: base=ou=People,dc=example,dc=com scope=subtree filter=(&(objectClass=inetOrgPerson)(uid=user1)) fields=uid,nopassword Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): result: uid(user)=user1 Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): Password mismatch Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): PLAIN(1) != '' Dec 9 02:11:17 localhost dovecot: auth(default): client out: FAIL 1 user=user1 Dec 9 02:11:19 localhost dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<user1>, method=PLAIN, rip=127 .0.0.1, lip=127.0.0.1, secured

That's why we now have to maintain a separate passwd-like file with the following contents:

user1:::::::nopassword user2:::::::nopassword ...

and so on (updating it each time manually as users are added/removed), and use it as passdb. Only this allows true "any password" policy.

In fact, the problem seems to be a little bit deeper. In our setup user/password challenge is not needed at all. This is exactly what RFC 4959, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", is about (http://tools.ietf.org/html/rfc4959 , see SASL EXTERNAL example). Are there any plans to implement SASL EXTERNAL mechanism in Dovecot?

Thank you! Zohan