Sympa Logo
Translations of this page:

Sympa workshop: basic and advanced usage

In the whole documentation, the example host is lists.domain.tld. a script allows you to enter the actual name or your server and replace all occurrences of lists.domain.tld in the page. You just have to enter the name in the form below.

First: check your host name:

hostname -f

Enter the host name here:

Your host name :

First of all:

sudo -i

1 Basic concepts

Define the listmaster email

geany /etc/sympa.conf

Edit the “listmaster” paragraph:

listmaster <>

Restart Sympa and Apache

/etc/init.d/sympa restart ; /etc/init.d/apache2 restart

1.1 connect as listmaster

Go to http://lists.domain.tld/sympa.

Click on “First connexion?”. Fill in the email address you defined in the sympa.conf file, then submit. Check your mailbox; Sympa sent a message. Click the validation link. you're being redirected to the Sympa web interface. Fill in your password and submit.

1.2 Create a list

Click on “List creation”, chose the “Public discussion list” model, then fill the form and submit.

Once you have created the list, you appear as list owner in the list menu.

Several files were created in the process. Check the list directory:

ls -1 /home/sympa/list_data/<nom-de-la-liste>


1.3 Subscribe addresses to the list

Click the “Review members” link in the list menu and add addresses to the form.

Note that you are not subscribed by default, though you are list owner.

You can add several addresses in one time by clicking on “Multiple add” and then put one address per list.

1.4 Send a message to the list

Well, do it. Once the message is sent, you can check that it was archived by clicking the “Archive” link.

1.5 subscriber view

Create an account for one of the addresses you subscribed. Log in with this address and contemplate the different view. You have less options.

1.6 Add an editor and a privileged owner

Go to « Admin

> Edit list config > List definition ». Add an address in the "editors" section and another one in the "owner" section; make sure to set the owner profile as "privileged" (default is "normal").

Note: If you don't defined editors, the list owners are considered as editors by default. For most lists, defining owners is enough.

1.7 List configuration options

Log in using the “privileged owner” account you just defined.

The list owner can edit list parameters through the web interface. Privileges granted to each role are defined by the edit_list.conf configuration file. For each parameter, this file define, for each role an access level:

  • hidden : users with this role can't see the parameter
  • read : users with this role can see the parameter but can't change its value
  • write : users with this role can edit the parameter.

We will now modify the edit-list.conf file.

Before any file configuration, you must first copy the version distributed in Sympa (locate in the “default” directory) to another directory:

  • etc if you want the changes to be global to the server
  • etc/<robot_name>/ (if you use virtual hosts) if you want changes to be global to a given virtual host
  • list_data/<list_name> if you want to limit the change to a single list.

Customize the edit_list.conf file:

cp -p /home/sympa/default/edit_list.conf /home/sympa/etc
geany /home/sympa/etc/edit_list.conf &

Make the include_sql_query parameter critable for a privileged owner.

save the file and close. Go to the list administration page, in the “data sources” section. a new form is available, allowing to configure an SQL data source.

1.8 Lists customization

Here are some of the majot list customization you can do in a list.

Footer and header

You can add automatically a footer or a header to each list's message.

Example with a footer:

geany /home/sympa/list_data/<list_name>/message.footer &

Type anything you like, save and close.

Send a message to the list; the footer is appended at the end of the message body; Note that, by default, this footer is added as an attachment to the message.


What you type here will be displayed at the home page of the list; you can use basic HTML formatting here.

geany /home/sympa/list_data/<nom-de-la-liste>/homepage &

1.9 Create a custom list template

How to customize list models

mkdir /home/sympa/etc/create_list_templates/
chown -R sympa:sympa /home/sympa/etc/create_list_templates/
cp -pr /home/sympa/default/create_list_templates/discussion_list /home/sympa/etc/create_list_templates/

ls -al

total 24
drwxrwxrwx 2 sympa sympa 4096 mai 2 17:32 .
drwxrwxrwx 10 root root 4096 jan 22 14:51 ..
-rw-r--r-- 1 sympa sympa 202 mai 2 17:32 comment.tt2
-rw-r--r-- 1 sympa sympa 835 mai 2 17:32 config.tt2
comment.tt2 : le message affiché dans l'interface de création de listes
config.tt2 : le modèle de configuration de la liste

geany config.tt2 &
## Configuration de la liste sympa-l
## Cree le Mercredi 31 Mars 99

#send editorkey

subject [% subject %]

status [% status %]

visibility noconceal

subscribe open_notify

unsubscribe open_notify

[% FOREACH o = owner -%]
email [% %]
profile privileged
[% IF o.gecos -%]
gecos [% o.gecos %]
[% END -%]

[% END -%]

[% IF owner_include %]
[% FOREACH o = owner_include -%]
source [% o.source %]

[% END -%]
[% END -%]

send privateoreditorkey

[% IF topics -%]
topics [% topics %]
[% END -%]


access public

access owner
period week

digest 1,4 13:26

review owner

d_edit default
d_read public

pictures_feature on

date_epoch [% creation.date_epoch %]
date [% %]
[% IF creation_email -%]
email [% creation_email %]
[% END -%]

Replace [% creation_email %] by your address : Any list created will be marked as created by you.

2 Mails in Sympa

2.1 Mail workflow

Let's play with daemons. Stop all sympa daemons

/etc/init.d/sympa stop

In another terminal, start a tail on the Sympa logs:

tail -f /var/log/sympa/sympa

Subscribe an address that won't work to your list. For example: pipo@pipo.pipo

Send a message to the list. Check the “msg” spool. Your message is there:

ls -al /var/spool/sympa/msg

Start the daemon.


Look a the msg spool. The message must have disappeared.

Look at the logs. The message was processed. A notification to the editors was sent to accept/reject the message.

Check your inbox. You have received the notification. Accept the message to be sent.

Check the outgoing spool, your message is there:

ls -al /var/spool/sympa/outgoing

Check the database: Inthe “bulkspool_table” table, you will find the message (the body was encoded in base 64). the expdition packets are located in the “bulkmailer_table” table.

Start the daemon:


The message is distributed. the logs show that the message is distributed. It disappears from the bulkmailer_table. It is still in the bulkspool_table (it will be later deleted by the Sympa task manager).



The message is archived (it is written in the logs) and disappears from the outgoing spool. Click the “Archive” link in the list menu to see your archived message.

Check the bounce spool:

ls -ltr /var/spool/sympa/bounce

You should find the bounce for the dummy address you subscribed before.

Start the logs show that the bounce is handled. It disappears from the bounce spool. Click “Admin

> bounces" in the web interface. the dummy address appears in the list of addresses.

Tip: Sometimes, one of the Sympa processes can crash. This is because, in the wild landscape of SMTP, you can meet some very weird beasts sometimes. Anyway, if the Sympa process crash you have probably no logs explaining it. It is possible to retrieve informations in the tmp spool. Indeed, anytime a Sympa process is started, it creates a file named <pid>.stderr (where <pid> is its process number). It writes standard error messages to this file. so the last line in this file is probably the reason why your process crashed. Copy this line and send it to the support lists.

Check it with the commands:

ps -ef | grep sympa
ls -ltr /home/sympa/spool/tmp

2.2 Reception modes

Note : Whatever option is selected by the subscriber, Sympa will never modify a S/MIME signed message.

You can use two parameters to control the size of the message sent to subscribers:

Préparer pièces jointes

2.3 Loop prevention

Sympa contains builtin mechanisms to prevent messenging loops. One of the tested parameters is the Message-Id header. You can test it simply::

2.4 Send a web page to a list

Sympa can download the full content of a web page and convert it to a multipart/related message to send to the list. This format decreases the risk for the HTML message to be tagged as spam.

In the list menu, click on “Post > Send an HTML page”.

Type an URL in the field titled “Send the page from the following URL:”. Type a subject, then click on “Send to selected receipient”.

In the message sent to the list, you can see that Sympa included all the images to the message body.

2.5 Alias

Read the alis file and watch the aliases created for the new list.

geany /etc/mail/sympa_aliases

This alias file is created from the /home/sympa/default/list_aliases.tt2 template.

