Proper use of lists rather than groups

The fundamental difference between an e-mail group vs. a true mailing list is in  how notification messages  are defined to be handled:  in particular, whether the original envelope From address (the error  report address) is retained (a group) or overridden with a list owner  address (a true mailing list). In the case of groups and mailing lists defined in LDAP, the distinction is whether an    attribute has been set;  in the case of groups and mailing lists defined via alias options in Unified Configuration, the distinction is whether the   alias option has been set; in the case of groups and mailing lists defined via the  alias file,  the distinction is  whether the  &#x5b;ENVELOPE_FROM&#x5d; named parameter  or alternatively the    positional parameter has  been set.

For almost all cases, true mailing lists should be used. Groups, on the other hand, should be reserved for those rare cases where:



 The group membership is (very!) small: on the order of a handful of   members. 

 The group membership is quite cohesive in terms of roles and   relationships: examples would be multiple mailboxes for the same actual    person, members of a (small!) family, emergency sysadmin contacts,    etc. 

 The group membership is quite static (unchanging). 



Regrettably, (mis)use of simple groups when mailing lists would be more appropriate is wide spread---and survives simply because sending  messages to a group is so easy and until something goes wrong  the difference is not apparent. Of course, once something does go wrong, it&#x27;s precisely the suboptimal handling of the notifications that  becomes a problem for the (misused) groups.

Many (probably most) sites do not have this distinction clear at all; they think of a group (abstractly a set of users) as essentially  synonymous with the use of that group as (the membership of) a mailing  list. And it&#x27;s routine to plaster a   attribute onto  every "group", at which point one can send messages  to the group, making it a pseudo-mailing list. But just plastering a   attribute onto a group does not make a group  a mailing list, and in fact it is perhaps unfortunate that this is so  "easy" as it lets sites make these sorts of conceptual and  operational mistakes so easily. (There are two possible mistakes: the more common is to use a  -attribute-decorated group  sans  as an autoforwarder in cases  where it is not appropriate; but simple addition of    to a  -attribute-decorated  group thereby turning it into a true list may be another, though  lesser, sort of mistake, especially when  groups are nested, if one  would prefer to still have the group available as a pure set of users,  suitable as membership for some superset groups or lists). Except for certain special cases where it really does make sense to have a mail  address for the group function as an autoforwarder, groups should not  be used directly as a pseudo-list. When no nesting is needed, a group can be turned into a list definition by adding. Or most generally, for best overall practice, the definitions should be separate to correspond to the  conceptual distinction: there is a group defining a related set of  users, and then there is a separate list entry in LDAP that has that  group as its membership.

So, for almost every case of an LDAP group entry to which messages will be addressed, correct definition should use an entry that includes an    attribute (more precisely, whatever attribute  is pointed to by the    MTA option), pointing to some  "responsible" or "list owner" address, so that the  group is also in e-mail terms, a true mailing list.

To expand upon the differences and options in notification handling:





With a plain group definition, as of MS 6.1 syntax errors or other   "immediately apparent" errors (such as over quota status for    local users) in the member address definitions will be reported to    the entire rest of the group membership, whereas with a mailing    list definition such syntax errors/immediately apparent errors are    reported only to the "responsible list owner" address: the      address.

Note that in neither case is   informing the original sender typically appropriate: the maintenance of    the correctness/usability of the addresses in a group or list    definition is not the business of the original message sender, but    rather best handled by either the (close and cohesive) "fellow    members" of the group in the case of a (properly used) group, or    by the "responsible list owner" in the case of a true mailing    list. The original message sender, in contrast, could well be some   remote correspondent with no ability to "fix" the    "bad" address definition, and in the case of (properly used)    groups, where the membership of the group is quite cohesive and    overlapping in intended roles so that as long as someone in the group    got the message it can be considered successfully received, a bounce    message back that an address was "bad" may be misleading and    unnecessarily worrisome to the original sender. Note that such cases of   immediately apparent as invalid addresses (but where at least one    address in the group appears initially valid) would not get reported to    the original message sender even prior to MS 6.1; instead such cases    were silently ignored prior to MS 6.1. Note also that a case where all   address definitions in a group are bad does, of course, get reported    back to the original sender: in that case the sender&#x27;s message was not    received at all, and the entire group address was bad. The case   discussed above is where at least some of the group addresses    appeared initially valid.



 In the case of initially apparently valid addresses that suffer   delivery problems, for a plain group such delivery problems are    reported back to the original sender, whereas for a true mailing list    the delivery problems are reported back to the "responsible list    owner" address. With only a little thought, it should become clear   why with any sort of large list, or any list where membership is at all    subject to change (membership "turn over"), informing merely    the list owner (who may want to consider removing chronically    "bad" addresses from the list membership) is desirable, and    why "informing" the original sender is likely to be perceived    as "pestering" the original sender with irritating, useless,    and irrelevant (to them) bounce messages. Furthermore, exposing who is   on the list, but suffering delivery problems, to arbitrary original    senders may be considered an undesirable exposure of information in    some cases. (Keep in mind that some mailing lists and groups are   configured so that being allowed to post to the list or group does not    imply ability to see the list membership.) So notifying only the    "responsible list owner" about delivery problems to list    members is a true advantage that mailing lists have over groups. Now   due to the widespread (mis)use of groups for mailing list purposes,    users may have gotten accustomed, when posting to what is actually a    group (but being misused as a mailing list), to receiving notifications    of delivery problems to the individual group members. In such cases,   the proper course is, almost always, to switch to a mailing list and    educate the users on what to expect with a true mailing list, rather    than continue to (mis)use a group. 

 For the rare cases where mailing list semantics are appropriate in   general, but where it truly makes sense to notify the original message    sender of delivery problems to mailing list members, new in MS 6.3 (but    not working until the fix for CR # 6530591), setting    , that is, setting to the forward slash    character, has a special meaning. It tells the MTA to revert to using   the original envelope From address that had been present on the    incoming message, yet in all other respects use mailing list semantics. This can be useful for setting up mailing lists that report all forms   of list errors to the original sender. Note that this feature should   not be used merely to avoid having to educate users about a    change from group to mailing list semantics, as this is more than a    "cosmetic" feature but rather has significant semantic    impliciations; use of this feature should be reserved for cases where    its semantic implications are truly understood and desired. 



See the discussion of the  attribute (or more  precisely, the attribute named by the    MTA option)  for some additional discussion and special syntaces for  this attribute&#x27;s value.

Another difference between groups vs. true mailing lists is in the area of passing through of NOTARY flags on the message  "copies" to the various recipients; here too mailing list  behavior tends to be distinctly more desirable, as the group behavior  (as required by Internet standards!) is optimized for the case of  multiple mailboxes (aliases) for a single person.

See also:
 * Notification messages
 * Notification message generation timing
 * ldap_errors_to MTA Option
 * Alias options
 * alias_envelope_from Option
 * Alias file
 * Alias file named parameters
 * ldap_primary_address MTA Option
 * Nested groups and nested mailing lists
 * Mass mailings
 * Mailing lists