Table of Contents
Here is a snapshot of what Sympa looks like once installed on your system. This also illustrates the Sympa philosophy, we guess. Almost all configuration files can be defined for a particular list, for a virtual host or for the entire site, and most of them have a reasonable default value provided by Sympa distribution.
The following reference manual assumes a particular location for all files and directories. Note that binary distributions usually change those locations according to the operating system file organization. When installing Sympa from source kit, configure can be called with command options in order to change all default file locations.
The root directory of Sympa. You will find almost everything related to Sympa under this directory, except logs and main configuration files.
This directory contains the binaries, including the CGI.
Here Sympa stores the default versions of what it will otherwise find in
/home/sympa/etc(task models, authorization scenarios, templates and configuration files, recognized S/Mime certificates, families).
/home/sympa/defaultmay be completely overwritten by the
make installso you must not customize templates and authorization scenarios under
This is your site's configuration directory. Consult
/home/sympa/bin/etcwhen drawing up your own.
List templates (suggested at list creation time).
This directory will contain your authorization scenarios. If you don't know what the hell an authorization scenario is, refer to Authorization scenarios. Those authorization scenarios are default scenarios but you may look at
/home/sympa/etc/my.domain.org/scenari/for default scenarios of my.domain.org virtual host and
/home/sympa/list_data/mylist/scenarifor scenarios specific to a particular list.
This directory will contain your .incl files (see Data inclusion file). At the moment it only deals with files required by paragraphs
editor_includein the config file.
This directory will store your own list task models (see Customizing tasks).
Contains your global task models (see Customizing tasks).
/home/sympa/etc/web_tt2/(used to be
The web interface (WWSympa) is composed of template HTML files parsed by the CGI program. Templates can also be defined for a particular list in
/home/sympa/etc/mail_tt2/(used to be
Some of the mail robot's replies are defined by templates (
welcome.tt2for SUBSCRIBE). You can overload these template files in the individual list directories or for each virtual host, but these are the defaults.
Contains your family directories (see Mailing list creation). Family directories can also be created in
The directory to define the virtual host my.domain.org dedicated to management of all lists of this domain (list description of my.domain.org are stored in
/home/sympa/list_data/my.domain.org). Those directories for virtual hosts have the same structure as
/home/sympa/etcwhich is the configuration dir of the default robot.
Sympa's working directory.
The list directory (refer to Mailing list definition). Lists stored in this directory belong to the default robot as defined in sympa.conf file, but a list can be stored in
/home/sympa/list_data/my.domain.org/mylistdirectory and it is managed by my.domain.org virtual host.
The directory where Sympa stores all user's certificates.
Internationalization directory. It contains message catalogues in the GNU .po format.
Sympa uses different spools (see Spools).
The main daemon; it processes commands and prepares messages in database. Continuously scans the
The distribution message daemon ; Continuously scans the database (
bulkmailer_table) and send messages as prepared by sympa.pl
A wizard to edit
sympa.conf. Maybe it is a good idea to run it at the beginning, but these files can also be edited with your favorite text editor.
The CGI program offering a complete web interface to mailing lists. It can work in both classical CGI and FastCGI modes, although we recommend FastCGI mode, being up to 10 times faster.
This daemon processes bounces (non-delivered messages), looking for bad addresses. List owners will later access bounce information via WWSympa. Continuously scans the
This daemon feeds the web archives, converting messages to HTML format and linking them. It uses the amazing
MhOnArc. Continuously scans the
The daemon which manages the tasks: creation, checking, execution. It regularly scans the
The server will process SOAP (web services) request. This server requires FastCGI; it should be referenced from within your HTTPS config.
This small program gets the incoming messages from the aliases and stores them in
queuefor bounces. Stores bounces in
queuefor automatic lists (lists defined by family and created when receiving a mesage for it. Stores incomming messages in spool 'automatic'.
The main configuration file. See Sympa.conf parameters.
Defines which parameters/files are editable by owners. See List editing.
Contains the declarations of your site's topics (classification in WWSympa), along with their titles. A sample is provided in the
sample/directory of the Sympa distribution. See Topics.
Defines authentication backend organization (LDAP-based authentication, CAS-based authentication and Sympa internal).
It is a subset of
sympa.confdefining a Virtual host (one per Virtual host).
This file specifies how Sympa detects web crawlers. It is used in order to optimize the Sympa web interface responses and internal mechanisms for crawlers. In this version the file is limited to a list of user agent strings, but in the future it may be enriched with IP adresses. When a crawler is detected, Sympa allows the web client to cache pages so crawlers should not browse old archives every day. In addition, Sympa does not create http sessions for crawlers. This keeps the Sympa session table quite small.
This file is used to limit the number of recipients per SMTP session. Some ISPs trying to block spams reject sessions with too many recipients. In such cases you can set the nrcpt robot.conf parameter to a lower value but this will affect all SMTP sessions with any remote MTA. This file is used to limit the number of recipients for some specific domains. The file must contain a list of domains followed by the maximum number of recipients per SMTP session. Example:
yohaa.com 3 oal.com 5
This file is automatically created and maintained by Sympa itself. It contains the current version of your Sympa service and is used to detect upgrades and trigger maintenance procedures such as database structure changes.
This file defines the parameters for a LDAP directory, when using
ldap_alias_manager.plas the mail aliases management script.
As of Sympa 6.2,
wwsympa.confconfiguration file was obsoleted and unified to
See Spool related for spool definition in
For storing messages until they have been confirmed. Files are created and processed by the
For storing incoming bouncing messages. Files are created by the
bouncequeueprogram (via mail aliases) and processed by the
For storing bouncing messages for which bounce management failed, though an user was identified. Files are moved there by the
For storing message digests before they are sent. Files are created and processed by the
For storing unmoderated messages. Files are created by the
sympa.plprogram and processed by either
For storing incoming messages (including commands). Files are created by the
queueprogram (via mail aliases) and processed by the
Sympa stores rejected messages in this directory. Files are created by the
For storing messages ready for distribution. This spool is used only if the installation runs 2
sympa.pldaemons, one for commands, one for messages.
Sympa stores rejected messages in this directory. Files are created by the
sympa.plprocess dedicated to message distribution.
For storing all tasks created. Files are created and processed by the
sympa.pldumps messages in this spool to await archiving by
wwsympa.fcgimay also create files in this spool.
For storing messages which couldn't be archived. Files are moved there by the
For storing topic information files.
For storing temporary information, as stderr flux from processes or message parts submitted to the anti-virus
You can assign roles to users (identified via their email addresses) at different levels in Sympa; privileges are associated (or can be associated) to these roles. We list these roles below (from the most powerful to the least), along with the relevant privileges.
These are the persons administrating the service, defined in the
sympa.conffile. They inherit the listmaster role in virtual hosts and are the default set of listmasters for virtual hosts.
You can define a different set of listmasters at a virtual host level (in the
robot.conffile). They are responsible for moderating mailing lists creation (if list creation is configured this way), editing default templates, providing help to list owners and moderators. Users defined as listmasters get a privileged access to the Sympa web interface. Listmasters also inherit the privileges of list owners (for any list defined in the virtual host), but not the moderator privileges.
The first defined privileged owner is the person who requested the list creation. Later it can be changed or extended. They inherit (basic) owner privileges and are also responsible for managing the list owners and editors themselves (through the web interface). With Sympa's default behavior, privileged owners can edit more list parameters than (basic) owners can do; but this can be customized via the
They are responsible for managing the members of the list, editing the list configuration and templates. Owners (and privileged owners) are defined in the list config file.
Moderators are responsible for the messages distributed in the mailing list (as opposed to owners who look after list members). Moderators are active if the list has been setup as a moderated mailing list. If no moderator is defined for the list, then list owners will inherit the moderator role.
Subscribers are the people who are members of a mailing list; they either subscribed, or got added directly by the listmaster or via a data source (LDAP, SQL, another list, ...). These subscribers receive messages posted in the list (unless they have set the
nomailoption) and have special privileges to post in the mailing list (unless it is a newsletter). Most privileges a subscriber may have are not hard coded in Sympa but expressed via the so-called authorization scenarios (see Scenarios).