Whent you mus rename a list, Sympa can do all the work for you. Go to the “Admin” section of the list. In the “drastic operations” section, click on “Rename the list”. You just have then to type the new name of the list in the page that is displayed. All aliases are updated to conform to the new list name, the archives are renamed, the databasee and the subscribers updated, etc.

Please note that you can through the same “REname list” interafce, move a list from a virtual host to another, provided it is hosted by the same Sympa instance.

If you want the old list address to keep working, you can define a redirection file.

Rename a list through the web interface. Say its former nam was “oldname” and the new one “newname”.

geany /etc/mail/alias_redirections &

Add the following files to this new file:

oldname: newname
oldname-request: newname-request
oldname-owner: newname-owner
oldname-subscribe: newname-subscribe
oldname-unsubscribe: newname-unsubscribe 

Tthen run:


In the /etc/mail/ file, find the following line:

define(`ALIAS_FILE', `/etc/aliases,/etc/mail/sympa_aliases')dnl 

Change this line to:

define(`ALIAS_FILE', `/etc/aliases,/etc/mail/sympa_aliases,/etc/mail/alias_redirections')dnl 

Then run:

make ;
/etc/init.d/sendmail restart ;

Send a mail to the old address. It arrives to the new one.

2.6 Messenging parameters

To handle the ougoing flow of message, You can define the number of processes. The more you run, the quicker you process a large number of messages, particularly when outgoing sessions are slow.

Create a source file of email addresses from the same domain:

for i in $(seq 1 1000) ; do echo "pipo+$i@lists.domain.tld" ; done > /home/sympa/includes/enormeliste.incl

Configure your MTA to send all messages sent to these addresses to /dev/null:

geany /etc/aliases
pipo+*: "| cat > /dev/null"

In a list, change the configuration to include this file to the subscribers' list (the other data sources are fully covered later). Go to “Admin

> Edit list config > Data sources setup". Then fill the path to the datasource file in the "File inclusion" field and save.

Run a tail that selects bulk logs:

tail -f /var/log/sympa | grep bulk | grep sending

Send a message to the list.

In the logs, you'll find an entry beginning with « Start sending message... », then a last with « Done sending message ».

The gap between the “Start sending...” and the “Done sending...” gives the distribution time.

Edit the Sympa config:

geany /etc/sympa.conf&

Add the following line:

bulk_max_count 10

Restart Sympa:

/etc/init.d/sympa restart

Repeat the previous sending and note the difference of time.

The number of processes is not the only way to change the distribution performance.

In sympa.conf, you can play with two other parameters:

Add the following lines in sympa.conf:

maxsmtp 100

nrcpt 500

Replay the mail sending and note the difference.

These two parameters are useful but must be used carefully:

Some domains (yahoo and gmail for example) reject sessions with two many receipients. You can tweak the number of receipients for some domains diffrently from the main sympa.conf nrcpt parameter. This donee through the nrcpt_by_domain.conf file.

geany /home/sympa/etc/nrcpt_by_domain.conf &

Add this line:

lists.domain.tld 3

Replay the message sending and note the difference.

Finally, a last parameter is used to set tha maximum number of different domains that Sympa will use within a single sendmail call: avg.

2.7 Bounce management

2.7.1 Bounce score

Sympa handles bounces automatically. It affects a score to bouncers. This score is used to sort bouncing addresses in three classes, corresponding to their position regarding two thresholds:

The level 1 and 2 are defined by two list parameters: “bouncer_level_1” and “bouncers_level_2” (“Admin

> Edit list config > Bounces"). For each of these parameters, you can define three values:


he bounce score computation is based on three factors:

The bounce score computing is done according to the following formula:

Score = bounce_count * typ_rate * regularity_rate

To avoid to compute score prematurary, Sympa start computing a score only if:

If an address stops generating bounces, its bounce socre starts decreasing after a period of time deinfed by the expire_bounce parameter (10 days by default).

2.7.2 VERP

Variable enveloppe return path. When used, this feature encodes the original receipient address in the message Return-Path header. Indeed, some bounces don't mention it (for example, if the receipient address is redirected to another mailbox).

Any mail sent to an address which generated a bounce previously is automatically sent in VERP.

VERP is costly: Any message sent is VERP is customized (the Return-Path header is changed). It then requires an SMTP session of its own (it therefore impossible to group messages in VERP addressed to a single domain).

You can tweak the VERP rater throught the “verp_rate” parameter in the list config. This parameter's default value if the sympa.conf verp_rate parameter, whose default value is 0%.

2.8 Mail tracking

You take MDN and DSN into account to track the mail delivey status of each receipient for a message.

In a list config, set the “tracking_feature” parameter to “on”.

Send a message to the list.

In the logs, you will see messages related to handling of delivery status notifications.

Go the list archives: Once the message is archived, consult it. You'll see a “Tracking” button. By clicking it, you'll find a table relating the distribution staus for each receipient.

2.9 SMIME,

Sympa can handle messages signed and encrypted with S/MIME. Unfortunately, we need list certificate to properly test it, whose generation process is too long to experiment it during this workshop. Please consult the Sympa manual to get all details regarding S/MIME.

3 Sympa interfaces

3.1 Command line is not only the main Sympa daemon. It can be run as a command line tool. All options can be get by running: --help

You can, for example, create liast using the command line. This functionnality is especially useful to instantiate list families.

3.2 Mail

Sympa users can execute basic list manipulations using mails. These mails must be sent to the Sympa robot (by default sympa@lists.domain.tld).

The most common usage is message acceptance or rejection through mail commands; The full command list is documented in the Sympa online help. This usage tends to decrease over time, gradually replaced by the web interface.

3.3 Web

You know this interface better now.

You can customize it using two ways:

Change the web interface colors by Going to “Sympa Admin

> Skins, CSS and colors".

There you can select colors for categories of objects. You can apply these colors to your session only and, once you're satisfied with the result, extend them to the full server by clickng on “Install my session colors in a new static CSS”.

After you have done this, check that a new CSS has been created in /home/sympa/static_content/css. A new “style.css” has been created.

The web interface is generated using TT2 templates at each HTTP request. You will se further how to customize the web interface by modifying the web templates.

3.4 SOAP

Sympa proposes a web service through a SOAP interface.

In order for an user to manipulate Sympa through another application, it must send credentials on behalf of the user.

The most common case (which is not the only one) is to establish a trust relationship between the two applications. This workshop does not offer enough time to cover this aspect of Symps. Please consult the Sympa manual to learn more about this interface.

4 Authorization

For most end user actions, privileges are attributed by coputing athorization scenarios. Sending a message to a list, review the subscribers list, browse the archives and so on are all actions controled by authorization scenarios.

The following items is the exhaustive list of list or server parameters whosee value corresponds to an authorization scenario :

Practically speaking, a scenario is a file located in the relevant “scenari” directory:

All the default scenarios distributed in Sympa can be found in /home/sympa/default/scenari/.

You can then customize scenarios by copying them to the relevant location:

If, in the lsit config, the “send” parameter has the value “private”, it means that whenever somebody wants to send a message to the list, the scenario evaluated will be the one located in a “send.private” file. When processing the message, Sympa wil first look in the lsit directory, then in the virtual host directory (if any) the in the main config, and then in the default directory.

A scenario has always the same structure. It is one or more line all built following the scheme below:

<test>     <authentication method>   ->   <action>

A test perform operations on variables and then return true or false. For example, the test “is_subscriber(<email

>,<listname>)" returns true if the email address corresponding to <email> is subscribed to the list named <listname>.

An authentication method is one of the four methods usable to assess the authenticity of the user attempting to perform an operation. They correspond to different realities depending on the context:

Method Mail contextWeb context
smtpThe value of the “From” field in the messageNot usable in this context
smimeThe email is S/MIME signedAn X509 is installed in the web browser
md5A MD5 hash located was present in the mail subject (used for mail commands)The user authenticated to the web interface
dkimThe email is DKIM signed not usable in this context

The action is what Sympa must do if the test is actually performed (because we are in position to evaluate the user authenticity using the specified authentication method) AND the test returns true. If the action is “do_it”, then the requested operation is performed (the mail is sent to the list, the user can browse the subscribers, lst, etc.). If the action is “reject”, the operation is forbidden (the mail is rejected, the review page is a blank page, etc.). The action can take other values which can be either moderation (the operation will be executed if an owner, an editor or the listmaster gives her explicit approval) or authentication verification (a challenge email is requested, the user must authenticate to the web interface, etc.)

There is no limit to the number of lines a scenario can contain. They are evaluated one at a time, from top to bottom. As soon as a rule is verified, Sympa applies the action and stops evaluating the scenario.

Scenario example: (send.private_smime) :

is_subscriber([listname],[sender]) smime -> do_it # The message will be sent to the list if the user is subscribed AND his mail is signed
is_editor([listname],[sender]) smime -> do_it # The message will be sent to the list if the user is a list editor AND his mail is signed
is_owner([listname],[sender]) smime -> do_it # The message will be sent to the list if the user is a list owner AND his mail is signed

true() smtp,dkim,md5,smime -> reject(reason='send_subscriber_smime') # For any other authentication method, the message is rejected and she receives a service message informing her that she MUST sign her messages.

A short practice run:

Say you have two lists, cleverly named A and B. Using the scenario documentation (, create a scenario that forbids users subscribed to A to post a message to B using the web interface.

Scenarios inclusion

You can include a scenario in anohter one usgin the following line:

include <general>

Sympa will then include all the rules contained in the scenario called ”<general

>.include" at the position where the "include" line appears in the including scenario. This is usefull if you have rules that must appear in moore than one scenario and that are likely to change.

It is also possible to implicitely include a scenario at the beginning of all the scenarios of a class (for example, all the “send” scenarios).

such an implicitely included scenario must have a name respecting the following syntax:

include.<scenario class>.header

The rules that such a scenario contain will be appended at the beginning of any scenario of the same class at the same level or below (virtual host or server, depneding on where it is located).

An application of this method can be spam management. Antispam softwares tag messages as spams in the subject or using headers.

Another little practice run:

Suppose you have an antispam software that tag spam using a header called “Antispam-Tag”. If a message is a spam, it contains the following header:

Antispam-Tag: Yes

Create an implicitely included scenario that will automatically moderate spams for the whole server.

Test your scenario using the following method:

5 Data sources for list subscribers

Sympa is aimed at information system integration. It can threfore provision subscribers from a variety of external data sourceS.

You already experimetend inclusion from a flat file sooner in the workshop.

Here is the exhaustive list of available data sources:

Create a table of dummy addresses

echo "CONNECT sympa;" > /tmp/dummy_creation
echo 'CREATE TABLE dummy_emails (email varchar(100)) ENGINE=MyISAM;' >> /tmp/dummy_creation
for i in $(seq 1 100) ; do echo "INSERT INTO dummy_emails VALUES ('pipo+$i@lists.domain.tld');" >> /tmp/dummy_creation; done
mysql -u user_name -p < /tmp/dummy_creation

Edit the config of the list you used previously to include a file and add the following paragraph (this can also be done through the web interface):

db_name sympa
db_type mysql
host localhost
user user_name
passwd user_password
sql_query SELECT email FROM dummy_emails

Save and close the config.

Review the list memebers. A mesasge appears to inform you that the list was updated with your data source.

In the review page, the “Sources” column shows several sources: the file and the SQL source.

The subscribers' list is updated on the fly on several occasions:

You can also force the synchronization by deleting the sync_include task in the task spool. It will be immediately recreated and executed at the next task_manager loop.

cd /home/sympa/spool/task/
rm -f $(find . -E -regex /sync_include.....) ; tail – f /var/log/sympa

You see the messages related to task creation and execution in the logs.

ls -ltr

The tasks have been recreated.

You can also click the “Synchronize list members” button in the review page.


The exclusion is a mechanism that allows to unsubscribe an address that have been included through an external data source. Practically speaking, Sympa simply adds the address to a table in its database (exclude_table). The email addresses contained inthis table are simply ignored when the list is synchronized.

There is no parameter to activate / deactivate the exclusion. It is always possible, as soon as it is possible, according to the authorization scenarios, to remove a user from the list (either by a “del” or an “unsusbscribe” operation).

Including owners / editors

Owners and editors can be included using the same data source as suscribers. The configuration is slightly different, though.

Owners/editors work this way: Instead of writing a paragraph directly in the list config, you write this paragraph in a separate file. This file is then referenced in the list config file. Don't see any malevolence here. This is simply a way to factorize oftenly used data sources. Indeed, the owner_include and editor_include parameters used to defined data sources accept a field called “source_parameters” containing a comma-separated list of values which are interpreted as variables to change the actual datasource paragraph. That doesn't look crystal clear? Have a look below:

Create a datasource file:

mkdir /home/sympa/etc/data_sources
chown sympa:sympa /home/sympa/etc/data_sources
geany /home/sympa/etc/data_sources/my_owners.incl

Add the following paragraph to the file:

db_type mysql
host localhost
user user_name
passwd user_password
db_name sympa
sql_query SELECT DISTINCT email FROM dummy_emails WHERE email LIKE 'pipo+[%param.0%]%'

Save and close

In the list config, add the following paragraph:

source my_owners
source_parameters 9
reception mail
profile privileged

Save and close. Go to see the list in the web interface. You can see that list of owners has changed. If you change the parameter value, the owners change. You can reuse the “my_owners.incl” file in another list with a different parameter.

Yes another practice run: Go back to your beloved “A” and “B” lists. Configure list A in order that its owners are the owners of list B.

6 Sympa customization

Sympa is a flexible tool. A lot of elements can be customized. Well, sometimes, too many: it can be overwhelming for beginners. but experienced listmasters can take advantage of these customizations to build a simpler life.

6.1 A few parameters

Custom attributes

In the list config, you can define user attributes beyond the email address.

Go to the web interface. Click on “Edit list config

> Miscellaneous". At the very bottom og the page, you can find the "custom\_parameter" parameter.

It contains the following fields:

Ce paramètre contient les champs suivants :

When you define a custom_parameter, the user is presented a form when subscribing. If the custom_parameter is “required”, the user can't subscribe without providing a valid value for the parameter.

The value provided by the user is displayed in the review page. It is alos available in templates under the following syntax:

[% user.custom_attribute.<id>.value %]

Note: in the coming 6.2 version, custom_attributes can be provisionned fomr LDAP and SQL.

Custom list parameters

It is possible to create a list parameter not existent in the sympa code. It is a simple key/value pair. You define the name and the value of the custom parameter in a single list parameter: “custom_var”.

In the list config file, add the following lines:

  name var_name
  value var_value

You can then use this var in a scenario uder the syntax:


You can alos use it in mail and web temlates (in list context only) under the syntax:

[% custom_vars.var_name %]

Custom actions

You can define new actions in the Sympa weeb interface. These are new pages in the web interface, corresponding to URL that you define, totally integrated in the rest of the web interface.

Create a template bearing the name of you custom action:

mkdir /home/sympa/etc/web_tt2
chown sympa:sympa /home/sympa/etc/web_tt2
geany /home/sympa/etc/web_tt2/action_test.tt2&

Copy the following content in the editor:

<h2>A test action</h2>
[% IF list %]
<p>liste: [% list %]</p>
[% END %]
<p>Custom action name: [% custom_action %]</p>
[% FOREACH param=cap %]
<li><b>[% param %]</b></li>
[% END%]

Display your custom action by going to:


You can also define list custom actions. these are the same thing as above, except that you can use the whole list configuration in these actions.

Copy your model in a list directory

mkdir /home/sympa/list_data/lists.domain.tld/<listname>/web_tt2
chown sympa:sympa /home/sympa/list_data/lists.domain.tld/<listname>/web_tt2
cp -p /home/sympa/etc/web_tt2/action_test.tt2 /home/sympa/list_data/lists.domain.tld/<listname>/web_tt2

Display your custom action by going to: http://lists.domain.tld/sympa/lca/action_test/<listname>/param1/param2/param3

6.2 The TT2 language

The TT2 (for “Template toolkit”) language is a mini-language, exclusive to the perl language, which allows to define dynamic content.

All the dynamic content in Sympa (except the scenarios which use a home-made dialect) are done using TT2:

Here are a few examples of the language:

Define a variable:

[% SET toto = 3 %]

You can use tests:

[% IF age < 10 %]

Hello [% name %], does your mother know you're 

using her AOL account?

[% ELSIF age < 18 %]

Sorry, you're not old enough to enter 

(and too dumb to lie about your age)

[% ELSE %]
Welcome [% name %].

[% END %]

[% UNLESS text_mode %]

[% INCLUDE biglogo %]

[% END %]

You can use loops:

[% FOREACH thing IN [ foo 'Bar' "$foo Baz" ] %]

* [% thing %]

[% END %]

For risky tests, you can handle exceptions. for example, if you want to open a file that your a not sure to find, you could use such a sequence:

[% TRY %]

[% INCLUDE myfile %]

<div>The file is here!</div>

[% CATCH file %]

<div>File was not found!</div> [% %]

[% CATCH %]

<div>An error was encountered.</div>

[% END %]

6.3 Customizable elements (mail, web, scenarios, etc.)

Before any customization, it is vital to copy the file from the default location you found it to the relevant directory: etc, etc/<virtual_host

> or list_data.


ndeed: any file in default will be overwrittent at the next Sympa update.

7 Practices (if we have enough time)


DKIM means “domain key identified mail”. It allows for a mail domain to certify that a mail was actually emited by this domain. It is done through a messages signature by the mail server.

Sympa can use DKIM through three ways:

To enable DKIM in Sympa:

geany /etc/sympa.conf&


dkim_feature on

Modify a send scenario. The first line will reject any mail sent with a DKIM signature, the second one will accept mails with other authentication mechanisms.

If you can, send a mail to this list with a domain using DKIM, and another from a domain which doesn't.

Fixing DKIM in Sympa 6.1.17

In 6.1.17 DKIM support is broken because of a bad configuration parameter processing, to fix that you must open the /home/sympa/bin/ and go to line 270, original code looks like :

    ## Some parameters require CPAN modules
    if ($Conf{'DKIM_feature'} eq 'on') {
        eval "require Mail::DKIM";
        if ($@) {
            &do_log('err', "Failed to load Mail::DKIM perl module ; setting 'DKIM_feature' to 'off'");
            $Conf{'DKIM_feature'} = 'off';
    unless ($Conf{'DKIM_feature'} eq 'on'){
    # dkim_signature_apply_ on nothing if DKIM_feature is off
    $Conf{'dkim_signature_apply_on'} = ['']; # empty array

DKIM_feature must become dkim_feature :

    ## Some parameters require CPAN modules
    if ($Conf{'dkim_feature'} eq 'on') {
        eval "require Mail::DKIM";
        if ($@) {
            &do_log('err', "Failed to load Mail::DKIM perl module ; setting 'dkim_feature' to 'off'");
            $Conf{'dkim_feature'} = 'off';
    unless ($Conf{'dkim_feature'} eq 'on'){
    # dkim_signature_apply_ on nothing if dkim_feature is off
    $Conf{'dkim_signature_apply_on'} = ['']; # empty array

You must then restart Sympa and Apache.

Sign with DKIM

For Sympa to sign with DKIM, the DNS must be adapted.

For the workshop, the DKIM-related DNS reecords have been made already. The have the form:

<selector>._domainkey.lists.domain.tld. IN TXT "v=DKIM1; g=*; k=rsa; t=y; p=<public key>"

_adsp._domainkey.lists.domain.tld.    IN    TXT    "dkim=unknown"


> must have the same values as the "dkim\_selector" parameter. In this workshop, it has the value "lists".

Here are the DKIM-related parameters:

parameter (sympa.conf or robot.conf) default overridden by (list context)
dkim_feature off N/A
dkim_add_signature_to list,robot N/A
doc/formation/sympa_workshop_support.txt · Last modified: 2017/09/07 13:22 by
Show pagesource
Back to top

The Sympa software is provided by RENATER
Faq | News | Contact | Legal Notices