List parameters controlling the behavior of commands are linked to different authorization scenarios. For example : the send private parameter is related to the send.private scenario. There are four possible locations for a authorization scenario. When Sympa seeks to apply an authorization scenario, it looks first in the related list directory /home/sympa/expl/<list>/scenari. If it does not find the file there, it scans the current robot configuration directory /home/sympa/etc/my.domain.org/scenari, then the site's configuration directory /home/sympa/etc/scenari, and finally /home/sympa/bin/etc/scenari, which is the directory installed by the Makefile.
An authorization scenario is a small configuration language to describe who can perform an operation and which authentication method is requested for it. An authorization scenario is an ordered set of rules. The goal is to provide a simple and flexible way to configure authorization and required authentication method for each operation.
Each authorization scenario rule contains :
![[*]](crossref.png)
).
Example
del.auth
title.us deletion performed only by list owners, need authentication title.fr suppression réservée au propriétaire avec authentification title.es eliminacin reservada slo para el propietario, necesita autentificacin is_owner([listname],[sender]) smtp -> request_auth is_listmaster([sender]) smtp -> request_auth true() md5,smime -> do_it
An authorization scenario consists of rules, evaluated in order beginning with the first. Rules are defined as follows :
<rule> ::= <condition> <auth_list> -> <action>
<condition> ::= [!] <condition
| true ()
| all ()
| equal (<var>, <var>)
| match (<var>, /perl_regexp/)
| search (<filter.ldap>,<var>)
| is_subscriber (<listname>, <var>)
| is_owner (<listname>, <var>)
| is_editor (<listname>, <var>)
| is_listmaster (<var>)
| older (<date>, <date>) # true if first date is anterior to the second date
| newer (<date>, <date>) # true if first date is posterior to the second date
<var> ::= [email] | [sender] | [user-><user_key_word>] | [previous_email]
| [remote_host] | [remote_addr] | [user_attributes-><user_attributes_keyword>]
| [subscriber-><subscriber_key_word>] | [list-><list_key_word>] | [env-><env_var>]
| [conf-><conf_key_word>] | [msg_header-><smtp_key_word>] | [msg_body]
| [msg_part->type] | [msg_part->body] | [msg_encrypted] | [is_bcc] | [current_date]
| [topic-auto] | [topic-sender,] | [topic-editor] | [topic] | [topic-needed]
| <string>
[is_bcc] ::= set to 1 if the list is neither in To: nor Cc:
[sender] ::= email address of the current user (used on web or mail interface). Default value is 'nobody'
[previous_email] ::= old email when changing subscription email in preference page.
[msg_encrypted] ::= set to 'smime' if the message was S/MIME encrypted
[topic-auto] ::= topic of the message if it has been automatically tagged
[topic-sender] ::= topic of the message if it has been tagged by sender
[topic-editor] ::= topic of the message if it has been tagged by editor
[topic] ::= topic of the message
[topic-needed] ::= the message has not got any topic and message topic are required for the list
<date> ::= '<date_element> [ +|- <date_element>]'
<date_element> ::= <epoch_date> | <var> | <date_expr>
<epoch_date> ::= <integer>
<date_expr> ::= <integer>y<integer>m<integer>d<integer>h<integer>min<integer>sec
<listname> ::= [listname] | <listname_string>
<auth_list> ::= <auth>,<auth_list> | <auth>
<auth> ::= smtp|md5|smime
<action> ::= do_it [,notify]
| do_it [,quiet]
| reject(reason=<reason_key>)
| reject(tt2=<tpl_name>)
| request_auth
| owner
| editor
| editorkey[,quiet]
| listmaster
<reason_key> ::= match a key in mail_tt2/authorization_reject.tt2 template corresponding to
an information message about the reason of the reject of the user
<tpl_name> ::= corresponding template (<tpl_name>.tt2) is send to the sender
<user_key_word> ::= email | gecos | lang | password | cookie_delay_user
| <additional_user_fields>
<user_attributes_key_word> ::= one of the user attributes provided by the SSO system via environment variables. The [user_attributes] structure is available only if user authenticated with a generic_sso.
<subscriber_key_word> ::= email | gecos | bounce | reception
| visibility | date | update_date
| <additional_subscriber_fields>
<list_key_word> ::= name | host | lang | max_size | priority | reply_to |
status | subject | account | total
<conf_key_word> ::= domain | email | listmaster | default_list_priority |
sympa_priority | request_priority | lang | max_size
(Refer to 16.8, page for date format definition)
The function to evaluate scenario is described in section 28.2.6, page .
perl_regexp can contain the string [host] (interpreted at run time as the list or robot domain). The variable notation [msg_header-><smtp_key_word>] is interpreted as the SMTP header value only when evaluating the authorization scenario for sending messages. It can be used, for example, to require editor validation for multipart messages. [msg_part->type] and [msg_part->body] are the MIME parts content-types and bodies ; the body is available for MIME parts in text/xxx format only.
The difference between editor and editorkey is, that with editor the message is simply forwarded to the moderaotr. He then can forward it to the list, if he wishes. editorkey assigns a key to the message and sends it to the moderator together with the message. So the moderator can just send back the key to distribute the message. Please note, that moderation from the webinterface is only possible when using editorkey, because otherwise there is no copy of the message saved on the server.
A bunch of authorization scenarios is provided with the Sympa distribution ; they provide a large set of configuration that allow to create lists for most usage. But you will probably create authorization scenarios for your own need. In this case, don't forget to restart Sympa and wwsympa because authorization scenarios are not reloaded dynamicaly.
These standard authorization scenarios are located in the /home/sympa/bin/etc/scenari/ directory. Default scenarios are named <command>.default.
You may also define and name your own authorization scenarios. Store them in the /home/sympa/etc/scenari directory. They will not be overwritten by Sympa release. Scenarios can also be defined for a particular virtual host (using directory /home/sympa/etc/<robot>/scenari) or for a list ( /home/sympa/expl/<robot>/<list>/scenari ). Sympa will not dynamically detect that a list config should be reloaded after a scenario has been changed on disk.
Example:
Copy the previous scenario to scenari/subscribe.rennes1 :
equal([sender], 'userxxx@univ-rennes1.fr') smtp,smime -> reject match([sender], /univ-rennes1\.fr$/) smtp,smime -> do_it true() smtp,smime -> owner
You may now refer to this authorization scenario in any list configuration file, for example :
subscribe rennes1
At the moment Named Filters are only used in authorization scenarios. They enable to select a category of people who will be authorized or not to realise some actions.
As a consequence, you can grant privileges in a list to people belonging to an LDAP directory thanks to an authorization scenario.
People are selected through an LDAP filter defined in a configuration file. This file must have the extension '.ldap'.It is stored in /home/sympa/etc/search_filters/.
You must give several informations in order to create a Named Filter: