Defining membership of large lists

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


Note:This discussion will focus on lists primarily defined in LDAP, as that is the typical mode of defining lists nowadays. However, the MTA does also support lists defined instead in an aliases file entry, or in Unified Configuration via alias options, rather than in an LDAP entry; see those topics for details.

The membership of a list may be defined by simply listing the e-mail addresses of the members, or (for lists defined in LDAP) by listing the DNs (location in the LDAP directory tree) of the members.

For instance, for a list defined in LDAP, the memberURL attribute or mgrpDeliverTo attribute (more precisely, the attributes named by the ldap_group_url2 and ldap_group_url1 MTA options, respectively) are available, e.g.:


memberURL: ldap:///o=usergroup??sub?(uid=abc123) 
memberURL: ldap:///o=usergroup??sub?(cn=Adam Brown) 
memberURL: mailto:Betty.Charles@domain.com 
memberURL: mailto:John.Doe@external-domain.com 

Note that an LDAP based list definition can obtain a list of actual addresses from a separate, on-disk file (accessible from the MTA performing the list expansion) by using a file: URL; e.g.:


memberURL: file:///IMTA_TABLE:list-members.txt 

where the IMTA_TABLE:list-members.txt file itself consists of a list of e-mail addresses, one address per line, e.g.,


Betty.Charles@domain.com 
John.Doe@external-domain.com 

Or, when it is more convenient to describe a list in LDAP via the locations of the member entries rather than via their e-mail addresses, the members may be described via the uniqueMember attribute (more precisely, the attribute named by the ldap_group_dn MTA option). For each member defined via uniqueMember, the MTA will use the value of that member's mail attribute (more precisely, the value of the attribute named by the ldap_primary_address MTA option) as the e-mail address for that member of the list. (The group_dn_template MTA option controls which attributes for the user the MTA fetches, and hence which/whether additional addresses for the user can match for purposes such as comparisons with posting restrictions. See Indirect or alternate criteria for list membership for a discussion of more complex membership definitions using variants of DN semantics.)

But for "large" lists especially, it is often more convenient to instead define the list membership in terms of some criteria by which to locate the relevant users in LDAP; for instance, a list of all users in LDAP might have membership defined as:


memberURL: ldap:///o=usergroup??sub?(&(objectClass=inetMailUser) 
                                      (objectClass=inetOrgPerson)) 

Or a list of all the users in the domain domain.com might have membership defined as:


memberURL: ldap:///dc=domain,dc=com,o=internet??sub? 
            (&(objectClass=inetMailUser)(objectClass=inetOrgPerson)) 

When defining list membership via a memberURL or mgrpDeliverTo attribute (or more precisely, whatever attributes to which the MTA options ldap_group_url1 and ldap_group_url2 are set), unless use of some other attribute is explicitly selected, the MTA assumes that the value of the mail attribute (ldap_primary_address MTA option) should be used as the e-mail address for the list member; note how in the above example no attribute is explicitly requested (and therefore the default use of the mail value is assumed). If it is desired to use some other attribute that does itself contain an e-mail address, that may be selected by explicitly selecting that attribute. For instance, suppose that a no longer canonical, acquired domain name is still in use in certain users' mailEquivalentAddress values; a list intended for sending to those users, at their "old" addresses, could have membership defined as:


memberURL: ldap:///o=usergroup?mailEquivalentAddress?sub? 
   (&(objectClass=inetMailUser) 
     (objectClass=inetOrgPerson) 
     (mailEquivalentAddress=*@acquired-domain)) 

There is one additional factor to consider when defining list membership. Definitions that reference member e-mail addresses, e.g., mgrpRFC822MailMember (see the ldap_group_rfc822 MTA option), allow better error reporting in cases of definition errors (such as syntax errors), than definitions that reference LDAP DNs or LDAP URLs. Syntax errors in e-mail address members will be reported to the list owner. However, syntax errors in an LDAP DN or LDAP URL used to define members, e.g., syntax errors in a uniqueMembers or memberURL attribute, will cause the list membership expansion to abort at that point. So it is especially important to check list definition, e.g., via imsimta test -rewrite -check_expansions, when defining lists that make use of LDAP DN or LDAP URL criteria for membership.


See also: