Next: 15. Shared documents Up: Sympa Mailing Lists Management Software version Previous: 13. Creating and editing mailing using Contents Index
Subsections

- 14.1 List description
  - 14.1.1 editor
  - 14.1.2 host
  - 14.1.3 lang
  - 14.1.4 owner
  - 14.1.5 subject
  - 14.1.6 topics
  - 14.1.7 visibility
- 14.2 Data source related
  - 14.2.1 user_data_source
  - 14.2.2 ttl
  - 14.2.3 include_list
  - 14.2.4 include_remote_sympa_list
  - 14.2.5 include_sql_query
  - 14.2.6 include_ldap_query
  - 14.2.7 include_ldap_2level_query
  - 14.2.8 include_file
- 14.3 Command related
  - 14.3.1 subscribe
  - 14.3.2 unsubscribe
  - 14.3.3 add
  - 14.3.4 del
  - 14.3.5 remind
  - 14.3.6 remind_task
  - 14.3.7 expire_task
  - 14.3.8 send
  - 14.3.9 review
  - 14.3.10 shared_doc
- 14.4 List tuning
  - 14.4.1 reply_to_header
  - 14.4.2 max_size
  - 14.4.3 anonymous_sender
  - 14.4.4 custom_header
  - 14.4.5 custom_subject
  - 14.4.6 footer_type
  - 14.4.7 digest
  - 14.4.8 available_user_options
  - 14.4.9 default_user_options
  - 14.4.10 cookie
  - 14.4.11 priority
- 14.5 Bounce related
  - 14.5.1 bounce
  - 14.5.2 bouncers_level1
  - 14.5.3 bouncers_level2
  - 14.5.4 welcome_return_path
  - 14.5.5 remind_return_path
- 14.6 Archive related
  - 14.6.1 archive
  - 14.6.2 web_archive
  - 14.6.3 archive_crypted_msg
- 14.7 Spam protection
  - 14.7.1 spam_protection
  - 14.7.2 web_archive_spam_protection

#
14. List configuration parameters

The configuration file is composed of paragraphs separated by blank lines and introduced by a keyword.

Even though there are a very large number of possible parameters, the minimal list definition is very short. The only required parameters are `owner` and `subject`. All other parameters have a default value.

> keyword value

WARNING: configuration parameters must be separated by blank lines and BLANK LINES ONLY !

# 14.1 List description

##
14.1.1 editor

The `config` file contains one `editor` paragraph per moderator (or editor).

Example:

    editor
    email Pierre.David@prism.uvsq.fr
    gecos Pierre (Universite de Versailles St Quentin)

Only the editor of a list is authorized to send messages to the list when the `send` parameter (see 14.3.8, page ) is set to either `editor`, `editorkey`, or `editorkeyonly`. The `editor` parameter is also consulted in certain other cases ( `privateoreditorkey` ).

The syntax of this directive is the same as that of the `owner` parameter (see 14.1.4, page ), even when several moderators are defined.

##
14.1.2 host

(Default value: ``domain` robot parameter`)

`host` fully-qualified-domain-name

Domain name of the list, default is the robot domain name set in the related `robot.conf` file or in file `/etc/sympa.conf`.

##
14.1.3 lang

(Default value: ``lang` robot parameter`)

Example:

    lang cn-big5

This parameter defines the language used for the list. It is used to initialize a user's language preference ; Sympa command reports are extracted from the associated message catalog.

See 11.6, page for available languages.

##
14.1.4 owner

The `config` file contains one `owner` paragraph per owner.

Example:

    owner
    email serge.aumont@cru.fr
    gecos C.R.U.
    info Tel: 02 99 76 45 34
    reception nomail

The list owner is usually the person who has the authorization to send `ADD` (see 20.2, page ) and `DELETE` (see 20.2, page ) commands on behalf of other users.

When the `subscribe` parameter (see 14.3.1, page ) specifies a restricted list, it is the owner who has the exclusive right to subscribe users, and it is therefore to the owner that `SUBSCRIBE` requests will be forwarded.

There may be several owners of a single list; in this case, each owner is declared in a paragraph starting with the `owner` keyword.

The `owner` directive is followed by one or several lines giving details regarding the owner's characteristics:

- `email` address

  Owner's e-mail address

- `reception nomail`

  Optional attribute for an owner who does not wish to receive mails. Useful to define an owner with multiple e-mail addresses: they are all recognized when Sympa receives mail, but thanks to `reception nomail`, not all of these addresses need receive administrative mail from Sympa.

- `gecos` data

  Public information on the owner

- `info` data

  Available since release 2.3

  Private information on the owner

- `profile` `privileged` `|` `normal`

  Available since release 2.3.5

  Profile of the owner. This is currently used to restrict access to some features of WWSympa, such as adding new owners to a list.

##
14.1.5 subject

`subject` subject-of-the-list

This parameter indicates the subject of the list, which is sent in response to the `LISTS` mail command. The subject is a free form text limited to one line.

##
14.1.6 topics

`topics` computing/internet,education/university

This parameter allows the classification of lists. You may define multiple topics as well as hierarchical ones. WWSympa's list of public lists uses this parameter.

##
14.1.7 visibility

(Default value: `conceal`)

`visibility` parameter is defined by an authorization scenario (see 9, page )

This parameter indicates whether the list should feature in the output generated in response to a `LISTS` command.

- `visibility` `conceal` (view)
  conceal except for subscribers

- `visibility` `intranet` (view)
  intranet access

- `visibility` `noconceal` (view)
  no conceal

- `visibility` `private` (view)
  subscribers

- `visibility` `secret` (view)
  conceal even for subscribers

# 14.2 Data source related

## 14.2.1 user_data_source

(Default value: `file|database, if using an RDBMS`)

`user_data_source` `file` `|` `database` `|` `include`

Sympa allows the mailing list manager to choose how Sympa loads subscriber data. Subscriber information can be stored in a text file or relational database, or included from various external sources (list, flat file, result of or query).

- `user_data_source` `file`

  When this value is used, subscriber data are stored in a file whose name is defined by the `subscribers` parameter in `sympa.conf`. This is maintained for backward compatibility.

- `user_data_source` `database`

  This mode was been introduced to enable data to be stored in a relational database. This can be used for instance to share subscriber data with an HTTP interface, or simply to facilitate the administration of very large mailing lists. It has been tested with MySQL, using a list of 200 000 subscribers. We strongly recommend the use of a database in place of text files. It will improve performance, and solve possible conflicts between Sympa and WWSympa. Please refer to the ¨Sympa and its databasesection (6, page ).

- `user_data_source` `include`

  Here, subscribers are not defined extensively (enumeration of their e-mail addresses) but intensively (definition of criteria subscribers must satisfy). Includes can be performed by extracting e-mail addresses using an or query, or by including other mailing lists. At least one include paragraph, defining a data source, is needed. Valid include paragraphs (see below) are `include_file`, `include_list`, `include_remote_sympa_list`, `include_sql_query` and `include_ldap_query`.

## 14.2.2 ttl

(Default value: `3600`)

`ttl` `delay_in_seconds`

Sympa caches user data extracted using the include parameter. Their TTL (time-to-live) within Sympa can be controlled using this parameter. The default value is 3600.

## 14.2.3 include_list

`include_list` `listname`

This parameter will be interpreted only if `user_data_source` is set to `include`. All subscribers of list `listname` become subscribers of the current list. You may include as many lists as required, using one `include_list` `listname` line for each included list. Any list at all may be included ; the `user_data_source` definition of the included list is irrelevant, and you may therefore include lists which are also defined by the inclusion of other lists. Be careful, however, not to include list `A` in list `B` and then list `B` in list `A`, since this will give rise an infinite loop.

## 14.2.4 include_remote_sympa_list

`include_remote_sympa_list`

Sympa can contact another Sympa service using https to fetch a remote list in order to include each member of a remote list as subscriber. You may include as many lists as required, using one `include_remote_sympa_list` paragraph for each included list. Be careful, however, not to give rise an infinite loop making cross includes.

For this operation, one Sympa site act as a server while the other one act as client. On the server side, the only setting needed is to give permition to the remote Sympa to review the list. This is controled by the review authorization scenario.

From the client side you must define the remote list dump URI.

- `remote_host` remote_host_name

- `port` port (Default 443)

- `path` absolute path (In most cases, for a list name foo /wws/dump/foo )

Because https offert a easy and secure client authentication, https is the only one protocole currently supported. A additional parameter is needed : the name of the certificate (and the private key) to be used :

- `cert` `list` the certificate to be use is the list certificate (the certificate subject distinguished name email is the list adress). Certificate and private key are located in the list directory.
- `cert` `robot` the certificate used is then related to sympa itself : the certificate subject distinguished name email look like sympa@my.domain and files are located in virtual robot etc dir if virtual robot is used otherwise in `/home/sympa/etc`.

