Mail aliases are required in Sympa for
sympa.pl to receive mail commands and list messages. Management of these aliases will depend on the MTA (
exim) you are using, where you store aliases and whether you are managing virtual domains or not.
sendmail, maybe it is configured to use the secured shell
# grep smrsh /etc/mail/sendmail.mc FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
Smrsh obliges you to copy all the programs that are called from the mail aliases into the dedicated
/etc/smrsh directory. Therefore you will have to tell Sympa that binaries should be installed in the
/etc/smrsh directory. This can be performed via the
–with-smrshdir option of sympa’s
An electronic list manager such as Sympa is built around two processing steps.
queueprogram (supplied in this package) to store the message in a spool.
sympa.pldaemon, set in motion at system startup, scans this spool. As soon as it detects a new message, it processes it and performs the requested action (distribution or processing of a command).
To separate the processing of commands (subscription, unsubscription, help requests, etc.) from the processing of messages destined to mailing lists, a special mail alias is reserved for administrative requests, so that Sympa can be permanently accessible to users. The following lines must therefore be added to the
sendmail alias file (often
sympa: "| /home/sympa/bin/queue firstname.lastname@example.org" listmaster: "| /home/sympa/bin/queue email@example.com" bounce+*: "| /home/sympa/bin/bouncequeue firstname.lastname@example.org" abuse-feedback-report: "| /home/sympa/bin/bouncequeue email@example.com" sympa-request: postmaster sympa-owner: postmaster
sympaalias entry per virtual host (see Virtual host).
sympa-request should be the address of the robot administrator, i.e. a person who manages Sympa (here
sympa-owner is the return address for Sympa error messages.
The alias bounce+* is dedicated to collect bounces where VERP (variable envelope return path) was active. It is useful if
welcome_return_path unique or
remind_return_path unique or the
verp_rate parameter is not null for at least one list.
abuse-feedback-report is used for processing automatically feedback that respect ARF format (Abuse Report Feedback), which is a draft to specify how end users can complain about spam. It is mainly used by AOL.
Don not forget to run
newaliases after any change to the
Note: Aliases based on
listserv (in addition to those based on
sympa) can be added for the benefit of users accustomed to the
majordomo names. For example:
listserv: sympa listserv-request: sympa-request majordomo: sympa listserv-owner: sympa-owner
For each new list, it is necessary to create up to six mail aliases (at least three). If you managed to setup the alias manager (see Alias manager), then Sympa will install automatically the following aliases for you.
For example, to create the
mylist list, the following aliases must be added:
mylist: |/home/sympa/bin/queue firstname.lastname@example.org mylist-request: |/home/sympa/bin/queue email@example.com mylist-editor: |/home/sympa/bin/queue firstname.lastname@example.org mylist-owner: |/home/sympa/bin/bouncequeue email@example.com mylist-subscribe: |/home/sympa/bin/queue firstname.lastname@example.org mylist-unsubscribe: |/home/sympa/bin/queue email@example.com
mylist-request should correspond to the person responsible for managing
mylist (the owner). Sympa will forward messages sent to
mylist-request to the owner of
mylist, as defined in the
/home/sympa/list_data/mylist/config file. Using this feature means you will not need to modify the alias file if the list owner were to change.
Similarly, the address
mylist-editor can be used to contact the list editors, if defined in
/home/sympa/list_data/mylist/config. This address definition is not compulsory.
mylist-owner is the address receiving non-delivery reports (note that the
-owner suffix can be customized, see return path suffix. The
bouncequeue program stores these messages in the
queuebounce directory. WWSympa may then analyze them and provide a web access to them.
mylist-subscribe is an address enabling users to subscribe in a manner which can easily be explained to them. Beware: subscribing this way is so straightforward that you may find spammers subscribing to your list by accident.
mylist-unsubscribe is the equivalent for unsubscribing. By the way, the easier it is for users to unsubscribe, the easier it will be for you to manage your list!
alias_manager.pl script does aliases management. It is run by WWSympa and will install aliases for a new list and delete aliases for closed lists. To use a different alias management tool (
ldap_alias_manager.pl for example), you should edit the
alias_manager sympa.conf parameter (see alias_manager).
The script expects the following arguments :
/home/sympa/bin/alias_manager.pl add mylist renater.fr
/home/sympa/bin/alias_manager.pl works on the alias file as defined in
sympa.conf with the
sendmail_aliases variable (default is
/etc/mail/sympa_aliases, inherited from
You must refer to this aliases file in your
sendmail.mc (if using sendmail):
If using postfix: edit /etc/postfix/main.cf:
alias_maps = hash:/etc/aliases,hash:/etc/mail/sympa_aliases alias_database = hash:/etc/aliases,hash:/etc/mail/sympa_aliases
and chown the files
/etc/mail/sympa_aliases.db as the sympa user.
sendmail has requirements regarding the ownership and rights on both
sympa_aliases.db files (the later being created by sendmail via the
newaliases command). Anyhow, these two files should be located in a directory, every path component of which being owned by and writable only by the root user.
/home/sympa/bin/alias_manager.pl runs a command
sympa_newaliases-wrapper), after any changes to aliases file. With Postfix,
newaliases will create the alias file databases given with
alias_database and uses all the aliases given with
alias_maps – this is why above we add two lines into
If you manage virtual domains with your mail server, then you might want to change the form of aliases used by the alias manager. You can customize the
list_aliases template that is parsed to generate list aliases (see list_aliases.tt2).
Note that you do not need alias management if you use MTA functionalities such as Postfix'
virtual_transport. Then you can disable alias management in Sympa by positioning the
sendmail_aliases parameter to
Ludovic Marcotte has written a version of
ldap_alias_manager.pl that is LDAP enabled. This script is distributed with Sympa distribution. The script has later been extended by Philippe Baumgart, British Telecom. You can customize the LDAP parameteres via the
When using virtual domains with
postfix, you can not refer to
firstname.lastname@example.org on the right-hand side of a
/etc/aliases entry. You need to define an additional entry in a virtual table. You can also add a unique entry, with a regular expression, for your domain.
With Postfix, you should edit the
/etc/postfix/virtual.regexp file as follows:
Entries in the 'aliases' file will look like this:
my.domain.org-sympa: /home/sympa/bin/queue email@example.com ..... my.domain.org-listA: /home/sympa/bin/queue listA@my.domain.org
With Sendmail, add the following entry to
If your Sympa server does virtual hosting, then it needs to perform mail routing internally. Here is how mail routing is handled :
queueprogram parameter defined in the mail aliases ;
sympa.plprocess, Sympa determines the current virtual host by comparing the domain part of the file name with the
domainparameter defined in the
sympa.confor in the
robot.conffiles of each virtual host.
Therefore you should ensure that the domain used as a parameter to the
queue program in mail aliases corresponds to the
domain configuration parameter of the virtual host.