Moderated mailing lists

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


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 mgrpErrorsTo setting that makes it a true list, rather than a group). These are, for a list defined in LDAP:

  1. The moderator(s) allowed to post directly must be among the mgrpAllowedBroadcaster values.
  2. The mgrpMsgRejectAction must be set to toModerator, 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.
  3. The address(es) to which to re-route not-yet-approved direct posting attempts must be specified, by setting mgrpModerator.

(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 ldap_errors_to, ldap_auth_url, ldap_reject_action, and ldap_moderator_url MTA options.)

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

  1. A moderator address, (which may be an alias/group/list address itself), must be set via the alias_moderator_address 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 mgrpModerator LDAP setting.
  2. 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_moderator_list alias option (where in this specific case the use is rather similar to that of the ldap_auth_url LDAP setting), or any of the alias_moderator_mapping, alias_username_moderator_list, alias_sasl_moderator_list, or alias_sasl_moderator_mapping alias options. But, unlike the LDAP case, in the absence of any settings specifying additional accepted moderator From: addresses, the basic alias_moderator_address 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 mgrpAllowedBroadcaster posters can be useful; or combining (ORing) various posting access conditions via mgrpBroadcasterPolicy 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 AFTER_AUTH value is used for mailDeferProcessing. In earlier versions, the less desirable no 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 mgrpAllowedBroadcaster to be the moderator, and setting mgrpBroadcasterPolicy to PASSWORD_REQUIRED,OR, 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 mgrpBroadcasterPolicy setting including OR, 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 mgrpAllowedBroadcaster to be the moderator, and setting mgrpBroadcasterPolicy to PASSWORD_REQUIRED,OR, 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: <hogwarts-moderator-user>@domain.com 
mgrpModerator: mailto:%3Chogwarts-moderator-user%3E+hogwarts@domain.com 
mailDeferProcessing: AFTER_AUTH 

Then for the <hogwarts-moderator-user>@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 'reject' or a 'redirect :resetmailfrom "hogwarts@domain.com";', as appropriate. E.g.:


require ["reject","envelope","subaddress"]; 
if  envelope :detail "to" "hogwarts" { 
  if allof ( header :contains ["To","Cc","Bcc"] "hogwarts@domain.com", 
             header :matches "Subject" ["Re*:*", "RE*:*"]) { 
    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 ["mime","reject","subaddress","envelope"]; 
if envelope :detail "to" "listname" { 
  if header :mime :anychild :type "Content-type" 
      ["application","audio", "image","video"] 
     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 ["fileinto","reject","subaddress","spamtest","relational"]; 
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 mgrpMsgMaxSize 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 mgrpMsgMaxSize can not be simply ORed with access checks such as mgrpAllowedBroadcaster, 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 ["reject","subaddress","fileinto","notify"]; 
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 listname-large 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 "vacation" 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 ["subaddress","vacation"]; 
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: