It's a nice idea, and we did consider it, and play with it but it doesn't
work for a few reasons.
1. We use Eudora as a mail client, it's not my choice unfortunately, and
it thrashes Courier, whilst UW doesn't break a sweat, due to the odd
way Eudora implements mail filters (using UID's).
2. We have to have people having logons in the system, this isn't just
email we're talking about, hence why I said I want to use real users, and
not virtual users. Also we run a web based front end to procmail for mail
filtering that has to be 'grannied' in.
Anyone know how to get qmail-ldap compliant with RFC2307?
How does qmail look up local users anyway? Why won't it work with
nss_ldap?
herbie
______________________________________________________________________________
This is an email, an electronic Post-It note.
Keep your Inbox tidy and dispose of it in a timely fashion.
On Mon, 25 Jun 2001, Mike Jackson wrote:
> Andrew J Herbert wrote:
>
> > I've now played with qmail_ldap, but fail to see that I can implement it
> > in the same structure as everything else, as it seems primarily geared
> > toward 'virtual users'.
> >
>
> You want qmail-ldap. If these are mail servers, why do users need to
> have a system account? They aren't administrators. I run several
> qmail-ldap servers, with only system accounts for the IT staff. Even if
> they need a system account, you can store their mail in
> /var/qmail/maildirs owned and grouped to the qmail-ldap daemons, and
> make them use pine over IMAP or pop.
>
> UW-Imap is a resource HOG. You have to patch it twice to get it to work
> in your setup, and you have to recompile it when you make configuration
> changes. Low tech. Courier Imap has native support for ldap
> authentication and maildirs, has low memory requirements, and can be
> reconfigured without recompiling.
>
> Regards,
> Mike
>
