Indirect or alternate criteria for list membership
As discussed in Defining membership of large lists, the MTA's normal interpretation of the
uniqueMember LDAP attribute (more precisely, the attribute named by the
ldap_group_dn MTA option) involves expanding the value of the
uniqueMember attribute via the URL template set by the
group_dn_template MTA option, which by default is
(meaning that the
$A substitution inserts the
uniqueMember value), so that by default,
uniqueMember values are interpreted as specifying a DN location in the DIT: all e-mail addresses under that location are considered to have been specified (be members).
This sort of indirect, additional-step, expansion of an LDAP attribute value turns out to be potentially useful for alternate approaches for membership definition. In order not to interfere with the "normal" handling of
uniqueMember DN values for list membership, in Messaging Server 7.0.5 the MTA option
ldap_group_dn2 and the mapping table
GROUP_TEMPLATES were introduced.
ldap_group_dn2 can be used to specify the name of an LDAP attribute which will then be processed similarly to the
uniqueMember) attribute---in particular, by default values of the LDAP attribute named by
ldap_group_dn2 are expanded via the
group_dn_template URL template just like
ldap_group_dn values. But the real usefulness of
ldap_group_dn2 tends to be when its use is combined with use of the
GROUP_TEMPLATES mapping table.
GROUP_TEMPLATES mapping table provides a way to specify different URL expansion templates for differently named LDAP attributes (such as different templates for the attribute named by
ldap_group_dn vs. the attributes named by
ldap_group_dn2), or even for different values of such LDAP attributes. When a
GROUP_TEMPLATES mapping table exists, it will be probed each time a group has an LDAP attribute named by either of the
ldap_group_dn2 MTA options. The probe form is:
object-classes is a plus-separated list of the object classes associated with the current LDAP entry, (see the
ldap_group_object_classes MTA option),
attribute-name is the name of the group "DN" attribute being expanded (i.e., the LDAP attribute name specified for either
attribute-value is that attribute's current value.
If the mapping sets the
$Y output flag, then the mapping output string will be used as the template for this attribute's expansion in place of using the value of
group_dn_template as the template. If the mapping sets the
$N output flag, then the attribute will be silently ignored.
So now that the facilities have been explained, how could they actually be used? Well, one sort of usage might be where groups/lists are defined not so much by the group/list entry pointing to (that is, listing) the members, but rather where each user entry specifies the groups/lists of which the user is a member, referring to some group/list ID. For instance, suppose group/list entries have an LDAP attribute
listID whose value is some string unique to that group/list. Then suppose further that user entries mark which groups/lists the user belongs to by having a
memberOf attribute that contains a valid
listID value. Defining group/list membership in this new way, while still allowing "traditional"
uniqueMember membership definitions, can be achieved by configuring the MTA with an option:
msconfig> set mta.ldap_groupdn listID
and mapping table:
GROUP_TEMPLATES ! Normal use of ldap_group_dn attribute uniqueMember *|uniqueMember|* $Yldap:///$$A?mail?sub?(mail=*) ! Find users who have a memberOf attribute set to the value of the group's ! listID attribute *|listID|* $Yldap:///$$B??sub?(memberOf=$$A)
where here note
$B is the substitution sequence meaning to substitute in the base of the user/group portion of the DIT (the
ldap_user_root MTA option's value), and where the
$A "Address" substitution means, in this context, the value of the currently used LDAP attribute (so the value of, respectively, the
listID attribute in the respective mapping table entries matching those attribute names). Then to make use of this type of group/list definition, provision groups and users in the directory along the lines of:
group1-entry listID: group123 ... group2-entry listID: groupXYZ ... user1-entry memberOf: group123 memberOf: groupXYZ ...