Title: representations of directory-based groups
version: 0.1
date: 23-Oct-1998
author: Jeff Hodges

1. Organizational groups

The "conventional X.500 wisdom" is that these groups ("country", 
"organization", "organizationalUnit") are formed by their being used as 
container objects directly in the DIT (i.e. directory namespace) hierarchy. 
They directly contain the objects within them, in this model.

There's several other ways we might represent such groups, some of which may 
be leveraged off of the approaches below. That's as far as I'm going to 
discuss these sorts of groups for this version of this doc.


2. Arbitrary, non-DIT mapped Groups

These are groups that are not represented directly in the DIT hierarchy. 
Typically, they are represented by some object class that has a multi-valued 
attribute, each of whose values represents a member. This attribute is 
typically named "member", not surprisingly. Typically, values of the member 
attribute are DNs. These serve as pointers to the member objects. Another 
attibute is sometimes used for members who do not have directory entries 
representing them. An example of this is the mgrpRFC822MailMember defined in 
[Steinback97] and [Steinback98].

An interesting wrinkle is a group having members by virtue of entities 
asserting that by setting an attribute in their ~own~ entries. An example is 
the memberOfGroup attribute from the umichPerson objectclass (below). In this 
case, the client, [mail500] has to know to go search the directory for any 
entries having a value of memberOfGroup equal to the group address being 
processed (see do_group_members() in main.c of [mail500]).

[Steinback97] also defines an interesting approach to denoting group 
membership -- the 'mgrpDeliverTo' attribute (aka "Dynamic Group"). The value 
of this attribute is an LDAP URL which defines a search on the directory which 
will yield members of the group. See section 3.3.3 of [Steinback97]. 
[Steinback98] also mentions this attribute, and also notes that they've filed 
for a patent on it (!). I have my doubts whether they will get it, tho, 
because it isn't necessarily all that "non-obvious". It is simply a more 
general approach to the "memberOfGroup" technique.


3. Summary

So, there's essentially three approaches to groups in present practice...

3.1. Representation directly in the hierarchical DIT via container objects. 

3.2. Representation of group as an object which has one or more multi-valued 
attributes whose values comprise group membership.

3.3. Representation of group indirectly by the member objects themselves 
having an attribute denoting group membership. Group membership is assesed 
dynamically by searching for all the members.

3.4. A combination of 2 & 3 ([UMichLDAPRel3.3] and [Steinback97&98] do this). 



4. Example Object Class and Attribute definitions from some of the References.


From [rfc1274]...

     groupOfNames OBJECT-CLASS
         SUBCLASS OF top
         MUST CONTAIN {
             commonName,
             member}
         MAY CONTAIN {
             description,
             organizationName,
             organizationalUnitName,
             owner,
             seeAlso,
             businessCategory}
     ::= {objectClass 9}


     member ATTRIBUTE
         WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
         ::= {attributeType 31}



From [rfc2256]...

			.
			.
5. Attribute Types
			.
			.
			.
5.32. member

    ( 2.5.4.31 NAME 'member' SUP distinguishedName )
			.
			.
5.51. uniqueMember

    ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
			.
			.
7. Object Classes
			.
			.
7.10. groupOfNames

   ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
     MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
			.
			.
7.18. groupOfUniqueNames

   ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
     MUST ( uniqueMember $ cn )
     MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
			.
			.



From [UMichLDAPRel3.3]...


objectclass groupOfNames
	requires
		objectClass,
		member,
		cn
	allows
		businessCategory,
		description,
		o,
		ou,
		owner,
		seeAlso

objectclass umichPerson
	requires
		objectClass,
		sn,
		cn,
		universityID
	allows
		affiliationCode,
		audio,
		businessCategory,
		classStanding,
		description,
		destinationIndicator,
		doNotDelete,
		doNotMove,
		drink,
		expire,
		facsimileTelephoneNumber,
		homePhone,
		homePostalAddress,
		internationaliSDNNumber,
		janetMailbox,
		jpegPhoto,
		keepNames,
		krbName,
		l,
		labeledURL,
		mail,
		mailPreferenceOption,
		memberOfGroup,
		mobile,
		multiLineDescription,
		noBatchUpdates,
		notRegistered,
		notice,
		onVacation,
		organizationalStatus,
		otherMailbox,
		ou,
		pager,
		personalSignature,
		personalTitle,
		photo,
		physicalDeliveryOfficeName,
		postOfficeBox,
		postalAddress,
		postalCode,
		preferredDeliveryMethod,
		proxy,
		registeredAddress,
		registrationStatus,
		roomNumber,
		secretary,
		seeAlso,
		st,
		streetAddress,
		telephoneNumber,
		teletexTerminalIdentifier,
		telexNumber,
		textEncodedORaddress,
		title,
		uid,
		updateSource,
		userCertificate,
		userClass,
		userPassword,
		vacationMessage,
		x121Address,
		xacl

