Setting |
Description |
The public name of this list (make
case-changes only). |
This is the name by which the list will be
referred to in all automatically generated messages as well as on the
listing of lists available on the server. Note that this name must match
the name of the list as it was created -- you may only change the case of
the name in this field. |
The list administrator email
addresses. Multiple administrator addresses, each on separate line is okay. |
This field should contain the e-mail address
of the list administrator. The list administrator will receive all
administrative messages generated by the server as well as any requests
that require approval (postings to moderated lists or requests to
subscribe to non-open lists).
Note: the persons listed as administrators
do not automatically receive copies of list traffic. If they want to
participate in the list they must also add their address as a
subscriber. |
The list moderator email
addresses. Multiple moderator addresses, each on separate line is okay. |
This
field should contain the e-mail address of the list moderator. The list
moderator can tend to pending administration requests, including
approving or rejecting held subscription requests, and disposing of held
postings. |
A terse phrase identifying this
list. |
This phrase will appear in two places: on the
general listinfo page showing all of the lists hosted on the server, and
in the header of all messages sent through the list itself. This value is
best kept short. |
An introductory description - a few paragraphs
- about the list. It will be included, as html, at the top of the listinfo
page. Carriage returns will end a paragraph. |
This information will be included at the top
of the listinfo page for this list. In cases where the listinfo page is
used to entice people to join the list you would want to use this setting
to provide a detailed description of the purpose and nature of the
list. |
Prefix for subject line of list
postings. |
This value will be added to the beginning of
the subject line of all list traffic in order to help members
identify/filter list traffic. By default the value is the name of the list
enclosed in [square brackets]. You may modify this value to something
other than the name of the list. |
Should any existing
Reply-To: header found in the original message be stripped? If so, this
will be done regardless of whether an explict Reply-To: header is
added by Mailman or not. |
If you
would like Mailman to remove any Reply-To: header found in the original
message, select yes. Be aware, however, that if the Reply-To: header is
removed, you should specify where replies are to go with the next two
settings. |
Where are replies to list messages directed? |
When poster is selected, the reply-to line
will be written by Mailman so that persons hitting reply in their mail
program will send their response back to the individual who posted the
note. When this value is set to "this list" the reply-to line will be
rewritten so that persons hitting reply in their mail program will send
their response back to the list itself. When this value is set to
"explicit address" the Reply-To header will use the value that is provided
in the field below.
While the program suggests that this be set to
poster, you should consider the purpose of the list in selecting this
value. Lists that intend to focus on discussion are best set to "list" to
encourage conversation. Lists used for announcements are best set to
poster to prevent unwanted traffic and the inadvertent broadcast of
replies.
|
Explicit Reply-To: header. |
If the reply-to header is set to "explicit
address above," the value in this field will be used in all outgoing list
messages. |
Send password reminders to,
eg, "-owner" address instead of directly to user. |
This is a setting that Mailman refers to
internally as the "umbrella list" setting. If your list does not actually
consist of people but instead of lists (so that messages cascade from this
"umbrella" down into the constituent lists) then you want this setting to
be yes. This means that the password and subscription information will not
be sent to all of the members of the constituent list, but instead to the
list owner alone. |
Suffix for use when this
list is an umbrella for other lists, according to setting of previous "umbrella_list"
setting. |
When "umbrella_list" is set
to indicate that this list has other mailing lists as members, then
administrative notices like confirmations and password reminders need to not
be sent to the member list addresses, but rather to the owner of those
member lists. In that case, the value of this setting is appended to the
member's account name for such notices. `-owner' is the typical choice. This
setting has no effect when "umbrella_list" is "No". |
Send monthly password
reminders? |
When
set to yes, list members will receive an automatically generated monthly
posting reminding them of their password as well as the URLs to access their
list configuration options. This will save you a lot of time as administrator as it will let users solve a
lot of their own problems. |
List-specific text prepended to new-subscriber
welcome message. |
When new users join your list, or when they
are added by the list manager, they receive a note welcoming them to the
list and telling them about their password and list-related URLs. Text
contained in this box will be prepended to the generic technical
information so that you can let them know about specific procedures or
protocols related to their participation in the list. |
Send welcome message to
newly subscribed members? |
When set to yes people who join the list or
who are added by the list administrator will receive an automatically
generated welcome message with information including the list address,
their password, and the URLs needed to access their list
preferences. |
Text sent to people leaving the list. If
empty, no special text will be added to the unsubscribe message. |
This is your last chance to get a word in when
people leave your list.
Note: in Mailman there is no way to
prevent persons from leaving a list. If you are running a list where
participation is mandatory (such as a course or a list of system users)
you may want to include something in this area to let them know that they
should not be leaving the list. |
Send goodbye message to
members when they are unsubscribed? |
If you
set this to Yes, people leaving the list will receive Mailman's standard
"goodbye" message along with any special text you have provided in the above
setting. |
Should the list moderators
get immediate notice of new requests, as well as daily notices about
collected ones? |
This setting dictates the frequency with which
the list moderators are told of pending administrative requests: either
notes awaiting moderator approval or subscription request for controlled
lists. By default the server will send a daily reminder of the pending
requests. If the list owner would like more immediate notification then
they should check "yes" here for immediate notice of each request.
The notification that you receive will include
a URL that will take you to the pending administrative requests page
detailed near the end of this document. |
Should administrator get notices of
subscribes/unsubscribes? |
Because list membership is checked easily
through the web, the list manager may not feel that it is necessary to
know of all of the comings and goings of list members (especially on large
lists with a lot of turnover). Saying yes here will tell Mailman to send a
short note to the list manager for each person that is added or removed
from the list.
Note: Mailman does not currently let the list
manager block persons from leaving the list. If you are running a list for
something like a course or committee, where participation is mandatory,
make sure to have this set this to "yes" so you will be informed of
unauthorized departures.
Note: If you are migrating large lists over to
Mailman, or if you are creating new lists using the mass subscribe
feature, you may want to deactivate this initially so that the manager is
not flooded with innumerable subscribe notices. |
Send mail to poster when their posting is held
for approval? |
Setting this option to yes will send a short
"we have your message and it is awaiting approval" note to persons whose
postings are being held for approval. This is a useful "courtesy" and will
help people on moderated lists from wondering why their note never showed
up. This message will also be sent to non-members who attempt to
post to lists that allow posting for members only. |
Default options for new
members joining this list. |
Select the default setting
for new members. Members can change this setting via the web interface
later, but a default setting must be selected. |
(Administrivia filter) Check postings and
intercept ones that seem to be administrative requests? |
If you activate this feature Mailman will
check traffic for administrative requests that have inadvertently been
sent to the list. This will prevent the classic case of a user sending a
note to the entire list membership saying "unsubscribe." |
Maximum length in Kb of a message body. Use 0
for no limit. |
This setting will allow you to specify the
maximum size of messages allowed to be passed through the list to the
subscribers. This is an important security measure as it allows you to
block a malicious poster from bombing everyone's list with a large file
and it prevents your server from being tied up delivering inappropriately
large messages.
The recommended value for this setting is nothing
greater than 40. |
Host name this list prefers
for email. |
For multi-home hosts (systems that have
different aliases) this would be the value that Mailman uses to identify
itself. Do not change the value of this setting unless you have
made specific arrangements with EsoSoft or your list may cease to work. |
Should messages from this
mailing list include the RFC 2369 (i.e. List-*) headers? Yes
is highly recommended. |
RFC 2369 defines a set of
List-* headers that are normally added to every message sent to the list
membership. These greatly aid end-users who are using standards compliant
mail readers. They should normally always be enabled.
However, not all mail readers are standards compliant yet, and if you
have a large number of members who are using non-compliant mail readers,
they may be annoyed at these headers. You should first try to educate your
members as to why these headers exist, and how to hide them in their mail
clients. As a last resort you can disable these headers, but this is not
recommended (and in fact, your ability to disable these headers may
eventually go away). |
Should postings include the
List-Post: header? |
The List-Post:
header is one of the headers recommended by
RFC 2369. However for
some announce-only mailing lists, only a very select group of
people are allowed to post to the list; the general membership is usually
not allowed to post. For lists of this nature, the List-Post:
header is misleading. Select No to disable the inclusion of this
header. (This does not affect the inclusion of the other List-*:
headers.) |