Sign In Sign Out Mailing Lists Unsubscribe or Change Settings Help

OpenBSD Mailing List Server

                     Introduction to List Moderation

When people say "a mailing list is moderated," they usually mean that 
every message that someone posts to the list is examined by someone else 
before it is allowed to be delivered.  In Majordomo, moderation can also 
apply to subscription or unsubscription, access to the list archives, 
and many of Majordomo's other features.  The word "request" is used 
to refer to anything that requires approval, including posted messages.

When a request is moderated, Majordomo mails a message to the moderators
with the word "CONSULT" in the subject line.  Basically, to approve or 
discard a request, you only need to reply to that message and type 
one of these two commands into the body of the reply:

  accept
  reject

The rest of this document focuses on the details of moderation:
  * Who are the moderators?
  * How does Majordomo keep track of the moderated requests?
  * Why does a request become moderated?
  * Is the person who made the request notified of what happens?
  * How can you decide what requests are and are not moderated?
  * How can messages be discarded automatically instead of moderated?

The last section of this document presents solutions for common
moderation problems.

The examples in this document assume that you know how to use your 
list's administrative password.  Please review "help admin_passwords",
if you have not already done so.  In each example, replace LISTNAME
with the name of your mailing list.  Replace ADDRESS with a valid e-mail
address.


What's the difference between an owner and a moderator?
-------------------------------------------------------

The short answer is that the owner has all of the authority, and the 
moderator has all of the responsibility.  Only kidding.

When a request is moderated, a message with CONSULT in the Subject
header will be sent to the moderators.  Basically, all the moderators
have to do is reply with the accept command to approve a request, or the
reject command to disallow it.  Neither of these commands requires a
password, so in principle the moderators might not have permission to
perform other administrative tasks, such as unsubscribing people from
the mailing list.

The list owners are the people whose e-mail addresses appear in the
"owners" configuration setting.  The list owners usually know the list's
master password, and can issue any administrative command.

Majordomo uses the following steps to determine who the moderators are,
stopping when it finds a valid address:

  1. It looks in the LISTNAME:moderators auxiliary list, for addresses
     that do not have the "nomail" flag set (see "help auxiliary_list"
     for more details).

  2. It looks in the "moderators" configuration setting for the list.

  3. It looks in the "owners" configuration setting.

  4. It looks in the "whoami_owner" configuration setting.

If the moderators and the owners are different people, and the owners
want the moderators to be able to perform other duties, such as
subscribing and unsubscribing people, passwords with restricted
privileges can be defined for the moderators using the "passwords"
configuration setting (See "help configset_passwords" for more details).


Token identifiers
-----------------

When a request requires someone's approval, Majordomo creates a random
number, called a "token identifier" or "token," to keep track of the
request.  Every token looks something like this:
 
  98FE-03BB-A743

To approve or disallow a token, the accept or reject command is used,
for example:

  accept B139-DE29-A649
  reject 98FE-03BB-A743

If a request is not accepted or rejected, after a few days the moderators
will receive a reminder that the request has not been completed.  A few
days later, the token will expire, and the request will never be completed.

The reminder notice gives a brief summary of the request.  If a moderator
has forgotten the details of the request, the tokeninfo command can be
used to obtain more information, for example:

  tokeninfo 9F34-77DA-B021

The accept, reject, and tokeninfo commands never require a password.

Administrators who do know a list's administrative password can see
a summary of outstanding tokens for a mailing list with the showtokens
command:

  showtokens LISTNAME

See "help accept", "help reject", "help showtokens", and "help tokeninfo"
for more details.


Notifications
-------------

When a moderator accepts or rejects a request, Majordomo may or may not 
send a notice to the person affected by the request (the "victim").  The 
decision to send a notice is based upon the victim's personal settings.

  * For accepted requests other than posted messages, a notice is always sent.

  * When posted messages are accepted, a notice is sent if the "ackpost"
    setting is turned on.

  * When any request is rejected, a notice is sent if the "ackreject" setting
    is turned on.

