[Kroupware] Distribution lists

[Henning Holtschneider]

Hi everyone,

first of all, I'm not sure whether anyone has done any work on
distribution lists but as far as I see in the docs and the code, there
are currently no distribution lists planned for the Kolab server.

Am Mon, 2002-09-30 um 04.51 schrieb Andreas Jellinghaus:

> Everyone knows /etc/aliases:
> alias: dest1,dest2,dest3
> [...]
> So, i wonder how we should do this?
> 
> the straightforward alias replacement is a normal object with
> mailacceptinggeneralid: alias1
> maildrop: email1
> 
> both maildrop and mailacceptinggeneralid can have any number of
> entries. such one object can have several names, and can of course
> distribute mail to several people.
> 
> however since the email addresses are used in the maildrop: attribute,
> the whole thing gets quite dirty. well, those who actualy use
> firstname.lastname@company.de are fine, but those who started with
> short fn1@company.de and only added longer names as aliases will see
> a quite confusing schema.

I see you point and I think it should be as easy to understand for the
point-and-click administrator as possible. The administrator must not
worry about a user being on a distribution list if he wants to delete or
modify the user. To be able to see the distribution lists a specific
user is "subscribed" to is also a nice feature.

If I understand things correctly, the easiest way to achive consistency
would be to use either the uid or even better the entryUUID attributes.
Initially, a distribution list would look like this:

dn: cn=listname,dc=somewhere
cn: listname
structuralObjectClass: distributionList
entryUUID: 824ee95e-be57-1026-82dc-f642527c0ee4
creatorsName: cn=manager,dc=somewhere
createTimestamp: 20030117110644Z
objectClass: distributionList
mail=listname@somewhere.com

Then you add a user to the list through the web interface:

dn: cn=listname,dc=somewhere
cn: listname
structuralObjectClass: distributionList
entryUUID: 824ee95e-be57-1026-82dc-f642527c0ee4
creatorsName: cn=manager,dc=somewhere
createTimestamp: 20030117110644Z
objectClass: distributionList
mail=listname@somewhere.com
mailRoutingUUID=2f6b78e4-be87-1026-96d5-9fb427f3afb8

The kolab process monitoring the OpenLDAP log will now be able to look
up the mail address belonging to 2f6b78e4-be87-1026-96d5-9fb427f3afb8
and add the mailRoutingAddress to the LDAP object. The final result is:

dn: cn=listname,dc=somewhere
cn: listname
structuralObjectClass: distributionList
entryUUID: 824ee95e-be57-1026-82dc-f642527c0ee4
creatorsName: cn=manager,dc=somewhere
createTimestamp: 20030117110644Z
objectClass: distributionList
mail=listname@somewhere.com
mailRoutingUUID=2f6b78e4-be87-1026-96d5-9fb427f3afb8
mailRoutingAddress=joe@somewhere.com

If the email address of 2f6b78e4-be87-1026-96d5-9fb427f3afb8 changes,
the kolab process can also update every distribution list accordingly or
remove the member if the user account is being deleted.

I don't know how well this solution scales because it requires many
directory lookups but I don't see any other fool-proof solution at the
moment. Any suggestions?

I've got a couple of customers who are eager to try the Kolab server but
they need distribution lists. So, I'm going to implement whatever comes
out of this discussion based on the Kolab 1.0-beta1 server ;-)

Regards,
hh