Moderated mailing lists

A moderated mailing list---a list where certain moderators are allowed to post messages, but attempted postings by others are routed  to a moderator or moderators instead of being posted  directly---requires three basic settings for moderation (in addition to  the    setting that makes it a true list, rather  than a group). These are, for a list defined in LDAP:



 The moderator(s) allowed to post directly must be among the     values. 

 The     must be set to    , to cause messages that initially fail an    access check to get routed to the moderator(s) (who may or may not    resend the message to the list, at their pleasure) rather than being    outright rejected. 

 The address(es) to which to re-route not-yet-approved direct   posting attempts must be specified, by setting. 



(For concreteness, the above description refers to the LDAP attribute names that the MTA consults by default; but more precisely, the LDAP attributes that must be used are whatever attributes are named by the,  ,  , and   MTA options.)

For a list defined via alias options instead of in LDAP, the required  basic moderation settings, beyond the basic list setting of , are:



 A moderator address, (which may be an alias/group/list address  itself), must be set via the       alias option; this is the address to which will be sent all    attempted postings not   coming from a moderator address. This is analogous to the    LDAP setting. 

 Optionally, additional addresses may be established as allowed   direct posters (additional originator addresses to be handled as if they     were moderators, for purposes of allowing postings) using the         alias option (where in this specific case the use is rather similar to     that of     the   LDAP setting),  or any of the    ,     ,  , or    alias options. But, unlike the LDAP case, in the absence of any settings specifying   additional accepted moderator From: addresses, the basic       address will be used not only as    the moderator address to which to send unmoderated postings,    but also be recognized as a valid moderator From: address from which to   accept direct postings. 



Once these settings are made, a list can be considered moderated. Note that while a common case is that there is only one moderator  and only that one moderator can post, other cases may be just  as useful. In particular, allowing specially known and privileged classes of non-moderators as additional    posters can be useful; or combining  (ORing) various posting access conditions via     so that moderation applies only to  attempted postings that fail other conditions (such as use of SMTP AUTH  to authenticate, inclusion of a list password, etc.) can allow  for moderation of messages meriting higher scrutiny, while permitting  more trusted senders to post directly.

For instance, it can be useful to set up a mailing list where postings from members of the list are not moderated, but attempted postings by  non-members of the list go to the moderator for human review. To set up a mailing list where members are allowed to post directly, but where  attempted postings by non-members must be approved by the list  moderator, include in the list entry attributes such as: mgrpErrorsTo: moderator-user@domain.com mgrpAllowedBroadcaster: mailto:list-members@domain.com mgrpAllowedBroadcaster: mailto:moderator-user@domain.com mgrpMsgRejectAction: TOMODERATOR mgrpModerator: mailto:moderator-user+listname@domain.com mailDeferProcessing: AFTER_AUTH Note that in the above example, the new in MS 6.3p1   value is used for. In earlier versions, the less desirable   value would need to be used instead.

A similar example would be a mailing list where messages containing the list password are posted directly, while message lacking that password  are directed to the moderator for inspection. By setting the   to be the moderator, and setting    to  , the effect is that postings from the  moderator will be allowed even without the normal password, while  attempted postings from any other senders will only be directly posted  if they contain the password. mgrpErrorsTo: moderator-user@domain.com mgrpBroadcasterPolicy: PASSWORD_REQUIRED,OR mgrpAllowedBroadcaster: mailto:moderator-user@domain.com mgrpAuthPassword: secret-password mgrpModerator: mailto:moderator-user+listname@domain.com mgrpMsgRejectAction: toModerator When the moderator receives a message addressed to moderator-user+listname@domain.com, the moderator  would either reject messages he/she does not approve, or resend the  message to the list. In this example, due to the   setting including ,  the moderator is not required to add the header line that other senders  would need to include: Approved: secret-password That is, by setting the  to be the  moderator, and setting   to  , the effect is that postings from the  moderator will be allowed even without the normal password, while  attempted postings from any other senders will only be directly posted  if they contain the password.

Many additional mailing list behaviors are best achieved by setting up one form or another of moderated list. This is true even for certain behaviors that may not immediately seem like cases of a moderated  mailing list. An example: setting up a mailing list where postings directly to the list are permitted without moderation, but where  replies to prior list postings -- attempts to continue a posting  thread -- are disallowed can be achieved via a moderated list setup. Indeed in general, cases where it is desired to perform more elaborate checks or processing on messages before they are allowed to be posted  to the list are often cases where appropriate moderation of the list  may be helpful.