If the victim is a subscriber to the mailing list, the settings are
determined by the victim's settings.  Otherwise, the settings are
determined by the list's nonmember_flags configuration setting.  See
"help set" and "help configset_nonmember_flags" for details on changing
those settings.


Causes of moderation
--------------------

There are many ways in which the rules in the access_rules configuration
setting can cause moderation.  These causes will usually be clear to
the person writing the rules.  However, there are some less-than-obvious
ways in which the default access settings can cause a request to be moderated.

For requests other than posted messages, the default settings are usually
determined by a "policy" or "access" configuration setting.  For example,
access to the subscribe command is controlled by the subscribe_policy
configuration setting, and access to the who command is controlled by
the who_access configuration setting.  All of the policy and access settings 
are part of the ACCESS category.  To see their values, use this command:

  configshow LISTNAME ACCESS

(Substitute the name of your mailing list for LISTNAME, but type
the word ACCESS as shown, in capital letters.) 

If a policy setting is "open" or "open+confirm," the moderators' approval
will be needed if there is an address mismatch or posing.  A mismatch occurs 
when someone issues a command for another address.  For example, if 
jane@example.com uses this command:

  subscribe LISTNAME ruth@example.net

the two addresses, jane@example.com and ruth@example.net, do not match.
Posing occurs when someone uses the "default user" command.  For example, 
if jane@example.com uses these commands:

  default user ruth@example.net
  subscribe LISTNAME

jane@example.com is posing as ruth@example.net.  Mismatch and posing also 
will cause messages posted with the post command (see "help post" for more 
details) to be moderated.

Aside from mismatch and posing, there are many reasons a posted message
might be moderated:

  * The moderate configuration setting is turned on.

  * The author of the message is not a member of the groups in the 
    restrict_post configuration setting.

  * The administrivia configuration setting is turned on, and the
    message matches one or more of the patterns in the admin_body
    and admin_headers configuration settings.

  * The message contains an Approved: header with an invalid password.

  * The message exceeds one of the size limits in the max_total_header_length,
    maxlength, max_header_line_length, and max_mime_header_length 
    configuration settings.

  * The message has a body part whose type is marked for moderation
    by the attachment_rules setting.

  * The message has a duplicate Message-ID header, or duplicate body,
    of another message that has been posted to the same mailing list.

  * The message matches one or more of the patterns in the taboo_body
    and taboo_headers configuration settings.

  * The author exceeded the "soft limit" quota in the post_limits
    configuration setting.

  * The "postblock" personal setting for the author is turned on.
    (See "help set" for details on personal settings.)

  * The e-mail address in the "From" header of the message is invalid.

The rest of this document discusses how these settings can be tuned for
effective moderation of posted messages.  Using the access_rules
setting, any or all of the moderation checks can be turned off.
Likewise, any of the moderation checks can cause a message to be
discarded instead of moderated.  See "help configset_access_rules" for
more details.


Full moderation
---------------

The simplest way to moderate every message posted to a mailing list is 
to turn on the moderate configuration setting:

  configset LISTNAME moderate = 1

See "help configset_moderate" for more details.

The simplest way to moderate every message posted by one subscriber is
to turn on the "postblock" setting for that subscriber:

  set LISTNAME postblock someone@example.com

See "help set" for more details about personal settings.


Content filtering
-----------------

There are six configurations settings that support moderation based upon
the contents of the message.  For more information, see the following 
documents:

   help configset_admin_body
   help configset_admin_headers
   help configset_administrivia
   help configset_attachment_rules
   help configset_taboo_body
   help configset_taboo_headers


Size limits
-----------

There are four configuration settings that support moderation based upon
the size of the message body or the message headers.  For more information,
see the following documents:

   help configset_max_header_line_length
   help configset_max_mime_header_length
   help configset_max_total_header_length
   help configset_maxlength


Personal limits
---------------

There are two moderation checks that depend upon the address of the
author of a posted message.  A message will be moderated if the author's
"postblock" personal setting is turned on.  Only subscribers have
personal settings, so if a non-subscriber posts a message, it will be
moderated if the "postblock" flag is included in the nonmember_flags
configuration setting.

Unless the postblock setting is listed in the default_flags
configuration setting, a subscriber can unsubscribe, then subscribe
again to turn the setting off.  For more information on the postblock
setting, see "help set".

The post_limits configuration setting is used to moderate or deny
messages from people who post too often.  The limits can vary from
person to person or domain to domain.  For example, consider the
following command:

configset LISTNAME post_limits <<BLD
/example.edu/  |  10/100  |  4/d
/./            |  15/100  |  7/d
BLD

These settings establish the following limits:

  * For addresses in the example.edu domain, any person who has posted
    more than 10 messages out of the last 100 will exceed the "soft
    limit."  Any person who has posted more than 4 messages in the last
    day will exceed the "hard limit."

  * For all other addresses, the soft limit is 15 messages out of the 
    last 100, and the hard limit is 7 messages in the last day.

Exceeding a soft limit will cause a message to be moderated.  Exceeding
a hard limit will cause a message to be denied and discarded.  For more
information, see "help configset_post_limits".


Duplicates
----------

Two posted messages are considered duplicates if at least one of the following
three criteria is true:

  * The messages have duplicate Message-ID headers.
  * The first body parts of the messages are identical.
  * The first 10 lines of each message's body are identical.

By default, any message that duplicates a previously posted message will
be moderated.  Although these checks are useful for preventing mail
loops, they can also unnecessarily moderate messages that have a first
body part that is empty.  To turn off the body checks, use the following
rule in the access_rules setting:

post
unset=dup_checksum, unset=dup_partial_checksum
ALL


"Approved" messages
-------------------

Anyone who knows a list's master password can use the password to skip
all of the access checks.  To do this, it is necessary to add an
"Approved" line in the headers or body of the message.  For example, if
the list's master password is 4a5p6h7o, the line would look like this:

Approved: 4a5p6h7o

This line can appear in the message headers, or as the first non-blank
line in the body of the message.  Majordomo will automatically remove
the Approved line when the message is delivered.

For compatibility with Majordomo version 1, if an "Approved" line in the
body is followed by a non-blank line, it and all succeeding non-blank
lines, up to the first blank line, will become the headers of the
message when it is posted.

Sometimes, a moderator may want to make corrections to a moderated
message before it is delivered to the subscribers.   It is possible to
do this using an extended form of the Approved line, using the following
steps:  

  * Obtain the original posted message, either from the CONSULT message 
    that was sent to the moderator, or using the tokeninfo or
    tokeninfo-remind command:

      tokeninfo TOKEN
      tokeninfo-remind TOKEN

  * Edit the message and make the desired corrections.

  * Add an Approved line to the headers or the start of the body, with
    the following difference:  after the password, put a comma and
    the token identifier:

      Approved: PASSWORD , TOKEN

  * Send the edited message to the address of the mailing list.

When these steps are taken, two things will happen.  First, the password
will cause the moderation checks to be skipped.  Second, when Majordomo
sees the token identifier on the Approved line, it will reject the
token.  This will help to prevent another moderator from approving the
delivery of the original posted message.

The tokeninfo command displays information about a posted message, and
the contents of the message, in the same block of text.  The
tokeninfo-remind command, in contrast, includes the posted message as an
attachment.  In some cases, the latter format may make editing and
reposting a message easier; it depends upon the software that you use to
read e-mail.


Denying access
--------------

In some cases, it may be necessary to discard posted messages from
certain people automatically.  There are several ways to accomplish
this.

The "postblock" flag, which normally causes messages to be moderated,
can be used to discard messages.  To enable this feature, add the
following rule to the access_rules setting:

post
deny, reason="The postblock flag causes messages to be denied."
$post_block

Then, if you wish to deny all messages from non-subscribers, add
"postblock" to the nonmember_flags configuration setting.  To deny
messages from a particular subscriber, use the set command to turn on
the postblock flag for that subscriber:

  set LISTNAME postblock ADDRESS


Another way to deny messages from a select group of people is to use an
auxiliary list.  In the access_rules setting, use the following rule:

post
deny, reason="Posted messages from this address have been banned."
@banned

Then, to deny posted messages from a particular address, use the
following command:

  subscribe LISTNAME:banned ADDRESS


If the "ackdeny" flag is set, the person whose message is denied will be
sent a notice.  If the "ack_attach_original" configuration setting
includes the word "fail," the message that was denied will be attached
to the reply.  See "help set" and "help configset_ack_attach_original"
for more details.


Moderator groups (advanced topic)
---------------------------------

Different groups of moderators can be assigned different moderation
tasks.  A moderator group is created by adding addresses to an auxiliary 
list with the subscribe command.  The access_rules setting can then
be adjusted to assign responsibilities to the new moderator group.

For example, consider a list where one group of moderators is 
assigned to approve subscriptions and another is assigned to approve
posted messages.  All subscriptions and all posted messages are moderated.
The addresses of the subscription moderators have been added to the
"smods" auxiliary list, and the post moderators are in the "pmods"
auxiliary list.  The access_rules setting is changed:

configset LISTNAME access_rules <<LPP
post
consult=(consult,1,pmods,), reason="All moderated messages require approval."
ALL

subscribe
consult=(consult,1,smods,), reason="All subscriptions required approval."
ALL
LPP

See "help configset_access_rules" for more information.


                  Cookbook for common moderation problems
                  ---------------------------------------


Problem  How do I allow only subscribers, and a select group of 
-------  non-subscribers, to post messages to the list?


                                First approach:

  Subscribe all of the non-subscribers, but change their delivery class
  to "nomail" so they do not receive messages.

subscribe-set LISTNAME nomail nonsubscriber@example.com

  Then, set the restrict_post configuration setting to allow only list
  members to post:

configset LISTNAME restrict_post <<END
LISTNAME
END


                    Second approach (most like Majordomo 1):

  Sign up the recipient users as usual, and put everyone else in
  a "posters" auxiliary list:

subscribe LISTNAME:posters nonsubscriber@example.com

  then restrict posting to the main list and that sublist:
  Then, set the restrict_post configuration setting to allow only list
  members and members of the "posters" sublist to post:

configset LISTNAME restrict_post <<END
LISTNAME
LISTNAME:posters
END


Problem  How do I allow everyone in a certain domain to post, but
-------  require approval for all other domains?

  Headers can be forged, so persistent people can easily bypass any 
  restrictions based on the message headers. 

  The following access rule will cause posted messages from any address
  outside the "example.com" domain to be moderated.

configset LISTNAME access_rules <<END
post
consult, reason="Outsiders require approval."
!/example\.com$/
END


Problem  How do I keep anyone, or a certain domain, from posting
-------  while allowing all other users and domains to post freely?

  First note that headers can be forged and so if people really want to
  bypass a header-based restriction they can. Often what you REALLY
  want is to keep one user from posting while allowing everyone else
  to post, but the "freebie" domains make it easy to create new accounts
  and cause trouble.

  Here is how to lock out one domain, using Yahoo as an example. Note
  that the '@' and '.' characters need to be escaped with "\", and
  refer to "help patterns" for details on regular expressions:

configset LISTNAME  access_rules <<END
post
deny
/\@yahoo\.com$/
END

  Here is how to lock out TWO domains, using Yahoo and MSN, and you
  can add more domains to the list as needed:

configset LISTNAME access_rules <<END
post
deny
/\@yahoo\.com$/ OR /\@msn\.com$/
END

  Here is how to lock out the entire Yahoo domain, and also any email
  address from any domain which contains the string "calliger":

configset LISTNAME access_rules <<END
post
deny
/\@yahoo\.com$/i OR /calliger/i
END


Problem  How to I stop massive crossposting between my mailing list
-------  and other mailing lists at this site, and perhaps other sites?

  You can do this using taboo_headers matches and an access rule.

configset LISTNAME taboo_headers <<END
/^(to|cc):.*some-list/i 10,crosspost
/^(to|cc):.*some-other-list/i 10,crosspost
/^(to|cc):.*another-related-list/i 10,crosspost
/^(to|cc):.*yet-another-list/i 10,crosspost
/^(to|cc):.*and-another/i 10,crosspost
END

  These look like normal taboo_headers entries, with a twist:  the
  information on the end contains a 'score' (or a 'severity') and a name.
  Taboo matches can be given names; when one of them matches, the score is
  added to that name.  So for every match, ten points are added to the
  'crosspost' match.  Note that if you included your own list there, the
  match will start out at 10.

  Now, you have to test the score of the 'crosspost' match and do something
  with the message if it matches too many times.  This is with an access
  rule:

configset LISTNAME access_rules <<END
post
deny, reason="Cross-posting is prohibited"
$taboo_crosspost >= 30
END

  The person who posted the message may or may not receive a notice indicating
  that the message was denied.  See "help configset_nonmember_flags" and
  "help set" for details on the "ackdeny" setting.

  The "unique" delivery class can be used to keep people from receiving
  duplicates when messages are cross-posted to lists in the same domain.
  See "help set" for more details.


Problem  I want people to read my list for a few days before they post.
------- 

  The number of days that have passed since the author of a message
  subscribed is recorded in the days_since_subscribe access variable.
  To moderate posted messages from people who have been subscribed
  less than three days, use the following access rule:

configset LISTNAME access_rules <<END
post
consult, reason="New subscribers are moderated"
$days_since_subscribe < 3
END


If you don't find the answers to your questions here, please write to
the software developers at mj2-dev@lists.mj2.org. 


Which settings take precedence?
-------------------------------

Majordomo has many configuration settings which determine what happens
to a posted message.  You may wonder which settings have priority if one
setting says a message should be sent to the moderators and another
setting says a message should be thrown away.  Majordomo takes the
following steps to determine what rules apply to each message:

* The access_rules setting takes priority.  The first access rule with a
  "terminal" outcome (consult, deny, confirm, and so on) that matches the
  message causes that outcome to happen immediately.

If no "terminal" access rule applies, only then can the other configuration 
settings have any effect, in the following order:

* If the message exceeds a hard limit in the post_limits configuration
  setting, or contains an illegal body part according to the
  attachment_rules setting, the message is discarded.

* Any of the conditions listed in the "Causes of moderation" section, 
  earlier in this document, will cause the message to be moderated.

* Finally, if none of these restrictions applies, the message is posted
  to the subscribers.


See Also:
   help accept
   help admin
   help admin_commands
   help admin_config
   help admin_delivery
   help admin_documents
   help admin_monitor
   help admin_passwords
   help admin_subscribers
   help configdef
   help configset
   help configset_access_rules
   help configset_ack_attach_original
   help configset_attachment_rules
   help configset_default_flags
   help configset_moderators
   help configset_nonmember_flags
   help configset_post_limits
   help configset_whoami_owner
   help configshow
   help reject
   help set        (for a description of the postblock personal setting)
   help showtokens
   help tokeninfo

This is the "admin_moderate" help document for 
Majordomo 2, version 0.1201103110.

For a list of all help documents, send the following command:
   help topics
in the body of a message to majordomo@openbsd.org.

For assistance, please contact the openbsd.org administrators.
Sign In Sign Out Mailing Lists Unsubscribe or Change Settings Help