Nested groups and nested mailing lists

For many purposes, a useful thing to do is to "nest" group definitions: have groups defined that contain other subgroups as  members, or which are themselves contained in bigger groups.

When wishing to use such sets of users as mailing lists, however,  usually a separate list definition should be made for each  such desired list, defining each list&#x27;s membership to be an appropriate  group (or groups): for instance, using the     attribute. For instance, schematically: mail: list1@domain.com mgrpErrorsTo: list1-owner@domain.com memberURL: url-for-group2 memberURL: url-for-group3 where group2 and group3 are separately defined as groups with their own members, not as mailing lists (in particular, no    attribute). Indeed, it may be desirable to define group2 and group3 so that they do   not even have a     attribute of their own (are not    addressable as a pseudo-list). But if it is desired to also have the   sets of users in group2 and group3 be accessible for e-mail postings,    then use additional, separate list definitions, that in turn reference    the group2 and group3 definitions for their membership, along the lines    of: mail: list2@domain.com mgrpErrorsTo: list2-owner@domain.com memberURL: url-for-group2 mail: list3@domain.com mgrpErrorsTo: list3-owner@domain.com memberURL: url-for-group3 where note that these are indeed new list definitions, that make use of separate and distinct group definitions for the membership.

That is, when nesting of groups (or so-called nesting of mailing lists) is neither used nor desired, then converting existing group definitions  to true mailing lists definitions by simply adding an    attribute  (and any other desired mailing list  attributes) is perfectly fine. However, if nesting of groups (or mailing lists) is desired, then simply converting the group definitions  to list definitions is not optimal. Instead, this is the case where the more general approach of having group definitions (possibly not even  including a   attribute for the group) and then  separate list definitions that use the groups for membership, offers  significant advantages, including:



 By having the list membership defined as combining multiple groups,   or nesting groups, the LDAP search criteria on the membership uses a    search filter that includes all the appropriate groups, so that    duplicate elimination of members, from within all the groups and all    the nested levels of groups, will happen when the MTA is initially    expanding the membership of the list, rather than expanding to separate    sub-lists that then do their own membership expansion operation limited    to their own membership. That is, this approach allows better   elimination of duplicate addresses---a list member who is a member of    multiple subgroups defining the list will get one message    copy.1 

 By  not using nested lists, list-specific modifications to messages,    such as additions of List-⁠&#x2a;: header lines, setting of the    error return address    (the list "owner" address), etc., will be    performed once, consistently for the entire list membership, rather    than having nested levels of changes occurring at each stage of    nesting, causing changes to be cumulative or override each other. 



 1A separate issue is the so-called "duplicate" message copy -- which is not truly an exact duplicate -- that a recipient will receive if the original message was addressed directly to them, e.g., on the To: or Cc: header line, as well as being addressed to the list of which the recipient is also a member. A message copy resulting from a posting to a list is fundamentally different from the copy addressed directly to the recipient: even though the message content may be superficially "the same" (though even that is not necessarily the case, if list-specific text addition, or spam/virus cleaning, or document conversion, or character set translation, or other modifying operations have occurred), the notification address will be different for a true mailing list copy. Other differences, such as in NOTARY flags, or in Received: header lines, etc., also typically exist between mailing list copies and "direct" copies. Any difference that requires different handling by MTAs handling the message means that a different copy must be created at that point, and once a message has bifurcated in such a way, further divergence is possible and even likely: separate copies will be delivered and they are only superficially "duplicates". So keep in mind that even if the copies do not seem "significantly" different to the recipient, some difference existed at some point in time. Furthermore, sophisticated users may themselves wish to perform different handling of different types of incoming messages; for instance, some users will subscribe to mailing lists using subaddresses, thereby allowing for more  convenient Sieve filtering of their incoming list messages.

See also:
 * Mailing lists
 * ldap_group_url2 MTA Option
 * ldap_errors_to MTA Option
 * ldap_primary_address MTA Option
 * Subaddresses in aliases
 * Sieve subaddress extension
 * Proper use of lists rather than groups