Table of Contents
Mail aliases are required in Sympa for
sympa.plto 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
smrsh.# 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/smrshdirectory. Therefore you will have to tell Sympa that binaries should be installed in the
/etc/smrshdirectory. This can be performed via the
–with-bindiroption of sympa’s
An electronic list manager such as Sympa is built around two processing steps.
- A message sent to a list or to Sympa itself (commands such as subscribe or unsubscribe) is received by the SMTP server. When receiving the message, the SMTP server runs the
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
sendmailalias file (often
/etc/aliases).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
Note: If you run Sympa virtual hosts, you will need one
sympaalias entry per virtual host (see Virtual host).
sympa-requestshould be the address of the robot administrator, i.e. a person who manages Sympa (here
sympa-owneris 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
remind_return_path uniqueor the
verp_rateparameter is not null for at least one list.
abuse-feedback-reportis 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
newaliasesafter 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
majordomonames. 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
mylistlist, 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-requestshould correspond to the person responsible for managing
mylist(the owner). Sympa will forward messages sent to
mylist-requestto the owner of
mylist, as defined in the
/home/sympa/list_data/mylist/configfile. Using this feature means you will not need to modify the alias file if the list owner were to change.
Similarly, the address
mylist-editorcan be used to contact the list editors, if defined in
/home/sympa/list_data/mylist/config. This address definition is not compulsory.
mylist-owneris the address receiving non-delivery reports (note that the
-ownersuffix can be customized, see return path suffix. The
bouncequeueprogram stores these messages in the
queuebouncedirectory. WWSympa may then analyze them and provide a web access to them.
mylist-subscribeis 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-unsubscribeis 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.plscript 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.plfor example), you should edit the
alias_managersympa.conf parameter (see alias_manager).
The script expects the following arguments :
Example:/home/sympa/bin/alias_manager.pl add mylist cru.fr
/home/sympa/bin/alias_manager.plworks on the alias file as defined in
sendmail_aliasesvariable (default is
/etc/mail/sympa_aliases, inherited from
You must refer to this aliases file in your
sendmail.mc(if using sendmail):define(`ALIAS_FILE', `/etc/aliases,/etc/mail/sympa_aliases')dnl
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.dbas the sympa user.
sendmailhas requirements regarding the ownership and rights on both
sympa_aliases.dbfiles (the later being created by sendmail via the
newaliasescommand). 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.
aliaswrapper), after any changes to aliases file. With Postfix,
newaliaseswill create the alias file databases given with
alias_databaseand 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_aliasestemplate 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
Ludovic Marcotte has written a version of
ldap_alias_manager.plthat 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 the right-hand side of a
/etc/aliasesentry. 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.regexpfile as follows:/^(.*)@my.domain.org$/ my.domain.org-$1
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 :
- incoming messages are spooled with a file name (and a X-Sympa-To SMTP header) that corresponds to the
queueprogram parameter defined in the mail aliases ;
- when processed by the
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
queueprogram in mail aliases corresponds to the
domainconfiguration parameter of the virtual host.