##
14.2.5 include_sql_query

`include_sql_query`

This parameter will be interpreted only if the `user_data_source` value is set to `include`, and is used to begin a paragraph defining the SQL query parameters :

- `db_type` dbd_name

  The database type (mysql, Pg, Oracle, Sybase, CSV ...). This value identifies the PERL DataBase Driver (DBD) to be used, and is therefore case-sensitive.

- `host` hostname

  The Database Server Sympa will try to connect to.

- `db_name` sympa_db_name

  The hostname of the database system.

- `connect_options` option1=x;option2=y

  These options are appended to the connect string. This parameter is optional.

  Example :

      user_data_source include

      include_sql_query
            db_type mysql
            host sqlserv.admin.univ-x.fr
            user stduser
            passwd mysecret
            db_name studentbody
            sql_query SELECT DISTINCT email FROM student
            connect_options mysql_connect_timeout=5

  Connexion timeout is set to 5 seconds.

- `db_env` list_of_var_def

  Sets a list of environment variables to set before database connexion. This is a ';' separated list of variable assignment.

  Example for Oracle:

      db_env	ORACLE_TERM=vt100;ORACLE_HOME=/var/hote/oracle/7.3.4

- `user` user_id

  The user id to be used when connecting to the database.

- `passwd` some secret

  The user passwd for `user`.

- `sql_query` a query string The SQL query string. No fields other than e-mail addresses should be returned by this query!

Example :

    user_data_source include

    include_sql_query
          db_type oracle
          host sqlserv.admin.univ-x.fr
          user stduser
          passwd mysecret
          db_name studentbody
          sql_query SELECT DISTINCT email FROM student

##
14.2.6 include_ldap_query

`include_ldap_query`

This paragraph defines parameters for a query returning a list of subscribers. This paragraph is used only if `user_data_source` is set to `include`. This feature requires the `Net::LDAP` (perlldap) PERL module.

- `host` ldap_directory_hostname

  Name of the LDAP directory host or a comma separated list of host:port. The second form is usefull if you are using some replication ldap host.

  Example :

          host ldap.cru.fr:389,backup-ldap.cru.fr:389

- `port` ldap_directory_port (OBSOLETE)

  Port on which the Directory accepts connections.

- `user` ldap_user_name

  Username with read access to the LDAP directory.

- `passwd` LDAP_user_password

  Password for `user`.

- `suffix` directory name

  Defines the naming space covered by the search (optional, depending on the LDAP server).

- `timeout` delay_in_seconds

  Timeout when connecting the remote server.

- `filter` search_filter

  Defines the LDAP search filter (RFC 2254 compliant).

- `attrs` mail_attribute (Default value: `mail`)

  The attribute containing the e-mail address(es) in the returned object.

- `select` first `|` all (Default value: `first`)

  Defines whether to use only the first address, or all the addresses, in cases where multiple values are returned.

- `scope` base `|` one `|` sub (Default value: `sub`)

  By default the search is performed on the whole tree below the specified base object. This may be changed by specifying a scope parameter with one of the following values.

  - base : Search only the base object.

  - one : Search the entries immediately below the base object.

  - sub : Search the whole tree below the base object.

Example :

        include_ldap_query
        host ldap.cru.fr
        suffix dc=cru, dc=fr
        timeout 10
        filter (&(cn=aumont) (c=fr))
        attrs mail
        select first
        scope one

##
14.2.7 include_ldap_2level_query

`include_ldap_2level_query`

This paragraph defines parameters for a two-level query returning a list of subscribers. Usually the first-level query returns a list of DNs and the second-level queries convert the DNs into e-mail addresses. This paragraph is used only if `user_data_source` is set to `include`. This feature requires the `Net::LDAP` (perlldap) PERL module.

- `host` ldap_directory_hostname

  Name of the LDAP directory host or a comma separated list of host:port. The second form is usefull if you are using some replication ldap host.

  Example :

          host ldap.cru.fr:389,backup-ldap.cru.fr:389

- `port` ldap_directory_port (OBSOLETE)

  Port on which the Directory accepts connections (this parameter is ignored if host definition include port specification).

- `user` ldap_user_name

  Username with read access to the LDAP directory.

- `passwd` LDAP_user_password

  Password for `user`.

- `suffix1` directory name

  Defines the naming space covered by the first-level search (optional, depending on the LDAP server).

