Sign In Sign Out Mailing Lists Unsubscribe or Change Settings Help

OpenBSD Mailing List Server

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
configset  GLOBAL  access_rules <<TAG
[VALUE LINES]
TAG
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
configset listname access_rules <<TAG
[VALUE LINES]
TAG
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Default Value : no default
Data Type     : access_rules
Category      : access moderate
Password Notes: Visible only with password. 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

EXAMPLE:
configset GLOBAL access_rules << ENDTAG
show,which,who
deny, replyfile=NoShowWhichWho
ALL

access
deny
/msn/i OR /hotbot/i
ENDTAG

The access_rules setting controls who is permitted to use Majordomo
commands or to post messages to a mailing list.  Each rule consists of
three or more lines.  

The first line is one or more Majordomo commands, separated by commas.

The second line is one or more actions to take, separated by commas.

The third and succeeding lines specify the conditions under which the
rule is used.

Blank lines are used to separate individual rules from one another.

The access_rules setting is a powerful feature that can be used for
fine-grained control of specific Majordomo commands.  In many cases,
more convenient configuration settings, such as the subscribe_policy
setting, are available to control access to common commands.  The
access_rules setting will override any of these other settings.

The commands, actions, and conditions are described in detail in the
following sections of this document.


                                Commands

Access rules for the GLOBAL pseudo-list do not apply to regular mailing
lists; they primarily apply to commands that are not list-specific.  The
following table illustrates which access rules and other settings
apply to which commands:


Command     Which rules apply  Other settings for this command
---------------------------------------------------------------------
accept      none               none
access      GLOBAL             block_headers
advertise   list-specific**    advertise, noadvertise
alias       GLOBAL             none
announce    list-specific*     none
approve     none               none
archive     list-specific      archive_access
changeaddr  GLOBAL             none
configdef   none               none
configset   none               none
configshow  none               none
createlist  GLOBAL             none
default     none               none
digest      list-specific      none
end         none               none
faq         list-specific*     faq_access
get         list-specific*     get_access
help        GLOBAL             none
index       list-specific*     index_access
info        list-specific*     info_access
intro       list-specific*     intro_access
lists       GLOBAL**           advertise, noadvertise
owner       list-specific*     none
password    GLOBAL             none
post        list-specific      moderate, restrict_post, etc.
put         list-specific*     none
register    GLOBAL             none
reject      none               none
rekey       GLOBAL             none
sessioninfo none               none
set         list-specific*     set_policy
show        GLOBAL             none
showtokens  list-specific*     none
subscribe   list-specific*     subscribe_policy
tokeninfo   list-specific*     none
trigger     none               none
unalias     GLOBAL             none
unregister  GLOBAL             none
unsubscribe list-specific*     unsubscribe_policy
which       list-specific      which_access
who         list-specific*     who_access
---------------------------------------------------------------------
* Some list-specific commands can be affected by GLOBAL access rules.
  For example, a GLOBAL access rule for the set command would affect the
  "set ALL" command, which allows the settings for multiple list
  subscriptions to be changed at once.  Please refer to the help file for
  each command for more details on the exceptions.

** List-specific rules for the lists command should use the word 
   "advertise" instead of the word "lists" on the first line of
   each rule.

The table lists several commands for which the access rules have no
effect.  There are basically two cases in which this is true.  For some
administrative commands (configdef, configset, configshow), an
administrative password is always required.  For other commands, no
password is ever needed:  for example, to use the tokeninfo or
sessioninfo command, it is only necessary to know the token or session
number.

In general, any command that is issued with a valid administrative
password will succeed immediately, and the access_rules setting will
have no effect.  There are two exceptions to this rule for commands that
are affected by the access rules:  if the access_password_override
setting is turned off, or if the "rule" command mode is used.  For
example, the following command:

  subscribe-rule LISTNAME

would be subject to the access rules for the LISTNAME mailing list,
regardless of whether an administrative password is used.

It is possible to use comments before, between, and after the individual
rules, but not within rules.  Comments are lines that begin with a '#'.

Any access rule which refers to an auxiliary list will cause it to be
created automatically.  See "help auxiliary_list" for an introduction to
auxiliary lists.


                                Actions

The following table summarizes every action that can be used on
the second line of an access rule.  The first rule that matches the
command and conditions and that contains a "terminal" action will cause
all succeeding rules to be ignored.

Action     Terminal?     Default Reply File         
-------------------------------------------------------------------
allow            yes     none
confirm          yes     repl_confirm
confirm2         yes     repl_confirm2* 
confirm_consult  yes     repl_confcons
consult          yes     repl_consult or ack_stall
default          yes     none
delay            yes     repl_delay or ack_delay
deny             yes     repl_deny or ack_denial
forward          yes     repl_forward
mailfile          no     none
notify            no     none
replyfile         no     none
set               no     none
unset             no     none
-------------------------------------------------------------------
* If the victim's password is supplied, and only one confirmation 
  step is required, the repl_confirm_req reply file will be used by 
  default.

The default reply file is used to display the result of a command.  The
ack_delay, ack_denial, and ack_stall files are only used in response to
posted messages.  See "help reply_files" and the Reply Files section of
this document for more information.

In the descriptions of each action that follow, the "victim" is the
address of the person affected by a command, and the "requester" is the
address of the person who issued the command.  For example, if
jane@example.net issues the following command:

  subscribe LISTNAME ruth@example.com

the requester is jane@example.net, and the victim is ruth@example.com.
In many cases, the requester and the victim will be identical.

Each action can optionally be customized by following its name with an
equals sign and one or more parameters, separated by commas.  The
purpose of the parameters varies from action to action.


allow
-----
The allow action causes the command to succeed immediately.

The allow action takes one parameter, a number, for example:
  allow=3
The default value of this parameter is 1.

Using a higher number can influence the result of the which and who
commands.  See the Illustrative Examples section of this document for
more details.

The "default" action for the post command includes checks that prevent
large messages and mail loops from appearing on the list.  Use the
allow action with caution in rules for the post command, because these
checks will be bypassed.


confirm
-------
The confirm action causes a confirmation notice to be mailed to the
address of the victim.

The confirm action takes one parameter, the name of the file that is
mailed to the victim.  The default value is "confirm".


confirm2
--------
The confirm2 action depends upon the identities of the requester and the
victim, according to the following three rules:

* If requester and victim are identical, send a confirmation message to
  the victim.

* If requester and victim are different, but the victim's password
  was supplied, confirm with the requester. The confirmation message 
  will state that the command was requested by the victim.

* Otherwise, send a confirmation message to the victim, and if the
  victim confirms the command, send a confirmation message to the
  requester.

The confirm2 action takes up to two parameters:

The first parameter is the name of the file sent to the victim.
The default value is "confirm".

The second parameter is the name of the file sent to the requester.
The default value is "confirm".

This is the default action for the changeaddr command, but it may 
also be used for other commands where the user and victim are
different.


confirm_consult
---------------
The confirm_consult action causes a confirmation message to be sent to
the victim.  If the victim approves the message, a confirmation message
is sent to the moderators of the list.

The confirm_consult action takes up to four parameters:

The first parameter is the name of the file sent to the victim.
The default value is "confirm".

The second parameter is the name of the file sent to the moderators.
The default value is "consult".

The third parameter is the name of an auxiliary list which contains the
addresses of the moderators.   The default value is "moderators".  If
the auxiliary list does not contain any addresses, the moderators, and
whoami_owner configuration settings are examined until a valid address
is found.

The fourth parameter is the number of moderator approvals required.
The default value is 1.


consult
-------
The consult action causes a confirmation notice to be sent to a
group of moderators.

The consult action takes up to four parameters.

The first parameter is the name of the file sent to the moderators.
The default value is "consult".

The second parameter is the number of approvals required to confirm
the command.  The default value is 1.

