Defining membership of large lists

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   attribute or   attribute (more precisely, the  attributes named by the    and    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    URL;  e.g.: memberURL: file:///IMTA_TABLE:list-members.txt where the  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    attribute (more precisely, the attribute named by the    MTA  option). For each member defined via, the MTA  will use the value of that member&#x27;s   attribute (more  precisely, the value of the attribute named by the     MTA option) as the e-mail address for that member of the list. (The   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  might  have membership defined as: memberURL: ldap:///dc=domain,dc=com,o=internet??sub? (&(objectClass=inetMailUser)(objectClass=inetOrgPerson)) When defining list membership via a  or    attribute (or more precisely, whatever  attributes to which the MTA options    and    are set), unless use of some other attribute is explicitly selected,  the MTA assumes that the value of the   attribute  (   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    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&#x27;   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=&#x2a;@acquired-domain)) There is one additional factor to consider when defining list membership. Definitions that reference member e-mail addresses, e.g.,   (see the   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   or    attribute, will cause the list membership  expansion to abort at that point. So it is especially important to check list definition, e.g., via  ,  when defining lists that make use of LDAP DN  or LDAP URL criteria for membership.

See also:
 * Alias file
 * Aliases in Unified Configuration
 * ldap_group_url1 MTA Option
 * ldap_group_url2 MTA Option
 * MTA URL types
 * ldap_group_dn MTA Option
 * ldap_primary_address MTA Option
 * group_dn_template MTA Option
 * Indirect or alternate criteria for list membership
 * ldap_group_rfc822 MTA Option
 * test -rewrite utility
 * Mailing list addresses
 * Mass mailings