- `timeout1` delay_in_seconds

  Timeout for the first-level query when connecting to the remote server.

- `filter1` search_filter

  Defines the LDAP search filter for the first-level query (RFC 2254 compliant).

- `attrs1` attribute

  The attribute containing the data in the returned object that will be used for the second-level query. This data is referenced using the syntax ``[attrs1]''.

- `select1` first `|` all `|` regex (Default value: `first`)

  Defines whether to use only the first attribute value, all the values, or only those values matching a regular expression.

- `regex1` regular_expression (Default value: )

  The Perl regular expression to use if ``select1'' is set to ``regex''.

- `scope1` base `|` one `|` sub (Default value: `sub`)

  By default the first-level search is performed on the whole tree below the specified base object. This may be changed by specifying a scope parameter with one of the following values.

  - base : Search only the base object.

  - one : Search the entries immediately below the base object.

  - sub : Search the whole tree below the base object.

- `suffix2` directory name

  Defines the naming space covered by the second-level search (optional, depending on the LDAP server). The ``[attrs1]'' syntax may be used to substitute data from the first-level query into this parameter.

- `timeout2` delay_in_seconds

  Timeout for the second-level queries when connecting to the remote server.

- `filter2` search_filter

  Defines the LDAP search filter for the second-level queries (RFC 2254 compliant). The ``[attrs1]'' syntax may be used to substitute data from the first-level query into this parameter.

- `attrs2` mail_attribute (Default value: `mail`)

  The attribute containing the e-mail address(es) in the returned objects from the second-level queries.

- `select2` first `|` all `|` regex (Default value: `first`)

  Defines whether to use only the first address, all the addresses, or only those addresses matching a regular expression in the second-level queries.

- `regex2` regular_expression (Default value: )

  The Perl regular expression to use if ``select2'' is set to ``regex''.

- `scope2` base `|` one `|` sub (Default value: `sub`)

  By default the second-level search is performed on the whole tree below the specified base object. This may be changed by specifying a scope2 parameter with one of the following values.

  - base : Search only the base object.

  - one : Search the entries immediately below the base object.

  - sub : Search the whole tree below the base object.

Example : (cn=testgroup,dc=cru,dc=fr should be a groupOfUniqueNames here)

        include_ldap_2level_query
        host ldap.cru.fr
        suffix1 cn=testgroup, dc=cru, dc=fr
        timeout1 10
        filter1 (objectClass=*)
        attrs1 uniqueMember
        select1 all
        scope1 base
        suffix2 dc=cru, dc=fr
        timeout2 10
        filter2 (&(dn=[attrs1]) (c=fr))
        attrs2 mail
        select2 regex
        regex2 ^*@cru.fr$
        scope2 one

##
14.2.8 include_file

`include_file` `path to file`

This parameter will be interpreted only if the `user_data_source` value is set to `include`. The file should contain one e-mail address per line (lines beginning with a "#" are ignored).

# 14.3 Command related

##
14.3.1 subscribe

(Default value: `open`)

`subscribe` parameter is defined by an authorization scenario (see 9, page )

The `subscribe` parameter defines the rules for subscribing to the list. Predefined authorization scenarios are :

- `subscribe` `auth` (view)
  subscription request confirmed

- `subscribe` `auth_notify` (view)
  need authentication (notification is sent to owners)

- `subscribe` `auth_owner` (view)
  requires authentication then owner approval

- `subscribe` `closed` (view)
  subscribe is impossible

- `subscribe` `intranet` (view)
  restricted to local domain users

- `subscribe` `intranetorowner` (view)
  local domain users or owner approval

- `subscribe` `open` (view)
  for anyone without authentication

- `subscribe` `open_notify` (view)
  anyone, notification is sent to list owner

- `subscribe` `open_quiet` (view)
  anyone, no welcome message

- `subscribe` `owner` (view)
  owners approval

- `subscribe` `smime` (view)
  requires S/MIME signed

- `subscribe` `smimeorowner` (view)
  requires S/MIME signed or owner approval

##
14.3.2 unsubscribe

(Default value: `open`)

`unsubscribe` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies the unsubscription method for the list. Use `open_notify` or `auth_notify` to allow owner notification of each unsubscribe command. Predefined authorization scenarios are :

- `unsubscribe` `auth` (view)
  need authentication

- `unsubscribe` `auth_notify` (view)
  authentication requested, notification sent to owner

- `unsubscribe` `closed` (view)
  impossible