objectclass rfc822MailGroup
	requires
		objectClass,
		owner,
		cn
	allows
		associatedDomain,
		autoMgt,
		description,
		destinationIndicator,
		errorsTo,
		facsimileTelephoneNumber,
		internationaliSDNNumber,
		joinable,
		krbName,
		labeledURL,
		mail,
		member,
		memberOfGroup,
		moderator,
		multiLineDescription,
		notice,
		physicalDeliveryOfficeName,
		postOfficeBox,
		postalAddress,
		postalCode,
		preferredDeliveryMethod,
		registeredAddress,
		requestsTo,
		rfc822ErrorsTo,
		rfc822RequestsTo,
		seeAlso,
		streetAddress,
		suppressNoEmailError,
		telephoneNumber,
		teletexTerminalIdentifier,
		telexNumber,
		userPassword,
		x121Address,
		xacl







References....

[mail500] UMich LDAP-enabled sendmail "mailer" plug-in. UMich LDAP client and 
server package, Release 3.3.
file:///$INSTALL_DIR/ldap-3.3/clients/mail500/

[rfc1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", 
11/27/1991. ftp://ds.internic.net/rfc/rfc1274.txt

[rfc2256]  M. Wahl.  "A Summary of the X.500(96) User Schema for use with 
LDAPv3".  December 1997. http://info.internet.isi.edu:80/in-notes/rfc/files/rfc
2256.txt

[Steinback97]  Bruce Steinback, "Using LDAP for SMTP Mailing Lists & Aliases". 
Internet Draft (expired). Sept 1997.
http://www.normos.org/ietf/draft/draft-steinback-ldap-mailgroups-00.txt

[Steinback98]  Bruce Steinback, "Netscape mailGroup definition". See below. 

[UMichLDAPRel3.3] UMich LDAP client and server package, Release 3.3 -- 
ObjectClass definitions.
file:///$INSTALL_DIR/ldap-3.3/servers/slapd/slapd.oc.conf



----------------------------------------------------------------------------
Date: Thu, 22 Oct 1998 17:48:13 -0700
From: bruces@netscape.com (Bruce Steinback)
To: ilm@carumba.com
Subject: Netscape mailGroup definition

Greetings,

I'm a developer in the Netscape Messaging Server group.  We've
thoroughly tied our Mail Server to LDAP, and one of the thigs we came up
with was an LDAP objectClass for mailing lists.  I had put an RFC draft
up about it a while back, but it didn't get much attention and died.
Jauder noticed when I had put this spec up on another mailing list and
told me about this one [Jauder: sorry to take so long to send this
here].  He mentioned that you all might be interested, so here goes.

Attached below is a brief description of the mailGroup objectclass we
have defined here at Netscape.  It's meant to usually mix-in with a
groupOfUniqueNames (Netscape 'version' of the groupOfNames class), and
would normally get it's members (in part - see below) from there, but is
capable of standing on it's own.  As you can see, I've included a great
deal more attributes, but ones that are commonly useful in mailing
lists.  Let me know what you think, or if you're interested in more
information...

NOTE: One large legal caveat.  Netscape is in the process of attempting
to patent the 'Dynamic Group'
concept embodied by the mgrpDeliverTo attribute (a patent application
has already been filed).


                            Mailing Lists & mailGroup LDAP Class

This document describes our proposed schema for handling Mailing Lists
(Groups). We started with the
UMich rfc822MailGroup as a basis, but decided to split it up into two
classes. The main one I will discuss in this proposal is the mailGroup
class. (see below for a note on mailGroupManagement)

The mailGroup is meant to either stand alone or be mixed into another
objectClass. Mixing it in would enable the object as a mailing group.
The only objects that we would expect to mix into would be a
groupOfUniqueNames (or some similar LDAP group class).

The following is the schema entry for the LDAP mailGroup:

objectClass  mailGroup
      requires
              objectClass,
              mail
      allows
              mailAlternateAddress,
              mailHost,
              mailRoutingAddress,
              mgrpErrorsTo,
              mgrpNoDuplicateChecks,
              owner,
              cn,

              mgrpRFC822MailMember,
              mgrpDeliverTo,
              mgrpDeliverException,

              mgrpMsgMaxSize,
              mgrpAllowedDomain,
              mgrpAllowedBroadcaster,
              mgrpBrodcasterPolicy,
              mgrpApprovePassword,
              mgrpMsgRejectAction,
              mgrpMsgRejectText,
              mgrpModerator,

              mgrpAddHeader,
              mgrpRemoveHeader

Definition of mailGroup Attributes

--mail (cis, 1)

This is the name of the group for incoming email, i.e. mail to 'mail'
will be handled by this group. It's required as the Mail Server needs an
rfc822 address for this group in order to find it.  This is considered
the 'canonical' address of the group (see mailAlternateAddress below).

--mailAlternateAddress (cis, 0-many)

Alternates to the address above in the 'mail' attribute - e.g. if
mail=jblow@this.com, then
mailAlternateAddress might contain such as Joe_Blow@this.com and/or
jblow@server.this.com.  This can be used for things like handling common
misspellings of an address, or host hiding (allowing mail to an address
at a particular host, but not commonly exposing the host name).

--mailHost (cis, 0-1)

If this is present then this list is required to be exploded by the
particular Mail Server given - e.g. to 'shunt' processing of mailGroups
to a particular Server to allow the others to (more quickly) just
process 'regular' recipients. If empty, then any MTA having access to
the LDAP server containing the Group entry can handle this Group.

--mailRoutingAddress (cis, 0-1)

This is used if it is wished to re-route mail to this address.  It would
go instead to the address provided in this attribute.  Note: this
attribute is 'historical' in that it has now moved to the mailRecipient
class, but is left here to avoid messing up old versions of mailGroup.

--mgrpErrorsTo (cis, 0-1)

Address to send error messages to (i.e. for mail to a member bouncing).
The format of this is either
mailto:(rfc822 mail address) or ldap://(dn entry - which must be a
mailable entity). Only one entry allowed, but it can refer to a
mailGroup rather than a person.

--mgrpNoDuplicateChecks (cis, 0-1)

Normally, the Mail Server will check all recipients of a message for
duplication (including all members of a group).  This keeps multiple
copies of the same message from being delivered to a person.  However,
this takes up system resources, so if an admin is more concerned with
quick processing of a group, they may set this to "true", and duplicate
checking will not be performed for members of
the group.

--owner (cis, 0-many)

A DN that specifies the owner(s) of this group. Used for Access Control,
to determine who has write access to this class. 'owner' isn't really
used in the base mailGroup implementation, but is used for ACL in
mailGroupManagement (see note at end).  NOTE: this attrib also exists in
groupOfUniqueNames and is 'shared' if mixed-in with that class.

--cn

Just the CN reference for this group. Not used by mail server.


Membership Attributes
-----------------------

--(uniqueMember)

This contains the DN specified members of this group. It is not included
in the schema above, and is only mentioned parenthetically here to
remind people that this attribute would come from a mixed-in
groupOfUniqueNames.

--mgrpRFC822MailMember (cis, 0-many)

This contains the members of this group that cannot be expressed as dn's
(usually people not in the
directory). They are expressed as rfc822 mail addresses (e.g.
joe@blow.com). This might also be used to specify people who are to
receive mail to this group but not have the group priviliges of unique
members - from a mixed-in groupOfUniqueNames). The Mail Server would use
this attribute as addresses to send to when 'exploding' a message to the
list.

It is expected that members of the group internal to the company would
usually be expressed as DN's in a groupOfUniqueNames mixed in with this
object class (as mentioned above).

This attribute would optionally include other parameters as:

