[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: real life email with ldap.

On Fri, 19 Apr 2002, Adam Grochowski wrote:

> Hi,
> I'd be interested in hearing real world examples of how people are using
> ldap with their email systems (mail routing, imap auth, etc). It looks
> like we are going that way, and I'd like to explore different methods of
> doing so.

Here's our setup.

o openldap (2.0.21 currently) running on 4 machines (1 R/W, 3 RO),
  no anonymous bind allowed.
o pop/imap/pops/imaps via u/w imap-2000 with 2 deep hashed mail spool with
  pam auth
o mail routing via sendmail/laser-draft on main mail hub
o multiple linux hosts using ldap authentication and uid/gid mappings
o horde/imp for webmail interface
o auth various web application interfaces
o Internally built account management system (may turn GPL if I can some

It works very well.  Currently we have ~400 staff, ~100 system, and ~21000
students in the directory and there are no signs of slow down right now,
it's very important to index the h*** out of it and give openldap large
cache sizes.

Will also be authenticating a portal system, SunOS, and a courseware
system in the near future (~ 1yr out).  Student account numbers will
be increasing by approximately 17000 per year, and we are also in the
throws of creating the additional 2500 staff accounts which are needed.

Kerberos/sasl, OpenLDAP<->NDS, OpenLDAP<->Domino, and possibly Samba
auth via OpenLDAP will also be future things...  When/If these happen I
know I will be very happy!!

If you need more info, please feel free to contact me directly.

James Bourne

> Thanks!
> /a

James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA

This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.