On Mon, 2002-02-25 at 20:50, Dan Melomedman wrote: > Thomas -Balu- Walter writes: > > > Hey guys, > > > > are there any know problems/issues for using email-addresses > > as "uid" so that a user has to login to pop/imap using his email? > > > > I wonder if there are clients or other things that might make problems > > when using this kind of setup. > Yes, many problems!
Agreed. > > The "uid" attribute is used by many other LDAP-aware applications and > services, which cause clashes. Furthermore, "uid" is a very common naming > attribute, which again causes a conflict when naming LDAP entries. A good > idea is to compile qmail-ldap to use a different attribute for POP3 > authentication. > Why not both? LDAP does take search-filters :-) > I don't like "uid" as the chosen attribute for POP3 authentication, I wish > the developers went with a different attribute from the start of the > project, but "Oh Well". qmail-ldap already has a number of proprietary > attributes in its schema, so why not have an alternative for "uid" in the > shipped schema? Furthermore, why not make that alternative attribute the > standard in the future versions. "uid" is almost guaranteeing a conflict > with some other software. Would anyone like to respond to this? No, not really. I use LDAP for a lot of services around here, and each user has a single profile. The only change I made to qmail-ldap's default attributes (at qmail-ldap.h) was setting LDAP_QMAILUID to uidNumber instead of qmailUID, precisely because I _do_ want to use the same attribute in all services, whenever possible. In this case, FTP and mail both use "uidNumber" to determine the UID of the user. FTP, pop3, imap4, HTTP, radius, and a few other apps all use "uid" as the login. Additionally, POP3 and IMAP also use the mail address "user@domain" _and_ the alias (localpart) whenever it is possible. It's all in the filters. For instance, qmail-ldap originally uses: * assume $user == <USER given at POP3> (uid=$user) and I hacked it so the searchfilter is (| (uid=$user) (mail=$user) (mail=$user+"@"+<content of control/me>) ) which in effect results in the user autenticating with: 1) His login, the same he uses for FTP or other stuff 2) _or_ his full e-mail address 3) _or_ his mail-alias (assuming that his mail is @ my default domain, the content of control/) The user may choose at his convenience what he wants to insert as the "Login" in his MUA. And all it took was a little coding in checkpassword.c. Most users don't even know they can use other auth-methods, but they're there.
