|
|
|
GNU Mailman - List Administration Manual |
|
|
|
This subcategory controls the rules for exposing the existence of this
list, and for what new members must do in order to subscribe to the
list.
- advertised
- This option controls whether this list will show up in the list
overview for the site. Normally, an overview contains the name
and short description of every mailing list in the virtual
domain. By setting this variable to No, it will not show
up in this overview, nor will it show up in the administrative
overview. The only way then to find the list is to guess (or
know!) its name.
- subscribe_policy
- This option controls the steps that a new member must take to join
the list. The available options may differ based on some defaults
that the site administrator chooses. They are:
- None - No verification is done on the subscribing
member. This is also called open subscriptions and is
generally disabled by default. The site administrator must
allow list admins to choose this option; if not, this option
will not be presented to you.
- Confirm - An email confirmation step is required before the
address is added to the list. When a member requests
subscription, either via the web page or by sending a
message to yourlist
-join@example.com
, Mailman
will send a confirmation message to the requesting address.
This mail-back confirmation contains a unique identifier,
which the requester can present to Mailman in order to
confirm their subscription. This can be done either by
replying to the mail-back, or by visiting the url in the
mail-back message. The url points to a page that lets the
user either discard or confirm their request.
- Require approval - All subscription requests are held for
approval of the list moderator. No mail-back confirmation
is sent, but the list admins will recieve a message
indicating that approval is pending.
- Confirm and approve - Here, a mail-back notice must first
be confirmed by the requester. Once confirmed, the list
moderator must then approve the request. This is the most
secure method for users to subscribe since it both verifies
the requesting address, and forces the list moderators to
approve the request.
- unsubscribe_policy
- Specifies whether the list moderator's approval is required for
unsubscription requests. No is highly recommended, since
it is exceedingly impolite to not allow people to leave a mailing
list whenever they want (i.e. opt-out). Yes is useful in
some specialized contexts; e.g. you may not want to allow
employees to unsubscribe from the company newsletter.
- ban_list
- This contains a list of addresses (or regular expressions), one
per line, that are banned from ever subscribing to your mailing
list. If a match occurs during the subscription process, the
request will be automatically rejected, and the requester will get
a rejection notice. You can use this to permanently ban
troublesome posters to a members-only list.
- private_roster
- This specifies who is allowed to view the roster of member
addresses. If you choose Anyone, then the list membership
is completely public. You can limit exposure of the roster to
just list members, or just to the list administrators. In the
former case, a user must enter a valid member's address and
password before they can view the roster. In the latter case, a
list administrator's password must be entered; if a matching admin
password is entered, address field is ignored.
- obscure_addresses
- Controls whether some simple obfuscation of addresses is used when
member addresses are included on web pages. This should reduce
the opportunity for email address harvesting by spammers, although
it probably doesn't eliminate it.
Release 2.1, documentation updated on March 2, 2015.