The third parameter is the name of an auxiliary list which contains the
addresses of the moderators.   The default value is "moderators".  If
the auxiliary list does not contain any addresses, the moderators, and
whoami_owner configuration settings are examined until a valid address
is found.

The fourth parameter is the size of the pool of moderators who receive
the confirmation message.  If this number is smaller than the total
number of moderators and greater than zero, the moderators who receive
the confirmation are chosen randomly.  If this number is 0, all of the
moderators receive the confirmation message.  If this number is -1,
the pool size is taken from the moderator_group configuration setting.
The default value is -1.


default
-------
The default action causes all succeeding access rules to be ignored.
The default result for the command is used; see "help access_variables"
for a description of the default actions for each command.

The default action takes no parameters.


delay
-----
The delay action causes a command to be postponed until a later time.

The delay action takes up to two parameters:

The first parameter is the name of the file that is sent to the victim.
The default value is "delay".

The second parameter is the amount of time to delay the command.
See the "Time Period" section of "help times" for the time specification 
format.  The default value is 0.

The access rules have both a delay action and a delay variable.
See "help access_variables" for a description of the delay variable.

See "help delay" for an explanation of how delayed commands are
completed.


deny
----
The deny action causes the command to be discarded.

The deny action takes one parameter, the name of the reply file to be
sent to the requester.  The default value is "ack_denial" for posted
messages and "repl_deny" for all other commands.


forward
-------
The forward action causes the command or posted message to be mailed to
another address.

The forward action takes one parameter, the address to which the command
is forwarded.  The default value is the address in the whoami_owner
configuration setting.

A notice indicating that the message was forwarded will be sent to the
author of the message if the author's "ackstall" setting is enabled.
See "help set" for an explanation of that setting.


mailfile
--------
The mailfile action causes a file to be mailed to the address of the
victim.  This file is sent in addition to any reply message that would
ordinarily be sent to the requester.

The mailfile action takes one parameter, the name of the file to mail.
The default is a "file not found" error message.


notify
------
The notify action allows fine-grained control of the attributes of a
confirmation notice for the confirm, confirm2, confirm_consult, and
consult actions.  Up to four notify actions can be used by one rule.

The notify action takes one or more parameters of the form
  variable=value
The supported "notify variables" are documented in the 
"help access_variables" document.


reason
------
The reason action allows additional information to be included in the
reply message that is sent to the requester.  The collection of reasons
is made available in the $REASONS keyword substitution in the reply
file.  Reasons are also displayed in confirmation messages.

The reason action takes one parameter, a brief, free text message.
The default value is empty.  


reply
-----
The reply action replaces the text of the default reply file that is
sent to the requester with a brief message.

The reply action takes one parameter, a brief, free text message.
The default value is empty.


replyfile
---------
The replyfile action replaces the name of the default reply file that
is sent to the requester.

The replyfile action takes one parameter, a file name.  The default
value is "file_not_found".


set
---
The set action changes the value of an access variable.  See 
"help access_variables" for a list of the variables that are supported.

The set action takes one parameter, of the following form:
  variable=value
If only the variable name is used, the variable is set to the value 1.


unset
-----
The unset action resets the value of an access variable.  See 
"help access_variables" for a list of the variables that are supported.

The unset action takes one parameter, the name of an access variable.
The variable is set to 0 (for boolean, numeric, and timespan variables) 
or the empty string (for string variables).



                               Conditions

An access rule will only be applicable to a particular command if the
rule's conditions match the characteristics of the command.

If no rules match, the "default" action is taken, which results in a
reasonable emulation of the Majordomo 1 behavior using who_access,
moderate, restrict_post, and other configuration settings. The default
actions for all requests are listed below.

Several special features are supported by the condition syntax:

Logical
-------
  AND, && - the conditions on both sides must be true
  OR, ||  - any one or both of the conditions must be true.
  NOT, !  - the following condition must be false
  
Grouping
--------
  (, ) - parentheses may be used to enclose groups of conditions.

Address match
-------------
  /expression/ - true if the e-mail address of the victim matches 
  the regular expression.  See "help patterns" for an introduction to
  regular expressions.