For instance, consider the case of a mailing list that disallows replies to prior list postings. Replies to prior list postings will be detected via a Sieve filter that looks for common "reply"  prefix strings on the Subject: header line. The mailing list can be set up to include attributes: mgrpErrorsTo: &#x3c;hogwarts-moderator-user&#x3e;@domain.com mgrpModerator: mailto:&#x3c;hogwarts-moderator-user&#x3e;+hogwarts@domain.com mailDeferProcessing: AFTER_AUTH Then for the &#x3c;hogwarts-moderator-user&#x3e;@domain.com user, set up a Sieve filter that looks for messages addressed to the user with the  subaddress hogwarts (use the  Sieve subaddress extension) and then  either does a &#x27; &#x27; or a &#x27; &#x27;, as appropriate. E.g.: require &#x5b;"reject","envelope","subaddress"&#x5d;; if envelope :detail "to" "hogwarts" { if allof ( header :contains &#x5b;"To","Cc","Bcc"&#x5d; "hogwarts@domain.com",              header :matches "Subject" &#x5b;"Re&#x2a;:&#x2a;", "RE&#x2a;:&#x2a;"&#x5d;) { reject "Replies not allowed!"; } else { redirect :resetmailfrom "hogwarts@domain.com"; } } ...whatever other filter stuff this user wants... Another example where a technically moderated list, without involving actual human moderation, may be of interest would be the case of  rejected attempted postings that include non-text parts. With a mailing list definition that includes: mail: listname@domain.com mgrpErrorsTo: listname-owner@domain.com mgrpModerator: mailto:list-moderator+listname@domain.com mailDeferProcessing: AFTER_AUTH then the moderator user or pseudo-user (since possibly no human being corresponds to this entry, which might exist for the sole purpose of  having this Sieve script), list-moderator@domain.com, might  use a Sieve filter along the lines of: require &#x5b;"mime","reject","subaddress","envelope"&#x5d;; if envelope :detail "to" "listname" { if header :mime :anychild :type "Content-type" &#x5b;"application","audio", "image","video"&#x5d; reject "Non-text may not be posted to this list"; else { redirect :resetmailfrom "listname@domain.com"; } } ...whatever other filtering this user wants... An example that does involve an actual human moderator would be for a  list that does not impose controls on the identity of posters, but  where the attempted posts are scanned for suspicion of spam content,  and then are potentially either rejected or human moderated at  different levels of spam suspicion, while scanned non-spam messages get  automatically posted. mail: listname@domain.com mgrpErrorsTo: listname-owner@domain.com mgrpModerator: mailto:listname-owner+listname@domain.com mgrpAllowedBroadcaster: mailto:listname-owner@domain.com mgrpMsgRejectAction: toModerator Then the listname-owner@domain.com "user": mail: username@domain.com mailEquivalentAddress: listname-owner@domain.com should have a Sieve filter including: require &#x5b;"fileinto","reject","subaddress","spamtest","relational"&#x5d;; if envelope :detail "to" "listname" { if spamtest :value "ge" :comparator "i;ascii-numeric" "10" { if spamtest :value "ge" :comparator "i;ascii-numeric" "20" { reject "Content appears to be spam"; } else { fileinto "listname-spam"; } } else { redirect "listname@domain.com"; } } Or another example of a list involving human moderator of some attempted postings would be where it is desired that rather than a list  having an absolute limit on the size of postings (where note an  absolute limit could be achieved simply by setting the desired    on the  list), that a moderator be able to  selectively approve the posting of messages that would otherwise be  considered "too large". Note that a size limit such as   can not be simply ORed with access checks  such as , so this goal will require  a special moderation setup. mail: listname@domain.com mgrpErrorsTo: listname-owner@domain.com mgrpModerator: mailto:listname-owner+listname@domain.com mgrpAllowedBroadcaster: mailto:listname-owner@domain.com mgrpMsgRejectAction: toModerator Then the listname-owner@domain.com "user": mail: username@domain.com mailEquivalentAddress: listname-owner@domain.com could have a Sieve filter including: require &#x5b;"reject","subaddress","fileinto","notify"&#x5d;; if envelope :detail "to" "listname" { if size :under 10K { redirect :resetmailfrom "listname@domain.com"; } elsif size :under 50K { fileinto "listname-large"; notify :method "email" :options "listname-owner@domain.com" "Message filed to listname-large needs to be checked" "";      }    else { reject "Message too large to post"; } } which would automatically post to the list any small messages, automatically reject any extremely large messages, but notify the  moderator of any new medium size message posting attempt and file that  message into a   folder for the  moderator to inspect and approve or bounce, at their leisure.

Returning to yet another case of "automated moderator" processing, consider an example where it is desired to respond with an  automatic message to list postings, using the Sieve  " " action. With a list entry along the lines of: mail: listname@domain.com mgrpErrorsTo: listname-owner@domain.com mgrpModerator: mailto:moderator-pseudo-user+listname@domain.com mgrpAllowedBroadcaster: mailto:moderator-pseudo-user@domain.com mgrpMsgRejectAction: toModerator mailDeferProcessing: AFTER_AUTH Then the LDAP entry for moderator-pseudo-user@domain.com: mail: moderator-pseudo-user@domain.com can have a Sieve script attached along the lines of: require &#x5b;"subaddress","vacation"&#x5d;; if envelope :detail "to" "listname" { vacation :addresses "listname@domain.com" :from "listname@domain.com" :subject "Welcome to listname!" "Thank you for your interest in listname. You will receive a personal response soon."; redirect :resetmailfrom "listname@domain.com"; }

See also:
 * Mailing lists
 * Mailing list addresses
 * Sieve filters
 * Sieve subaddress extension
 * Sieve mime extension
 * Sieve supported extensions
 * ldap_errors_to MTA Option
 * ldap_auth_url MTA Option
 * ldap_reject_action MTA Option
 * ldap_moderator_url MTA Option
 * ldap_auth_policy MTA Option
 * alias_envelope_from Option
 * alias_moderator_address Option
 * alias_moderator_list Option
 * alias_moderator_mapping Option
 * alias_username_moderator_list Option
 * alias_sasl_moderator_list Option
 * alias_sasl_moderator_mapping Option
 * ldap_reprocess MTA Option