First, I don't see why you would want to let your users logon with any password. A user with a valid certificate could logon as any user, as long as you don't actually somehow check who is the certificates' owner.
And i don't think there's a big chance that EXTERNAL will be implemented in the next time (though this post is a bit outdated): http://archives.neohapsis.com/archives/postfix/2005-12/1323.html Also, there's no further information at Roadmap: http://wiki.dovecot.org/Roadmap Maybe you could use "auth external" with couriers authlib, as it recently started to support AUTH EXTERNAL: http://sourceforge.net/project/shownotes.php?group_id=5404&release_id=296342 The problem is that I don't see how authlib would be able to access the the certificate. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Zohan > Sent: Tuesday, December 09, 2008 12:45 AM > To: dovecot@dovecot.org > Subject: [Dovecot] "nopassword" extra field useless with LDAP passdb > > 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
