Re: [ldap] Mail groups

[Terry Lambert <terry@whistle.com>]

Note: In the future, please do not crosspost between lists
	which do not permit open postings, since some people
	may not be subscribed to both lists, and will get
	anal bounce messages when trying to respond to you
	and the forums in which you posted your questions.

--- Begin previous response -------------------------------------
Mike Douglass wrote:
> 
> I guess some people must be maintaining mail groups with
> ldap. How are you doing this?

I intend to do this; I have not enabled it yet, in my
local installation, where I intend to use this.

Sendmail 8.10.0 (and 8.10.1, just released) have support
for using LDAP to obtain maps.  These are just like any
standard sendmail map (mailertable, accessdb, virtusertable,
userdb, aliases, etc.), except they come from LDAP.  The
exact filters used for each map are dependant on both the
map and the schema used (in general, the right hand side of
a mailertable entry will not be the same thing as the right
hand side of an alias database, for example).

There are also objects defined in an IETF draft schema,
which the sendmail documentation references:

        draft-lachman-laser-ldap-mail-routing-01

This draft is out of date, but the pieces that sendmail
uses have not changed sufficiently that it does not
apply.

It is rumored that "postfix" (also variously known as
"vmailer" and "IBM Secure Mailer" [alphaworks.ibm.com])
can also support this type of functionality, but I have
yet to see it actually work, even in vitro.


> The netscape documentation shows how to create a group
> and then give people access to that group. On the other
> hand, the openldap mail500 example describes a method
> whereby individuals become members of a group by adding
> the dn for that group as an attribute to their own record.
> This second approach avoids having to give access to a
>  group record to users.

There are two different approaches embodied here.

If we think of these groups as sendmail aliases, and we
are content to permit any user to add themselves to any
alias, then the second approach you describe might be
adequate for some small set of mail installations.

I, for one, am not content to permit users to add
themselves to the aliases "hostmaster", "postmaster",
"spam", "sales", "abuse", and so on -- you will perhaps
not be content to allow users to add themselves to the
alias "Mike.Douglass", preferring to limit that aliases
membership to "douglm" -- or "deans", "deptartment_heads",
"alumni", etc..

The first approach permits administrative controls over
access to the ability to edit mailing lists.

In my opinion, neither of these are sufficient for the
general mailing list problem.  Really, you need to have
group element granularity, and LDAP ACLs do not provide
this capability.

Consider the case of an open subscription mailing list;
this is actually the simplest controlled access mailing
list you can have.

You wish to permit people to add themselves, and you wish
to permit people to remove themselves (basic "subscribe"
and "unsubscribe" semantics).  The access being controlled
is access to the records of other users, and to "special"
aliases.

Your second approach is not adequate, since it does not
permit limiting the lists to which a user may subscribe;
some lists _must_, by definition, be closed.  You can't
reject the addition of a DN, into a list of DNs associated
with the user, based on the contents of the DN the user is
adding.  The user either has permission to create _any_
DN which passes subschema enforcement (e.g. "it's a valid
case insensitive string"), or they have _no_ permission.

Your first approach is similarly inadequate, in that it
it does not permit limiting users to their own DN entries
in (presumably -- or something similar to) the object
"groupOfUniqueNames".  Either a user has the ability to
"subscribe" or "unsubscribe" _any_ DN in this list, or
they have _no_ permission.  Such permission implies the
ability to change other attributes of this object, as well,
some of which might be significantly more sensitive than
the list of subscribers, such as the list address ("alias")
itself.


What you appear to need is a third option, which enforces
a relation based on an attribute of the mailing list object
itself.

For this to work, you actually need to have a policy agent
draw this relation, and enforce polciy, on behalf of a
"subscription" or "unsubscription" request.  This agent is
called a "mailing list manager".

Currently, I am aware of no generally available products
which can do this; I am aware of a couple such products
currently in alpha test, which may never become real
products (one of them is located three feet to the right
of the keyboard on which I am typing this).


So on the deeper questions:

o       No, there's no way to map the problem space you
        are contemplating, without an intelligent agent
        to do the mapping.

o       Yes, you could embed such an agent in the schema
        enforcement mechanism of an LDAP server, if it
        was able to accept such plugins (e.g. a plugin
        to define a new attribute type and type content
        enforcement mechanism).  You didn't specifically
        ask this, but it's a second order derivative of
        the problem you appear to be trying to solve.

o       No, there is no generally available mailing list
        management software which you could use to do
        the work external to your LDAP server, at this
        time.

Hope this answers your questions.


-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- terry@whistle.com
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.