| Sign In | Sign Out | Subscribe to Mailing Lists | Unsubscribe or Change Settings | Help |
smoe.org mailing lists
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.
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.1200401130.
For a list of all help documents, send the following command:
help topics
in the body of a message to mj2@smoe.org.
For assistance, please contact the smoe.org administrators.
| Sign In | Sign Out | Subscribe to Mailing Lists | Unsubscribe or Change Settings | Help |