[Kolab-devel] Request for email alias handling easy fix

Bernhard Reiter bernhard.reiter at intevation.de
Fri Dec 23 16:39:41 CET 2005


Am Freitag, 23. Dezember 2005 12:04 schrieb Fabio Pietrosanti:
> Bernhard Reiter ha scritto:
> >Am Freitag, 23. Dezember 2005 09:27 schrieb Fabio Pietrosanti:
> >>I crawled at the mailing list archives of kolab and i noticed that *a
> >>lot* of people when look at "Distribution List" think about email alias
> >>management.
> >
> >We face the difficulty of making creating a common understanding
> >about what "distribution lists" are within Kolab.
> >The problem is similiar with "groups", "shared folders", "groupware"
> >and other terms.
> >I fear that this can never be solved completely, it is just important
> >that we document even better what the different terms mean within Kolab.
> >
> >>Email alias management using distribution list information should
> >>could't be a "quick" solution?
> >
> >Probably not, I would need to think about it.
> >Also what you call "aliases" is called "mailinglists" by others.
> >In theory it is quite easy to take any ldap object that can hold several
> > email aliases and add an ldap lookup to postfix.
> >Then you would need to add the handling of those aliases to the
> > webinterface.
>
> In the day by day practice every email system, even the most simple,
> allow to setup an address "something at domain.com" that forward all the
> messages to several other email address.

Some call this "forwarding". :-)
Which you can do with sieve scripts currently.
There are plans to change this partly so that some setting are
in the openldap at least.

> Those feature is called email aliases and not mailing lists which,
> instead, use other message handling feature like subscription,
> authorization, moderation, archival, etc, etc
> Mailing lists are something really different and are needed only when
> some specific feature (subscription, archivial, moderation, etc) are
> required.
> I integrated sympa with kolab, but this was needed because of specific
> needs that would not be solved by simple email aliases.

I agree that there are differences in technology
and I agree that there should be a way to solve the need, 
however you call it. My point is that we cannot avoid a certain bit
of confusion on these terms.

> In any other email system usually small "group" of people share a common
> "email alias".
> This is needed to create in a easy, efficient and quick way
> coordination/discussion groups. (I'm personally in the "email aliases"
> of many small groups of many organizations and none of them use mailing
> lists softwares).

I am in a many small groups that use  mailing list software
with the huge advantage that responsible persons do not need
to be administrators, but just get the password for their "list".

> A name like "Distribution List" i think that will ever remind to every
> person "An object which contain a list of personal email addresses that
> allow the dstribution of messages".
> This really sound to me "an email alias/unstructured mailing lists"

Well and this is what does do for email addresses that are known
to the Kolab System. When you add an external address to the directory,
you can use it in distribution lists, too.

> If DL are only used to managed "groups" for handling ACL of cyrus shared
> folder why not simply call them "groups"?

Because they are actually distributing email to the members
and we do have group accounts and global folders, too,
which also have some "group" properties.

> Let's discuss about the object that would be used to handling email
> aliases.
>
> Does it require for the project a new object in the kolab schema to be
> defined to handle this feature?

The reason why you need to put an external email address into the system
before you can use them in distribution list is, that the groupOfNames LDAP 
Object is designed to only accept member DNs.

Best,
Bernhard




More information about the devel mailing list