Membership check
----------------
  @MAIN - true if the victim is a subscriber to the mailing list.
          ('@' can be used as an abbreviation for '@MAIN'.)
  @SUBLIST - true if the victim is a member of the SUBLIST auxiliary
    list. (See "help auxiliary_list" for an introduction to sublists.)
  @LIST:SUBLIST - true if the victim is a member of the SUBLIST
    auxiliary list of the LIST mailing list.

Comparisons
-----------
  $variable          
    is true if the supplied variable has a true value.
    True values are neither 0 nor a zero-length string.

  $variable = STRING
    is true if the variable equals the given string of characters.

  $variable != STRING
    is true if the variable does not equal the given string of characters.

  $variable =~ /PATTERN/
    is true if the variable matches the given pattern.

  $variable !~ /PATTERN/
    is true if the variable does not match the given pattern.

  $variable <  NUMBER
    is true if the variable is less than the given number.

  $variable <= NUMBER
    is true if the variable is less than or equal to the given number.

  $variable >  NUMBER
    is true if the variable is greater than the given number.

  $variable >= NUMBER
    is true if the variable is greater than or equal to the given number.

  $variable == NUMBER
    is true if the variable is equal to the given number.

  $variable <> NUMBER
    is true if the variable is not equal to the given number.

  ALL
    is always true.

See "help access_variables" for a list of the variables that can be used
in comparisons.

Time constraints
----------------
  *time* - true if the current time matches the time specification
  between the asterisks.  See the "Scheduled times" section of the
  "help times" document for a description of the syntax.


                             Reply Messages

Reply messages indicating the result of a command or posted message are
not always sent to the requester.  A reply will not be sent under the
following circumstances:

* A posted message requires confirmation, is delayed, or is forwarded,
  and the "ackstall" flag is not set for the author of the message.

* A posted message is denied and the "ackdeny" flag is not set for the
  author of the message.

* A posted message is allowed and the "ackpost" flag is not set for the 
  author of the message.

See "help set" and "help configset_nonmember_flags" for more information
about the acknowledgement flags.

In messages returned by the mailfile, reply, and replyfile actions, the
standard substitution variables plus CMDLINE, FULFILL, NOTIFY, REASONS,
REQUESTER, and VICTIM are supported.  See "help variables" for a
description of each variable. 

The syntax for specifying file names with access variables is different
from the put and get commands.  If a file name is specified without a
leading '/', the slash is automatically prefixed.  In other
words,"consult" and "/consult" are identical.  This is also true for the
"file" and "chainfile" notify variables.

The actions
  reply=NONE
and
  replyfile=NONE
will override the "ackstall" or "ackdeny" flag and prevent a reply
message from being sent if a posted message is delayed, denied,
forwarded, or requires confirmation.

A reply of "NONE" can also be used to prevent the "Majordomo results"
message from being sent to a person who will also receive a confirmation
message.  For example, the following rule:

  subscribe
  confirm, reply=NONE, reason="Confirmation prevents subscription forgeries" 
  $interface =~ /^email/ AND !$mismatch AND !$user_password
  
will prevent the results from being mailed if the subscribe command is
the only command that Majordomo processes.  The "interface" condition is
necessary to keep web users from seeing no reply.

In general, a reply of "NONE" has no effect upon a command that succeeds
immediately.


                            Default Actions

If no access rules with terminal actions (other than the "default"
action) apply to a command or posted message, Majordomo will apply the
default action for the command, as described by the following table:

Command           Default action
--------------------------------
access            special
advertise         special
alias             confirm
announce          deny
archive           access
changeaddr        confirm2
createlist        deny
digest            deny
faq               access
get               access
help              allow
index             access
info              access
intro             access
lists             allow
password          confirm
post              special
put               deny
register          confirm
rekey             deny
report            deny
request_response  allow
set               policy
show              mismatch
showtokens        deny
subscribe         policy
tokeninfo         allow
unalias           confirm
unregister        confirm
unsubscribe       policy
which             access
who               access