- `unsubscribe` `open` (view)
  anyone without authentication

- `unsubscribe` `open_notify` (view)
  without authentication, notification is sent to owners

- `unsubscribe` `owner` (view)
  owner approval

##
14.3.3 add

(Default value: `owner`)

`add` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who is authorized to use the `ADD` command. Predefined authorization scenarios are :

- `add` `auth` (view)
  add need authentication

- `add` `closed` (view)
  add impossible

- `add` `owner` (view)
  add performed by list owner do not need authentication

- `add` `owner_notify` (view)
  add performed by owner do not need authentication (notification)

##
14.3.4 del

(Default value: `owner`)

`del` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who is authorized to use the `DEL` command. Predefined authorization scenarios are :

- `del` `auth` (view)
  deletion performed only by list owners, need authentication

- `del` `closed` (view)
  remove subscriber impossible

- `del` `owner` (view)
  by owner without authentication

- `del` `owner_notify` (view)
  list owners, authentication not needed (notification)

##
14.3.5 remind

(Default value: `owner`)

`remind` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who is authorized to use the `remind` command. Predefined authorization scenarios are :

- `remind` `listmaster` (view)
  listmaster only

- `remind` `owner` (view)
  restricted to list owner

## 14.3.6 remind_task

(Default value: `no default value`)

This parameter states which model is used to create a `remind` task. A `remind` task regurlaly sends to the subscribers a message which reminds them their subscription to list.

example :

remind annual

## 14.3.7 expire_task

(Default value: `no default value`)

This parameter states which model is used to create a `remind` task. A `expire` task regurlaly checks the inscription or reinscription date of subscribers and asks them to renew their subscription. If they don't they are deleted.

example :

expire annual

##
14.3.8 send

(Default value: `private`)

`send` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who can send messages to the list. Valid values for this parameter are pointers to scenarios.

- `send` `closed` (view)
  closed

- `send` `editor` (view)
  Moderated, old style

- `send` `editorkey` (view)
  Moderated

- `send` `editorkeyonly` (view)
  Moderated, even for moderators

- `send` `editorkeyonlyauth` (view)
  Moderated, with editor confirmation

- `send` `intranet` (view)
  restricted to local domain

- `send` `intranetorprivate` (view)
  restricted to local domain and subscribers

- `send` `newsletter` (view)
  Newsletter, restricted to moderators

- `send` `newsletterkeyonly` (view)
  Newsletter, restricted to moderators after confirmation

- `send` `private` (view)
  restricted to subscribers

- `send` `private_or_auth` (view)
  Confirmation for non subscribers ; then moderation

- `send` `private_or_auth_and_editorkey` (view)
  Confirmation for non subscribers ; then moderation

- `send` `private_smime` (view)
  restricted to subscribers check smime signature

- `send` `privateandeditorkey` (view)
  Moderated, restricted to subscribers

- `send` `privateandnomultipartoreditorkey` (view)
  Moderated, for non subscribers sending multipart messages

- `send` `privatekey` (view)
  restricted to subscribers with previous md5 authentication

- `send` `privatekeyandeditorkeyonly` (view)
  Moderated, for subscribers and moderators

- `send` `privateoreditorkey` (view)
  Private, moderated for non subscribers

- `send` `privateorpublickey` (view)
  Private, confirmation for non subscribers

- `send` `public` (view)
  public list

- `send` `public_nobcc` (view)
  public list, Bcc rejected (anti-spam)

- `send` `publickey` (view)
  anyone with previous md5 authentication

- `send` `publicnoattachment` (view)
  public list multipart/mixed messages are forwarded to moderator

- `send` `publicnomultipart` (view)
  public list multipart messages are rejected

##
14.3.9 review

(Default value: `owner`)

`review` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who can use `REVIEW` (see 20.1, page ), administrative requests.

Predefined authorization scenarios are :

- `review` `closed` (view)
  nobody can review

- `review` `intranet` (view)
  restricted to subscribers or local domain users

- `review` `listmaster` (view)
  listmaster only

- `review` `owner` (view)
  only owner (and listmaster)

- `review` `private` (view)
  restricted to subscribers

- `review` `public` (view)
  anyone can do it !

##
14.3.10 shared_doc

This paragraph defines read and edit access to the shared document repository.

### 14.3.10.1 d_read

(Default value: `private`)

