[Kolab-devel] DL of DL: would it be possible?

[Bernhard Reiter]

Hi Fabio,

Am Montag, 2. Januar 2006 00:22 schrieb Fabio Pietrosanti:
> DL could be (ab)used for basic mailing lists/aliases other than for
> managing ACL of Cyrus Shared folders.

that is on purpose and no abuse...

> Using it for mailing lists/aliases i got the need to creare DL of DL
> (like saing an alias of another alias that need to be resolved by
> postfix recursivelly) for situation like that:
>
> I have two domain:
> example.com
> example.it
> example.net
> example.de
>
> I have two user account named user1 at example.com and user2 at example.com
> that receive email directed to the DL info at example.com .
>
> Now i would like to create info at example.it, info at example.net and
> info at example.de that go directly to the same users of info at example.com .
>
> I don't want to specify the list of every users in all DL because this
> list could grow and keeping it syncronized between various
> .com/.it/.net/.de DL would be time expensive.
>
> Right now it's not possible to creare DL of DL, like info at example.it
> that contains as member info at example.com that recursivelly contains the
> users behind such DL.

Yes it (should) not be possible.

> What would be the implication in the kolab design to support as member
> of DL other DL to get recursive mailing lists/aliases resolving?

Currently we cannot do it, because of the ACL funcationality.
It would require recursive LDAP lookups in postfix and imapd (and possibly
other places), which is hard to change.
It probably has security implications at it is easier to confuse people
with recursive lookups.

To me it seems that you only want one level on indirection, is this right?
Somebody could provide this with an entry in postfix virtual.
Maybe we should think about an alias ldap object which 
a) cannot be used for ACLs
b) will not depend on a member attribute, but on a mail attribute which would
make it easier to make aliases for external users.
c) probably is not based on groupOfNames because of a) and b)

Bernhard