In addition to the actions already described, the default actions
include the following possibilities:

access
  Default access is determined by a configuration setting.  For example,
  the "which" command is controlled by the "which_access" setting.

mismatch
  The command will succeed unless the requester and victim do not match,
  or if someone is posing using the "default user" command.  See
  "help default" for more information.

policy
  Default access is determined by a configuration setting.  For example, the
  "subscribe" command is controlled by the "subscribe_policy" setting.

special
  Default access is determined by a variety of configuration settings.

The "special" default access for the lists ("advertise") command is
determined by the advertise and noadvertise configuration settings.
See "help configset_advertise" and "help configset_noadvertise" for more
details.

The "special" default access for the post command causes several
configuration settings, including the moderate, restrict_post,
taboo_body, and taboo_headers settings, to be examined.  See "help
admin_moderate" for more details.


                         Illustrative Examples                                

Moderate posts from non-subscribers
-----------------------------------
post
consult, reason="A message was posted by a non-subscriber"
!@MAIN

The "!@MAIN" condition matches any address in the "From" header of a message that
is not subscribed to your mailing list.


Customize the reply message for admin and taboo violations
----------------------------------------------------------
If a message violates the checks in the admin_body or admin_headers
setting, the "admin" access variable will be set.  The same applies to
the "taboo" access variable and the taboo_body and taboo_headers
settings.  The following rule customizes the reply file that is sent
when a message violates any of these settings.

post
deny, replyfile=SacredWordsUsed
$admin OR $taboo

The "SacredWordsUsed" file should already exist in the file space of
your mailing list.  See "help admin_documents" and "help put" for more
information about the file space.


Moderate new subscribers
------------------------
The following rule would cause posted messages from people who have been
subscribed less than 14 days to be moderated.  The days_since_subscribe
access variable will be set to -1 for non-subscribers; only subscribers
will have a value of 0 or greater.

post
consult, reason="New subscribers are moderated"
$days_since_subscribe >= 0 AND $days_since_subscribe < 14


Confirm "mismatched" subscriptions with both addresses
------------------------------------------------------
Usually, a subscribe command with a requester and victim that vary will
require the approval of the moderators of a mailing list.  The following
rule causes a confirmation message to be sent to the requester and
victim at the same time.

subscribe
confirm2, chain=0
$mismatch


Ban posted messages from abusers
--------------------------------
The addresses of abusers can be stored in an auxiliary list using the
subscribe command.  The name of the auxiliary list is arbitrary.

post
deny, reason="Messages posted from this address are banned"
@banned

To receive a brief notice when posted messages are denied, you may need
to adjust the inform configuration setting.  See "help configset_inform"
for more details.


Allow posted messages from a small group
----------------------------------------
The following two rules would allow all members of the heroes auxiliary
list to post without interference, while everyone else is moderated.

post
default
@heroes

post
consult, reason="The mailing list is moderated"
ALL

Using the "default" action instead of the "allow" action for members of
the heroes sublist will keep duplicate message checks, size limits, and
other protective measures intact.


Mail a questionnaire to prospective subscribers
-----------------------------------------------
The questionnaire file should already be present in your list's file
space before you add this rule.  The name of the file is arbitrary.

subscribe
mailfile="/questions", reply="A questionnaire is being mailed to you."
!@MAIN


Mail a questionnaire to prospective subscribers after confirmation
------------------------------------------------------------------
Consider the following scenario:  a subscription to a mailing list
requires the confirmation of both the victim and the moderators of the
list.  After the victim confirms the subscription, a questionnaire is
mailed to the victim.  The moderators will approve the subscription only
when the completed questionnaire is mailed to them.

The following access rule will make this possible:

subscribe
confirm_consult, notify, notify=(fulfill=1,expire=0,chainfile=more_info,file=questions,group=victim), notify
ALL