rfc822MailAddress [ % 'full' name] [ %1 (group parameter #1)] [ %2
(group parameter #2)]...

where the 'full' name is the name the user would be listed by in group
listings, and the other parameters are per-user groups settings.
Note: these are left intentionally undefined to allow expansion as
desired.

--mgrpDeliverTo (ces, 0-many)

This attribute provides an alternate method of membership in a
mailGroup. It contains data of the form of an LDAP search criteria URL -
e.g.:

ldap:///ou=Accounting,o=Netscape,c=US??sub?(&(objectClass=mailRecipient)(object
Class=inetOrgPerson))

The entries found by the search are members of the group. This is a very
useful attribute for example, to mail to an entire company or division.
Note that this does not use the attribs-to-get field of the LDAP URL as
the Mail Server will get the necessary attributes for it's operation.

--mgrpDeliverException (DN, 0-many)

This attribute provides a mechanism for handling exceptions to
mgrpDeliverTo (above).  i.e. Say you have a group "marketing" with
membership defined by an mgrpDeliverTo attribute.  One person who falls
under the search criteria in mgrpDeliverTo should not (or doesn't wish
to) receive mail to that group.  Instead of having to modify the
mgrpDeliverTo for every exception, this provides a means
to except people that would otherwise be delivered to.


Msg Restriction Attributes
--------------------------

--mgrpMsgMaxSize (cis, 1; ascii integer)

This defines the maximum message size (in bytes) that is allowed to be
sent to this group.

--mgrpAllowedDomain (cis, 0-many)

Domains allowed in mailing to this group - that is, accepted domains of
the 'sender' of msgs to this group.  If empty then there are no domain
restrictions.  If an authenticated sender address is available then it
is used as the sender, else a combination of the From: and Reply-To:
fields is used. This field is by default 'wild-carded' - e.g. an entry
of "netscape.com" will match a Sender domain of *.netscape.com

--mgrpAllowedBroadcaster (cis, 0-many)

This defines user(s) that are allowed to send messages to the group.
Each entry can either be a DN or
rfc822address. The format allowing this is either mailto:(rfc822 mail
address) or ldap://(dn entry - which must be a mailable entity or a
groupOfUniqueNames).  Groups (mailGroup or groupOfUniqueNames) are
allowed in this field.  The sender address to be matched against is
gotten from the message as in mgrpAllowedDomain above.

--mgrpBroadcasterPolicy (cis, 0-1)

This attribute provides more rigid controls on who is allowed is an
allowed broadcaster.  The options are:
SMTP_AUTH_REQUIRED - Requires msgs to the Group to be from an SMTP
Authenticated sender
(using whichever AUTH type(s) are allowed by the server).
PASSWD_REQUIRED - Requires msgs to the Group to have a "Approved:
(password)" line, where the password is a password assigned to the group
(see mgrpApprovePassword below).  The "Approved:" line can either be a
header or the first (non-blank) line of the message (of the first MIME
part for MIME msgs).
The Approved line is (of course!) stripped out before forwarding the
message to the group.
CERT_REQUIRED - Requires msgs to the Group to be signed, with the Cert
matching that of an
allowedBroadcaster.
NO_REQUIREMENTS - this is equivalent to no setting - that is - none of
the above special requirements are made of broadcasters, and is the
default.

--mgrpApprovePassword (ces, 0-1)

This would be used in conjunction with the PASSWD_REQUIRED selection of
mgrpBroadcasterPolicy.

--mgrpMsgRejectAction (cis, 0-many)

This specifies the action to be taken when a message to the group is
rejected (see allowedBroadcaster and allowedDomain above).
Actions currently available are: "toModerator" (send msg to moderator(s)
- see below), "reply" (send a
failure notice to sender), and "bounce" (return msg to sender with
reply). This is left open for more options to be added later.

Actions can be specified for particular rejection types.  Just add the
rejection type in front of the reject action you wish associated, e.g.
SIZE: toModerator.
Rejection types are: SIZE: DOMAIN: SENDER: and PASSWD:
Note: If no mgrpMsgRejectAction's are specified then the default is
"reply".

--mgrpMsgRejectText (ces, 0-1; may contain multiple lines of text with
$-encoding)

This contains the text of the reply that is sent if msgRejectAction
includes "reply" or "bounce"(see above).
Also similar to the above, different text can be specified for different
rejection types.

--mgrpModerator (cis, 0-many)

DN or rfc822address (handled as in mgrpAllowedBroadcaster above). If
this a msg is forced "toModerator" by mgrpMsgRejectAction (see above)
then this contains the people (or mailGroups) that the message is to be
sent to.


Message 'Munging' Attributes
------------------------------
--mgrpAddHeader (ces, 0-many)

This defines headers to be added to all msgs sent to the group, e.g.
"Reply-To: (group-address)" if you wish all replies to be sent to the
group.

--mgrpRemoveHeader (cis, 0-many)

This defines headers you wish to delete from all msgs sent to the group,
e.g. "Reply-To:" if you don't want replies to group msgs to go back to
the sender.

		----------------------------------
Note that I don't have 'management' attributes here (e.g. things handled
by such as Majordomo or Listserv having to do with subscribing to a
mailing list).  We have them packaged into another class,
mailGroupManagement, that's separately documented.  Jauder has mentioned
interest, so I'll try to post that to this group 'rsn' (real soon now
:-).

    Cheers,

    Bruce


--------------------------------------------------------------------------