Just a note on this--
I've been using qmail-ldap since october '99. I immediatly modified the code
to lookup "mail" instead of "uid" on my system before I put it into
production.
It's the way it makes sense to me. However, I had to do two source level
modifications to support my customer base:
1. Default realm for the user base that existed before I switched
to qmail-ldap... Simply, if (!strstr(username, "@")) {
strcat("@mydomain.com") };
2. Next, as Henning mentioned, take care of stupid clients who
don't allow "@" in a domain name. I got around this by using the ':'
character. We made it company policy that usernames would take the format of
"username:domain" or username@domain for all authentication requests. (This
includes FTP Servers, etc... ) So we have code that replaced all '@''s with
a ':'.... This also included making it company policy that a username never
have a : in it. Which is okay because it is against all modern UNIX
convention (think /etc/passwd) and qmail policy....
Of course, in qmail, I always used the stralloc library, not the libC
functions i used in my examples...
So it would make sense why there is a seperate uid= attribute: to support as
many configurations as possible. I choose to enforce these restrictions on
my customer base, however, and made my administration much easier by going
simply with the "mail" attribute.
Thanks,
James
---------------------------------------------------------
James Tavares <[EMAIL PROTECTED]>
Sr. Data Network Engineer
Log On America, Inc.
Ph: 1-401-459-6294
Fax: 1-401-459-6580
Web: http://www.loa.com/
----- Original Message -----
From: "Dan Melomedman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 01, 2001 3:15 PM
Subject: Feature proposal for pop3d
> I've been thinking about the uid attribute a little bit, and it seems
> completely redundant. If pop3d was modified to lookup mail=uid@domain,
> we wouldn't have the uniqueness problem, and wouldn't have to invent
> stupid uid value schemes like user-domain for the uid attribute value.
>
> The @domain part could be determined by the IP range that the client
> is in, or by simply running a different pop3d server per every virtual
> domain. Just like Apache does it for virtual domains.
>
> So the pop3 client submits uid to the pop3 server, pop3 server looks at
> the ip address of the client. If an address matches a range of particular
> virtual server in pop3d's configuration file (this could be a cdb
database),
> then an ldap search is done with uid@domain that's read from the config
> file. The configuration file is simply bunch of range=domain keys and
> values.
>