`d_read` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who can read shared documents (access the contents of a list's `shared` directory).

Predefined authorization scenarios are :

- `d_read` `owner` (view)
  restricted to list owners and document author

- `d_read` `private` (view)
  restricted to subscribers

- `d_read` `public` (view)
  public documents

### 14.3.10.2 d_edit

(Default value: `owner`)

`d_edit` parameter is defined by an authorization scenario (see 9, page )

This parameter specifies who can perform changes within a list's `shared` directory (i.e. upload files and create subdirectories).

Predefined authorization scenarios are :

- `d_edit` `owner` (view)
  restricted to list owners and document author

- `d_edit` `private` (view)
  restricted to subscribers

- `d_edit` `public` (view)
  public documents

Example:

    shared_doc
    d_read		public
    d_edit		private

### 14.3.10.3 quota

`quota` number-of-Kbytes

This parameter specifies the disk quota for the document repository, in kilobytes. If quota is exceeded, file uploads fail.

# 14.4 List tuning

##
14.4.1 reply_to_header

The `reply_to_header` parameter starts a paragraph defining what Sympa will place in the `Reply-To:` SMTP header field of the messages it distributes.

- `value` `sender` `|` `list` `|` `all` `|` `other_email` (Default value: `sender`)

  This parameter indicates whether the `Reply-To:` field should indicate the sender of the message (`sender`), the list itself (`list`), both list and sender (`all`) or an arbitrary e-mail address (defined by the `other_email` parameter).

  Note: it is inadvisable to change this parameter, and particularly inadvisable to set it to `list`. Experience has shown it to be almost inevitable that users, mistakenly believing that they are replying only to the sender, will send private messages to a list. This can lead, at the very least, to embarrassment, and sometimes to more serious consequences.

- `other_email` an_email_address

  If `value` was set to `other_email`, this parameter defines the e-mail address used.

- `apply` `respect` `|` `forced` (Default value: `respect`)

  The default is to respect (preserve) the existing `Reply-To:` SMTP header field in incoming messages. If set to `forced`, `Reply-To:` SMTP header field will be overwritten.

Example :

    reply_to_header
    value other_email
    other_email listowner@my.domain
    apply forced

##
14.4.2 max_size

(Default value: ``max_size` robot parameter`)

`max_size` number-of-bytes

Maximum size of a message in 8-bit bytes. The default value is set in the `/etc/sympa.conf` file.

##
14.4.3 anonymous_sender

`anonymous_sender` value

If this parameter is set for a list, all messages distributed via the list are rendered anonymous. SMTP `From:` headers in distributed messages are altered to contain the value of the `anonymous_sender` parameter. Various other fields are removed (`Received:, Reply-To:, Sender:, X-Sender:, Message-id:, Resent-From:`

##
14.4.4 custom_header

`custom_header` header-field`:` value

This parameter is optional. The headers specified will be added to the headers of messages distributed via the list. As of release 1.2.2 of Sympa, it is possible to put several custom header lines in the configuration file at the same time.

Example: `custom_header X-url: http://www.cru.fr/listes/apropos/sedesabonner.faq.html`.

## 14.4.5 custom_subject

`custom_subject` value

This parameter is optional. It specifies a string which is added to the subject of distributed messages (intended to help users who do not use automatic tools to sort incoming messages). This string will be surrounded by [] characters.

The custom subject can also refer to list variables ([list->sequence] in the example bellow).

Example: `custom_subject sympa-users`.

Example: `custom_subject newsletter num [list->sequence]`.

##
14.4.6 footer_type

(Default value: `mime`)

`footer_type (optional, default value is mime)` `mime` `|` `append`

List owners may decide to add message headers or footers to messages sent via the list. This parameter defines the way a footer/header is added to a message.

- `footer_type` `mime`

  The default value. Sympa will add the footer/header as a new MIME part. If the message is in multipart/alternative format, no action is taken (since this would require another level of MIME encapsulation).

- `footer_type` `append`

  Sympa will not create new MIME parts, but will try to append the header/footer to the body of the message. `/home/sympa/expl/mylist/message.footer.mime` will be ignored. Headers/footers may be appended to text/plain messages only.

## 14.4.7 digest

`digest` daylist hour`:`minutes

Definition of `digest` mode. If this parameter is present, subscribers can select the option of receiving messages in multipart/digest MIME format. Messages are then grouped together, and compilations of messages are sent to subscribers in accordance with the rythm selected with this parameter.

Daylist designates a list of days in the week in number format (from 0 for Sunday to 6 for Saturday), separated by commas.

Example: `digest 1,2,3,4,5 15:30`

In this example, Sympa sends digests at 3:30 PM from Monday to Friday.

WARNING: if the sending time is too late, Sympa may not be able to process it. It is essential that Sympa could scan the digest queue at least once between the time laid down for sending the digest and 12:00 AM (midnight). As a rule of thumb, do not use a digest time later than 11:00 PM.

## 14.4.8 available_user_options

The `available_user_options` parameter starts a paragraph to define available options for the subscribers of the list.

- `reception` modelist

  (Default value: ``reception` mail,notice,digest,summary,nomail`)

  modelist is a list of modes (mail, notice, digest, summary, nomail), separated by commas. Only these modes will be allowed for the subscribers of this list. If a subscriber has a reception mode not in the list, sympa uses the mode specified in the default_user_options paragraph.

Example :

    ## Nomail reception mode is not available
    available_user_options
    reception  	digest,mail

## 14.4.9 default_user_options

The `default_user_options` parameter starts a paragraph to define a default profile for the subscribers of the list.

- `reception` `notice` `|` `digest` `|` `summary` `|` `nomail` `|` `mail`

  Mail reception mode.

- `visibility` `conceal` `|` `noconceal`

  Visibility of the subscriber with the `REVIEW` command.

Example :

    default_user_options
    reception  	digest
    visibility	noconceal

## 14.4.10 cookie

(Default value: ``cookie` robot parameter`)

`cookie` random-numbers-or-letters

This parameter is a confidential item for generating authentication keys for administrative commands (`ADD`, `DELETE`, etc.). This parameter should remain concealed, even for owners. The cookie is applied to all list owners, and is only taken into account when the owner has the `auth` parameter (`owner` parameter, see 14.1.4, page ).

Example: `cookie secret22`

##
14.4.11 priority

(Default value: ``default_list_priority` robot parameter`)

`priority` 0-9

The priority with which Sympa will process messages for this list. This level of priority is applied while the message is going through the spool.

0 is the highest priority. The following priorities can be used: `0...9 z`. `z` is a special priority causing messages to remain spooled indefinitely (useful to hang up a list).

Available since release 2.3.1.

# 14.5 Bounce related

##
14.5.1 bounce

This paragraph defines bounce management parameters :

- `warn_rate`

  (Default value: ``bounce_warn_rate` robot parameter`)

  The list owner receives a warning whenever a message is distributed and the number (percentage) of bounces exceeds this value.

- `halt_rate`

  (Default value: ``bounce_halt_rate` robot parameter`)

  `NOT USED YET`

  If bounce rate reaches the `halt_rate`, messages for the list will be halted, i.e. they are retained for subsequent moderation. Once the number of bounces exceeds this value, messages for the list are no longer distributed.

- `expire_bounce_task`

  (Default value: `d`)aily

  Name of the task template use to remove old bounces. Usefull to remove bounces for a subscriber email if some message are distributed without receiving new bounce. In this case, the subscriber email seems to be OK again. Active if task_manager.pl is running.

Example:

    ## Owners are warned with 10% bouncing addresses
    ## message distribution is halted with 20% bouncing rate
    bounce
    warn_rate	10
    halt_rate	20

##
14.5.2 bouncers_level1

- `rate`

  (Default value: ``bouncers_level1_rate` config parameter`)

  Each bouncing user have a score (from 0 to 100).This parameter define the lower score for a user to be a level1 bouncing user. For example, with default values : Users with a score between 45 and 80 are level1 bouncers.

- `action`

  (Default value: ``bouncers_level1_action` config parameter`)

  This parameter define which task is automaticaly applied on level 1 bouncing users: for exemple, automaticaly notify all level1 users.

- `Notification`

  (Default value: `owner`)

  When automatic task is executed on level 1 bouncers, a notification email can be send to listowner or listmaster. This email contain the adresses of concerned users and the name of the action executed.

##
14.5.3 bouncers_level2

- `rate`

  (Default value: ``bouncers_level2_rate` config parameter`)

  Each bouncing user have a score (from 0 to 100).This parameter define the lower score for a user to be a level 2 bouncing user. For example, with default values : Users with a score between 75 and 100 are level 2 bouncers.

- `action`

  (Default value: ``bouncers_level1_action` config parameter`)

  This parameter define which task is automaticaly applied on level 2 bouncing users: for exemple, automaticaly notify all level1 users.

- `Notification`

  (Default value: `owner`)

  When automatic task is executed on level 2 bouncers, a notification email can be send to listowner or listmaster. This email contain the adresses of concerned users and the name of the action executed.

Example:

        ## All bouncing adresses with a score between 75 and 100
        ## will be unsubscribed, and listmaster will recieve an email
        Bouncers level 2
        rate :75 Points
        action : remove\_bouncers
        Notification : Listmaster

##
14.5.4 welcome_return_path

(Default value: ``welcome_return_path` robot parameter`) `welcome_return_path` unique `|` owner

If set to `unique`, the welcome message is sent using a unique return path in order to remove the subscriber immediately in the case of a bounce. See `welcome_return_path` `sympa.conf` parameter (5.8.3, page ).

##
14.5.5 remind_return_path

(Default value: ``remind_return_path` robot parameter`) `remind_return_path` unique `|` owner

Same as `welcome_return_path`, but applied to remind messages. See `remind_return_path` `sympa.conf` parameter (5.8.4, page ).

# 14.6 Archive related

Sympa maintains 2 kinds of archives: mail archives and web archives.

Mail archives can be retrieved via a mail command send to the robot, they are stored in `/home/sympa/expl/mylist/archives/` directory.

Web archives are accessed via the web interface (with access control), they are stored in a directory defined in `wwsympa.conf`.

##
14.6.1 archive

If the `config` file contains an `archive` paragraph Sympa will manage an archive for this list.

Example:

    archive
    period week
    access private

If the `archive` parameter is specified, archives are accessible to users through the `GET` command, and the index of the list archives is provided in reply to the `INDEX` command (the last message of a list can be consulted using the `LAST` command).

`period` `day` `|` `week` `|` `month` `|` `quarter` `|` `year`

This parameter specifies how archiving is organized: by `day`, `week`, `month`, `quarter`, or `year`. Generation of automatic list archives requires the creation of an archive directory at the root of the list directory (`/home/sympa/expl/mylist/archives/`), used to store these documents.

`access` `private` `|` `public` `|` `owner` `|` `closed` `|`

This parameter specifies who is authorized to use the `GET`, `LAST` and `INDEX` commands.

##
14.6.2 web_archive

If the `config` file contains a `web_archive` paragraph Sympa will copy all messages distributed via the list to the "queueoutgoing" spool. It is intended to be used with WWSympa html archive tools. This paragraph must contain at least the access parameter to control who can browse the web archive.

Example:

    web_archive
    access private
    quota 1000

### 14.6.2.1 access

`access_web_archive` parameter is defined by an authorization scenario (see 9, page )

Predefined authorization scenarios are :

- `access` `closed` (view)
  closed

- `access` `intranet` (view)
  restricted to local domain users

- `access` `listmaster` (view)
  listmaster

- `access` `owner` (view)
  by owner

- `access` `private` (view)
  subscribers only

- `access` `public` (view)
  public

### 14.6.2.2 quota

`quota` number-of-Kbytes

This parameter specifies the disk quota for the list's web archives, in kilobytes. This parameter's default is `default_archive_quota` `sympa.conf` parameter. If quota is exceeded, messages are no more archived, list owner is notified. When archives are 95% full, the list owner is warned.

##
14.6.3 archive_crypted_msg

(Default value: `cleartext`)

`archive_crypted_msg` cleartext `|` decrypted

This parameter defines Sympa behavior while archiving S/MIME crypted messages. If set to `cleartext` the original crypted form of the message will be archived ; if set to `decrypted` a decrypted message will be archived. Note that this apply to both mail and web archives ; also to digests.

# 14.7 Spam protection

## 14.7.1 spam_protection

(Default value: ``spam_protection` robot parameter`)

There is a need to protection Sympa web site against spambot which collect email adresse in public web site. Various method are availible into Sympa and you can choose it with `spam_protection` and `web_archive_spam_protection` parameters. Possible value are :

- javascript : the adresse is hidden using a javascript. User who enable javascript can see a nice mailto adresses where others have nothing.
- at : the @ char is replaced by the string " AT ".
- none : no protection against spammer.

## 14.7.2 web_archive_spam_protection

(Default value: ``web_archive_spam_protection` robot parameter`)

Idem `spam_protection` but restricted to web archive. A additional value is available : cookie which mean that users must submit a small form in order to receive a cookie before browsing archives. This block all robot, even google and co.

Next: 15. Shared documents Up: Sympa Mailing Lists Management Software version Previous: 13. Creating and editing mailing using Contents Index