[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ldap
> Hi all,
>
> I'm having problems configuring sendmail with LDAP support, and
> therefore I'm considering switching to zmailer. I would like to know if
> it's possible to do the following with zmailer:
Propably you are doing the mapping at wrong place, but
sendmail's global "virtuser" mapping feature is somewhat
stupid, it isn't an alias mapping at all...
> One mailserver must service multiple domains, which should be lookuped
> using LDAP. It would be very nice if user names needn't be unique
> between the domains.
> Thus, j.doe@domain1.com and j.doe@domain2.com must be able to use the
> same server.
>
> Is this possible with zmailer? Does anyone have experience with this?
> The problems I have are:
> - ldap clients usually support one search base.
> - if I could configure sendmail to support the lookups in all domains, i
> get problems with the mailboxes because they would both be called
> /var/mail/j.doe ....
My intention is to do this very thing for inhouse uses.
( We have to kill several flat mapping files by pushing
the lookup into secondary/tertiary key of the database
to map j.doe@some.domain -> doejnn@mbox-123.domain )
ZMailer can have any number of ldap interfaced databases
you wish, and you can attach them to any subsystem you
wish -- e.g. to fqdnalias.cf, and to aliases.cf at the
same time -- with different search keys, possibly at
different databases..
> I tried to avoid the problem with having users login with their full
> adress (user@domain),
> but sendmail immediately strips this down to only the user name.
>
> Any suggestions are appreciated,
Look LDAP usage examples at:
doc/guides/ldap.doc
As I understand that example, the LDAP schema in
use has keyed field where incoming full-name is
translated into lookup of:
filter=
objectclass=person
mailAlternateAddress=Full.Name
with yielding attribute 'uid' (in string form, which
is impled by the system structure).
In one test a while back I did lookup of this kind
from LDAP directory:
filter=
objectclass=person
cn=Person.Name
yielding attribute 'rfc822Mailbox'...
Now to look info your (and my) case, your directory
will need some directory element a'la:
filter=
objectclass=person
rfc822Address=full.name@do.main
yielding attribute 'rfc822Mailbox' (or login-name, or ..)
In my case the result is 'loginname@backend-server', which
then becomes routed by the backend-server host, but the users
will never see which backend their email is stored at -- POP3,
and IMAP proxies handle that.
> Paul
/Matti Aarnio <mea@nic.funet.fi>
( <matti.aarnio@sonera.fi> -- when doing ISP business.. )