This rule uses three "notify" actions to modify the behavior of the
confirm_consult action.  Normally, the confirm_consult action would
cause two confirmation notices to be sent:  the "confirm" notice would
be sent to the victim, and the "consult" notice would be sent to the
moderators after the victim confirms the first notice.  Using three
notices causes both the second notice and the third notice to have the
characteristics of a "consult" notice by default.

The first notify action has no customizations.  This causes the default
"confirm" confirmation message to be sent to the victim.  

The second notify action modifies a "consult" action with several
customizations:

  * The "group=victim" customization causes the notice to be sent to
    the victim instead of the moderators.

  * The "chainfile=more_info" customization causes the "more_info" reply file 
    to be sent to the person who confirmed the first confirmation message.

  * The "file=questions" customization causes the "questions" file to
    be sent to the victim in a separate message.

  * The "fulfill" and "expire" variables cause a delay token to be created 
    which will expire immediately.  Expiring the token immediately makes
    it unnecessary for someone to confirm the second notice.

The third notify action has no customizations.  This causes the default
"consult" confirmation message to be sent to the moderators of the
mailing list.


Prevent duplicate message checksums from being used
---------------------------------------------------
Normally, a posted message with a body that matches a previously posted
message will be sent to the moderators for confirmation.  The following
rule will turn off the body checks.

post
unset=dup_checksum, unset=dup_partial_checksum
ALL

This rule unsets the dup_checksum and dup_partial_checksum access
variables.  See "help configset_dup_lifetime" for an explanation of the
body checks.


Allow the which command to show more e-mail addresses
-----------------------------------------------------
Unless a site or domain administrative password is used, a maximum of 1
address will be returned for each mailing list when someone uses the
which command.  The following rule will change the maximum to 5
addresses.

which
allow=5
ALL


Allow the who command to show setting info
------------------------------------------
Unless an administrative password is used, the who-export and
who-enhanced commands will not show information about settings.  The
following rule will allow information about other subscribers' settings
to be seen by list members.

who
allow=2
@MAIN


Delay unsubscriptions
---------------------
In the following example, the unsubscribe-rule command, used in
conjunction with an administrative password, would cause the "expiring"
file to be mailed to the victim.  The victim would have four days to
reject the unsubscribe command and preserve the subscription.

unsubscribe
delay=(expiring,4d)
$master_password

The master_password access variable will be set only if the unsubscribe
command is issued using an administrative password.  This will prevent
unauthorized people from using the unsubscribe-rule command to remove
other people from your mailing list.

See "help admin_passwords" for an introduction to administrative
passwords.  See "help access_variables" for an introduction to access
variables.  See "help configset_access_password_override" and 
"help unsubscribe" for an explanation of the "rule" command mode.


Delay posts to spread out the system load
-----------------------------------------
The following rule would delay for four hours all messages that are
posted between 8:00 and 17:59.  The delay only affects posted messages that
would otherwise be distributed immediately.

post
set=(delay=4h), reason="Daytime messages are delayed."
*08-17*

See "help delay" for more details on delays.


See Also:
   help access    (for the special case of granting/denying all access)
   help access_variables              (for requests, variables, defaults)
   help admin_moderate
   help configset_access_password_override
   help configset_archive_access      (for     archive command access_rules)
   help configset_block_headers       (for how to filter out server requests)
   help configset_faq_access          (for         faq command access_rules)
   help configset_get_access          (for         get command access_rules)
   help configset_index_access        (for       index command access_rules)
   help configset_info_access         (for        info command access_rules)
   help configset_intro_access        (for       intro command access_rules)
   help configset_moderate
   help configset_post_limits         (for how to restrict posting frequency)
   help configset_restrict_post
   help configset_set_policy          (for         set command access_rules)
   help configset_subscribe_policy    (for   subscribe command access_rules)
   help configset_unsubscribe_policy  (for unsubscribe command access_rules)
   help configset_which_access        (for       which command access_rules)
   help configset_who_access          (for         who command access_rules)
   help delay
   help subscribe (How to add addresses to auxiliary lists)
   help times     (How to specify a delay)
   help variables (A description of keyword substitutions variables)

This is the "configset_access_rules" 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