| 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 |