[Kroupware] Web interface frontend
Tassilo Erlewein
kroupware@mail.kde.org
Tue, 1 Oct 2002 10:53:43 +0200
Hi Lutz,
sorry for my late answer. I find your ldap postfix findings quite useful.
We think heavily about getting the whole server config into a special=20
access-restricted LDAP object.
However I'm not so sure it's generally good to have the daemons
get their running config directly from LDAP (where possible)
So I would propose the following:
- have the web interface only interact with ldap
- provide a backend (perl) that reads stuff from ldap and
fills out config file templates=20
How do you think about that ?
Note that it's possible to arrange for special settings in the config fil=
e=20
templates that don't get overwritten by the backend. So it would be possi=
ble=20
for you to have postfix fetch whatever it supports directly from ldap.
My understanding is, that requires we stay postfix conformant with regard=
to=20
the ldap config object. So what you point out here could be very useful.=20
Please let me know further requirements like this, if you like.
Thanks
Tassilo
Am Montag, 30. September 2002 12:07 schrieb Lutz Badenheuer:
> Hi Tassilo,
>
> To have the postfix server properly lookup its virtual domains, you
> should possibly use
> 3. mailacceptinggeneralid (the email address) and
> 4. maildrop (where to put mail for this address to)
>
> The mailacceptinggeneralid attribute is used to lookup a mail user
> AND a virtual domain in Postfix: if you use
>
> mailacceptinggeneralid: example.org
> mailacceptinggeneralid: @example.org
> maildrop: harald@100jahralt.net
>
> in your "virtual_maps =3D ldap:ldaptag" you tell postfix to process
> mail for example.org; by adding a @example.org, you specify a
> catchall account that maildrops to harald@100jahralt.net.
>
> There is IIRC a limitation due to Postfix' security features, that
> you can't use [PC]RE or local usernames in the maildrop attribute.
> So, this has to be mapped to local mailboxes, but you can't specify
> local users in that maildrop attribute. To work around this, you may
> move transport_maps into LDAP, telling it to use cyrus deliver
> program as MDA. IIRC, the documentation told someting about cyrus: in
> this lookup's result. So,
>
> transport: cyrus:
>
> should be the LDAP result for the entire domain.
>
> With all this in mind, we need exactly two objectclasses: one that
> may be, possibly an extended version of inetOrgPerson, and one that
> is a special objectclass to represent a virtual mail domain. This
> entry provides virtual_maps and transport_maps to postfix.
>
> For the virtual domain, I propose
>
> --snip-----
> objectclass VirtualDomain
> requires
> objectclass
> mailacceptinggeneralid
> maildrop //is this really "required"?
> transport //always cyrus:
> --snap-----
>
> Ok, I hope I didn't forget something -- I started using Postfix only
> a week ago (before, I was addicted to qmail)... :-)