GNU Mailman List Management Guide v 2.0
|
Accessing Management Options
This document assumes that you are the owner (alternately referred to
as the list manager, administrator, or moderator). When the list was created
and you were assigned ownership of the list you should have received an
automatically-generated message letting you know what your administrative
password is, as well as directing you to the URLs needed to manage the
list through your browser. This document will further assume that you
have your list's manager's password, that you know the URL for the management
settings, and that you have a table-capable browser (Mailman does not
use any Java or JavaScript).
When you access your management settings using your list management page
you will be prompted for the password. Once you authenticate to the server
you will be shown the General Options page for you list and will also
see a listing of the other categories of settings that are available.
For all of these categories you will be able to make changes using your
browser, but the changes will not go into effect until you go to the bottom
of the screen and click the "Submit Your Changes" button. Changes will
then be immediately put into effect -- nothing needs to be changed or
restarted on the list server itself.
The remainder of this document will talk about each of the settings as
they appear in the configuration categories for your list. Note that each
list server is configured with different default settings, so this document
does not assume that any particular setting will be the default when you
look at your own list.
After you are authenticated by the server, you will be taken into Mailman's
General Options screen. Note that at the top of each of Mailman's
configuration screens you will see links to each of the configuration categories.
This document will cover all of the settings in each of the configuration
categories.
In the Cpanel click on the "Mailing Lists" option.
Click the Add List.
Type in the lists name "mylist" and password and click
on Create.
After the account is created click on the Go Back link.
To set up the listserv click on the Edit link besides the list
you just created.
Type in your lists password
You now can edit you lists settings. From this menu you can control the
look and feel of the list. You can add a tag line add a subject line header
and much more!
If you are changing over to this listserv from a old list or you just
need to add a list of email address you can do it using the Membership
Management option. This is very nice. If you have a member that is going
out of town and does not want to have 500 email from the list when they
get back they can go "nomail".
Below is a in-depth look at what the admin control panel can do for you.
Mailman's general options allow you to specify most of the ways that
your mail list will interact with the web server and how it will present
itself to the users. The text in the "setting" should
match the settings that you see in v2 of Mailman. The description
content provides a brief description of each setting as well as guidelines
for use when appropriate.
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 admin's email address
- having multiple admins/addresses (on separate lines) is ok. |
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.
|
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. |
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. |
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 v2 of 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.
|
Where are replies to list messages
directed? Poster is strongly recommended for most mailing lists. |
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. |
(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." |
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 using your list as an umbrella
list as mentioned above, this setting is what will be used to specify
who the owners of the constituent lists are. While -owner is not universal,
it will cover the conventions used by most of the mail list managers
that are used today (and will work with Mailman lists). |
Send monthly password reminders
or no? Overrides the previous option. |
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're a lot of time as administrator as it
will let users solve a lot of their own problems. |
Send welcome message when people
subscribe? |
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. |
Should administrator get immediate
notice of new requests, as well as daily notices about collected ones? |
This setting dictates the frequency
with which the list administrator is 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. |
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.
If you do not wish to have a limit on the size of
message, set this value to 0.
|
Host name this list prefers. |
For multi-home hosts (systems that
have different aliases) this would be the value that Mailman uses
to identify itself. You should not attempt to modify this value without
consulting your system administrator or Mailman may cease to work. |
Base URL for Mailman web interface. |
This is the base portion of the
Mailman URL that will be prepended to all of the pointers to specific
web features. You should not attempt to modify this value without
consulting your system administrator or Mailman may cease to work. |
The membership management section allows you to do two things: add/remove
users from your list, or adjust custom user settings.
Adding and Removing Members
The addition and removal of members is done thought the membership management
screen. When you access this screen you will be shown a table listing
all of your subscribers as well as their current member settings. Through
this screen Mailman allows the list manager to remove an individual from
their mail list, but the method is not entirely intuitive.
Find the line with the e-mail address of the individual that you would
like to remove.
- The check mark in the first column by the user address, labeled "subscr"
indicates that user is subscribed to your list. Uncheck the box by the
address that you would like to remove.
- Click the "Submit your changes" button at the bottom of the screen
to put the changes into effect.
Mailman allows a list manager to add people for their mail list through
this screen, but the method is not intuitively named.
- Scroll down to the area labeled "Mass Subscribe Users."
- Type the e-mail address of the individual that you would like to add
into the text box. If you would like to add more than one person then
each address should be entered on a separate line.
- If you would like to send a welcome message to the new members then
make sure that the "yes" button is checked. This will send the new members
their passwords and list configuration instructions.
- Click the "Submit your changes" button at the bottom of the screen
to put the changes into effect.
Note: You will almost always want to send new subscribers the welcome
message so that they have their password and the information necessary
to customize their configuration.
Note: Network etiquette generally frowns on opt-out lists apart from
their common use within an organization for official communications and
notices -- adding unsuspecting persons to a list and then telling them
that they can leave if they want. Do not use Mailman for unconscionable
activities such as sending Spam.
Subscriber Options
In the main table each participants address is shown along with the current
options for that user's list settings. As list administrator you have
the capability to modify any of the options for each of your subscribers.
Modifications are made by checking or unchecking the boxes for each feature
on the row corresponding to the subscriber's settings that you wish to
change. After making the modifications you need to click the "Submit Your
Changes" button at the bottom of the screen to put them into effect.
Note that because these settings are user configurable not all users may
have the same settings when you look at this page. Do not be alarmed,
it simply means that they have taken the time to modify their settings.
Setting
|
Values
|
subscr |
This setting indicates whether
or not the member is subscribed. If you uncheck this box and then
submit the changes on this page the user will be removed from the
list. |
hide |
As a privacy feature, Mailman allows
subscribers to make themselves invisible to others as part of the
web-based e-mail subscriber list. A check here indicates that the
person will not appear to others as a member of the list. This setting
does not affect the ability of the list manager to see the subscriber
on the list management page. |
nomail |
Users may disable mail delivery
if, for example, they are going to be away from their mail but do
not want to unsubscribe.
Mailman's bounce feature may also set a user to
nomail status if mail to their address experiences delivery problems.
See the section on bounce handling for more information.
|
ack |
Members may request that Mailman
send a short acknowledgement when a they post a message to the list.
Members find this useful for moderated lists so that they know that
their posting was delivered to the moderator successfully. |
not metoo |
In the event that members find
their own posts annoying, they can tell Mailman not to include them
in the delivery of their own postings to the list. |
digest |
If the digest feature has been
activated for the list, members may choose to receive list traffic
bundled as a single large message as opposed to receiving individual
messages. This setting indicates whether the member will receive individual
posts or the digest. |
plain |
When a user opts for digest delivery,
this setting indicates whether the digest will be delivered as plain
text or in MIME format. Most users of modern, GUI-based mail clients
can handle MIME traffic with no problems. Persons using character-based
mail clients should opt for plain-text digests. |
Mailman was created with the privacy shortcomings of other lists in mind.
There are a number of manager-configurable settings that can help in preventing
spam, subscription abuse, and widespread disclosure of list traffic to
non-subscribers.
Subscribing
Description
|
Value
|
Advertise this list when people
ask what lists are on this machine? |
In general, persons in the outside
world can see a list of available Mailman lists by visiting http://name.of.host/mailman/listinfo
By setting this value to "no," this list will not
be included in the directory of available lists.
|
What steps are required for subscription? |
Confirm: when a subscription request
is made a message will be sent back to the address being added. The
new member will have to reply to the message (without having to modify
anything) for their subscription to become active. This prevents someone
from maliciously adding people against their will.
Require Approval: when a subscription request is
made a note will be sent to the list administrator letting them
know that a person is petitioning to join. The list administrator
will be given a URL to follow that will then show them the request
and allow them to approve or deny it via the web.
Confirm+Approval: includes both of the above.
|
Membership exposure
Description
|
Value
|
Who can view subscription list? |
This setting dictates access to
the subscription list via the web.
Anyone: this allows anyone in the world to browse
by and take a look at who the members of your list are. Never ever
use this setting unless you are trying to say "I have contempt for
all of my list members and hope that they get spammed out of their
minds."
List members: this is the traditional setting for
most lists, allowing participants to see who the other people on
the list are but blocking view to the general public. This settings
can be overridden by individual users who have set the "hide" option
for their account.
List admin only: only the administrator can see
the list members.
|
Show member addrs so they're not
directly recognizable as email addrs? |
This is a nice feature that discourages
theft of lists: the membership list does not show actually addresses
but instead shows participants as "username at foo.com". This
should block most harvesters if they manage to get through to the
listing. |
General posting filters
Mailman allows you a good deal of control over who may and may not post
to the list. Because there is a bit of good old-fashioned logic involved
some people may be confused by these settings. Please see the chart following
the descriptions of the settings for an illustration of how these settings
work in concert.
Description
|
Value
|
Must posts be approved by an administrator? |
This settings defines the list
as "moderated" or "unmoderated" in most people's minds. If set to
yes, postings are held and the administrator is notified of their
existence. They may then approve or reject postings via the web interface.
If set to "no," postings to the list are immediately delivered to
list membership. |
Restrict posting privilege to list
members? (member_posting_only) |
Under nearly all circumstances
this should be set to "yes." This restriction will cause Mailman to
hold for administrative review all posts to the list that do not originate
from a list member. Setting this to yes prevents you from being spammed
by people who manage to get a hold of your list address.
Note: there is a use to setting this to no, see
the chart below.
|
Addresses of members accepted for
posting to this list without implicit approval requirement. |
This settings can be used to designate
posting privileges to persons who are not subscribers to the list.
It may also be used to specify persons who are exclusively allowed
to post. Please see the chart below for explanation. |
Posting privileges explained
The posting privileges settings outlined above actually interact with
one another. This chart will help to explain their use so that you can
optimally configure your posting privileges. Each box shows who may post
for each of the configurations.
Who is allowed to post? |
Posting restricted to list members? |
Yes |
No |
Are there implicitly approved people? |
Yes |
List members and individuals
listed. |
Only listed persons may
post. |
No |
List members only. |
Anyone in the universe. |
Spam-specific posting filters
Value
|
Description
|
Must posts have list named in destination
(to, cc) field (or be among the acceptable alias names, specified
below)? |
This prevents the list from being
used as part of a BCC (Blind Carbon Copy) spam. |
Alias names (regexps) which qualify
as explicit to or cc destination names for this list. |
Helps Mailman make allowances for
mail systems that do not substitute the address for alias or for mail
servers where list address receives mail from an alias with a different
name. |
Ceiling on acceptable number of
recipients for a posting. |
Prevents the list from being used
as part of a mass recipient spam. Also discourages use of list as
recipient of office jokecast notes and bogus solicitations. |
Addresses whose postings are always
held for approval. |
Allows manager to designate special
special individuals whose postings are always held for approval while
when postings are otherwise allowed through. |
Hold posts with header value matching
a specified regexp. |
Allows you to filter out known
addresses or domains that function primarily as spam providers. |
Hide the sender of a message, replacing
it with the list address (Removes From, Sender and Reply-To fields) |
This tells Mailman to rewrite the
header so that traffic appears to be coming from the list itself instead
of the original poster. Provides some added privacy for posters, but
may be annoying to some list members as mailbox headers show only
the list name instead of the actual poster. |
These are options that affect the normal mail traffic that is delivered
immediately and individually to list members.
Setting
|
Description
|
Can subscribers choose to receive
mail immediately, rather than in batched digests? |
While this seems a bit silly, it
is really asking about what options are available to list members.
If you say no, then subscription to the list will be available only
as a digest. |
Header added to mail sent to regular
list members. |
Allows you to add a uniform header
to all notes passing through the list. |
Footer added to mail sent to regular
list members. |
Allows you to add a uniform footer
to all notes passing through the list. The default footer shows the
list name, the list address, and the URL that persons can go to in
order to access the list information and change their settings.
Note: including this footer information will cut
down on the number of times list users will have to contact the
list administrator asking for things such as their configuration
access information and the like.
|
These options affect the way that the list will process messages that
are to be delivered to subscribers in the form of a digest. Unlike other
mail list managers, the digest feature of Mailman is built into the package
and it easy to activate and configure.
Setting
|
Description
|
Can list members choose to receive
list traffic bunched in digests? |
This setting allows you to specify
whether or not users can opt to receive mail traffic to the list in
the form of a digest.
Note: There are some instances, such as a list for
emergency announcements, where you want mail to be delivered immediately
in all cases and where you would want to disable the digest feature.
|
Which delivery mode is the default
for new users? |
This setting specifies whether
new users added by the list manager default to regular or digest delivery.
Users adding themselves to the list via the listinfo page are given
the option to choose for themselves: the options selected here is
what will be chosen for them as a default. |
When receiving digests, which format
is default. |
Regular will cause Mailman to send
plain text digests. When MIME is selected, the digest message
will be sent as a multipart MIME message as appropriate for the content
that the message contains. |
How big in Kb should a digest be
before it gets sent out? |
Mailman will collect list traffic
until this threshold is reached, then it will deliver the digest to
users. This setting is useful in preventing digests from containing
so many messages that the reader becomes disoriented. |
Should a digest be dispatched daily
when the size threshold isn't reached? |
When installed, Mailman is set
to run a daily maintenance script. If you check yes for this option
Mailman will send a digest at the specified time even though the size
threshold has not been reached. This is a good idea for low traffic
lists that may take some time in reaching the threshold.
Note: By default, the daily dispatch time is noon
(server time). If you want to be sure of the time that your daily
dispatch goes out ask the system administrator of your system.
|
Header added to every digest. |
Allows you to add a uniform header
to all digests passing through the list. |
Footer added to every digest. |
Allows you to add a uniform footer
to all digests passing through the list. The default footer shows
the list name, the list address, and the URL that persons can go to
in order to access the list information and change their settings.
Note: including this footer information will cut
down on the number of times list users will have to contact the
list administrator asking for things such as their configuration
access information and the like.
|
Unlike many other mail list managers, Mailman includes built-in bounce
handlers to help the list manager deal with address that have delivery
problems. If you run large lists with dynamic membership then these
settings may save you a lot of time in helping to weed out addresses that
go bad.
Value
|
Description
|
Try to figure out error messages
automatically? |
Tells Mailman whether or not to
bother you with bounce messages. Mailman does a pretty good job of
figuring out error messages generated with RFC-compliant mail agents.
On large lists with a large number of subscribers coming and going,
this feature will save you a lot of reading from MAILER-DAEMON. |
Minimum number of days an address
has been non-fatally bad before we take action. |
In the even that there is a problem
reaching a host or domain, this setting tells Mailman how long to
hold onto the delivery error messages before taking action. In practice,
this is a good way of preventing persons from getting bounced just
because their network is flaky and not reliably reachable. |
Minimum number of posts to the
list since members first bounce before we consider removing them from
the list. |
This amounts to telling Mailman
how many times to try someone before giving up. |
Maximum number of messages your
list gets in an hour. |
Mailman uses this guesstimate to
help figure out some of the characteristics of the bounce notifications
that it receives. Give this setting your best shot. |
Action when critical or excessive
bounces are detected. |
This setting tells Mailman what
to do when one of the above conditions are met, or when a "fatal"
error is recorded attempting to deliver to an address.
Do nothing: Mailman will keep attempting to deliver
to the address despite the futility of the effort -- this setting
in effect disable automatic bounce handling.
Disable and notify: Mailman set the problem account
to "nomail" status and notifies you of the problem.
Disable and DON'T notify: sets problem account to
"nomail" status but doesn't bother you with the details.
Remove and notify me: removes the problem account
from the list and sends a note to the list manager.
|
Unlike other mail list managers, Mailman has a built-in archival feature
that is easily activated and configured by the list manager.
Value
|
Description
|
Archive messages? |
Setting this to "yes" will cause
Mailman to store a record of all traffic sent thorough the list. |
Is archive file source for public
or private archival? |
If set to "private," then only
list members are able to access the contents of the list archive.
They will be prompted for their list password when the try to access
the contents. Setting this to "public" will allow anyone to access
the list archives through the listinfo page.
Note: think carefully about whether your list membership
wants their identities and postings made available to the world
at large by making the archive public. Public access means
that web spiders will be able to store and make available member's
writings outside of the context of the list to which they were posted
to the list.
|
Set date in archive to when the
mail is claimed to have been sent, or to the time we resend it? |
Determines whether the message
is stored with the time stamp of the sender when the note was sent,
or the time stamp at the time it was approved by the moderator (when
applicable). |
How often should a new archive
volume be started? |
The main archive screen for a list
breaks down the archive content based on this setting. There is no
best setting here, only what is most appropriate based on the list's
function and the amount of traffic that it receives. |
Mail-News and News-Mail Gateway Settings
|
In the event that you find it useful to gate your list traffic onto USENET,
you can use these settings to set up the service. Note that you may need
to talk to your system or network administrator to make sure that your
news server will work nicely with this list gateway.
Value
|
Description
|
The Internet address of the machine
your News server is running on. |
This is the host name of your NNTP
server. If in doubt, contact your system administrator for this setting.
Make sure to use a host that you have permission to post to. |
The name of the Usenet group to
gateway to and/or from. |
Make sure that this newsgroup is
available on your news server. |
Should posts to the mailing list
be resent to the newsgroup? |
Specifies whether messages sent
to the list should be sent to the news group for the entire world
to see. |
Should newsgroup posts not sent
from the list be resent to the list? |
Specifies whether or not messages
posted by people out there in the world who are not members of the
list should be gated and distributed to list members. |
Should mailman perform a catchup
on the newsgroup? |
This setting tells Mailman to begin
gating the newsgroup content to the mail list beginning at the moment
that the setting is evoked. Saying yes will effectively mark
all of the previous news postings are having been read, and Mailman
will ignore previous postings to the group. |
A new feature in Mailman v2 is the inclusion of Auto-responder functionality.
This feature allows a list administrator to specify that automated responses
be sent in a number of different circumstances. The top of this
screen shows a number of strings that can be inserted into the response
text in order to craft responses with text that is specific to the list
that is using the auto-responder.
Value
|
Description
|
Should Mailman send an auto-response
to mail list posters? |
If yes, then Mailman will automatically
send the response text (entered below) or a specified attachment to
persons sending mail to the list address. This may be useful,
for example, in sending FAQs or list participation guidelines to senders. |
Auto-response text to send to mail
list posters. |
This field contains the text that
is mailed to all posters to the list address when the auto-response
feature is turned on for the list address. If you would prefer
to send a file as the automatic response, you should specify and upload
the file using the field below the text box. |
Should Mailman send an auto-response
to email sent to the -admin and -owner addresses? |
This setting allows you to specify
auto response actions to be taken if you would like to have replies
sent to the list owner/administrator. |
Auto-response text to send to -admin
and -owner emails. |
This field contains the text that
is mailed to all posters to the list address when the auto-response
feature is turned on for the list -admin and -owner addresses..
If you would prefer to send a file as the automatic response, you
should specify and upload the file using the field below the text
box. |
Should Mailman send an auto-response
to emails sent to the -request address? If you choose yes, decide
whether you want Mailman to discard the original email, or forward
it on to the system as a normal mail command. |
Version 2 of Mailman allows you
to intercept mail traffic sent to a list's administrative address.
In addition to sending an automated response, you may also specify
whether the system will discard the message or forward it along to
the administrative command handler. This may be useful in informing
users about list use or enforcing membership rules. |
Auto-response text to send to -request
emails. |
This field contains the text that
is mailed to all posters to the list address when the auto-response
feature is turned on for the list -request addresses.. If you
would prefer to send a file as the automatic response, you should
specify and upload the file using the field below the text box. |
Number of days between auto-responses
to either the mailing list or -admin/-owner address from the same
poster. Set to zero (or negative) for no grace period (i.e.
auto-respond to every message). |
This setting allows you to determine
the frequency with which people will receive auto responses send to
auto-responder active addresses. Setting this value to zero
means that a response will be sent for every posting to the active
address, otherwise additional responses will not be sent to a given
user until the number of days specified by this field have passed. |
Other Administrative Activities
|
In addition to the web-based access to list settings, Mailman provides
three links at the top of each administrative page for "other"
activities.
Tend to pending administrative requests.
There are primarily three instances when you will need to tend to administrative
requests. Whether the administrator is notified immediately for
each request or just once per day is dictated by the switch in Mailman's
general settings section. Note that if you have multiple requests
pending you can work your way down the page clicking the appropriate action
for each request before submitting them all at once. You do not
need to click on the submit action on this page after answering individual
requests.
1. When a posting is held because it was posted by a non-member.
If you are running a list on which only members can post, items that are
being held for review will appear in this section for your review.
As the list administrator you have four actions available on this screen.
- Defer the posting, leaving it for a later time or for another list
administrator to look at.
- Approve the posting and forward it to list members.
- Reject the posting: the original poster will be sent notification
of the rejection along with the explanation that appears in the message
box on this screen. You may customize the message as you see fit
or leave it empty.
- Discard the message with no notification sent to the poster.
This is particularly useful for spam.
When choosing the action you will have two additional options:
- Preserve message for site administrator: this will keep a copy of
the message in the admin requests section even if you choose an action
other than defer.
- Additionally forward this message to: allows you to take action on
the note and forward a copy of it to another person.
2. When you operate a moderated list, you will use this feature
to accept or reject postings following the same guidelines as for non-members
postings above.
3. When you operate a list where subscription requires administrator
approval, user petitions to join will be listed on this page. You
should click accept or deny as appropriate.
Go to the general list information page.
Following this link takes you to the list's "public" information
page. This is the page that your subscribers use to log in and modify
their settings, it is also the gateway to the list archive.
Edit the HTML for the public list pages.
Mailman allows you to customize the look and feel for many of the pages
that are accessible by your list subscribers. This is nice if you
want to take the time to "brand" web pages. The following
pages can be customized:
- The general list information page
- The subscriptions results page
- The user specific options page
- The changing user options results page
When you follow the link to a particular page you are shown the source
HTML in a browser window. In order to make modification you will
need to know how to write raw HTML code and insert it in the proper places
in the page source. It is important to note that within the source
there are embedded Mailman fields that are inserter on-the-fly when the
user loads the page. You can identify the Mailman fields because
they are enclosed in angle brackets and are of the form
<MM-Field-Name>
It is suggested that you not make modifications to the Mailman field
tags unless you are an advanced user who understands the implications
of modifying or removing these fields.
Copyright (c) 1999, 2000 Aurora University, Christopher
Kolar. Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no Invariant
Sections, with no Front-Cover Texts specified, and with no Back-Cover
Texts specified. A copy of the license is included in the section entitled
"GNU Free Documentation License".
This document is intended for persons who have the responsibility
of managing mail lists that are being run by the GNU Mailman mail list
manager. Note that this document is not intended for people who are only
list members, and this document is not intended to serve as a technical
document that tells system administrators about installing or managing
the software. This document instead recognizes that Mailman makes it possible
for normal end users to take over responsibility for management of a mail
list and attempts to provide them with the information necessary to effectively
use the features of Mailman to become self-sufficient in doing so.
This document attempts to follow the layout of Mailman's
management screens as seen by the list manager and are valid for version
2.0. This document is currently being maintained by Christopher Kolar (ckolar@admin.aurora.edu)
and is copyright Aurora University. Please note that an Manager's
Quick Reference is available, in operation we have found that it solves
about 90% of list owners' problems. If you are a relatively experienced
manager of Mailman lists, take a look at the management
differences document to find out what has been changed.
The most recent version of Mailman is available
at www.list.org, where there are also
instructions on how to join the highly useful user mail list.
GNU Free Documentation License
GNU Free Documentation License Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite
330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim
copies of this license document, but changing it is not allowed.
0. PREAMBLE The purpose of this License is to make a manual,
textbook, or other written document "free" in the sense of freedom:
to assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible for
modifications made by others. This License is a kind of "copyleft",
which means that derivative works of the document must themselves be free
in the same sense. It complements the GNU General Public License, which
is a copyleft license designed for free software. We have designed this
License in order to use it for manuals for free software, because free
software needs free documentation: a free program should come with manuals
providing the same freedoms that the software does. But this License is
not limited to software manuals; it can be used for any textual work,
regardless of subject matter or whether it is published as a printed book.
We recommend this License principally for works whose purpose is instruction
or reference.
1. APPLICABILITY AND DEFINITIONS This License applies
to any manual or other work that contains a notice placed by the copyright
holder saying it can be distributed under the terms of this License. The
"Document", below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as "you". A "Modified
Version" of the Document means any work containing the Document or
a portion of it, either copied verbatim, or with modifications and/or
translated into another language. A "Secondary Section" is a
named appendix or a front-matter section of the Document that deals exclusively
with the relationship of the publishers or authors of the Document to
the Document's overall subject (or to related matters) and contains nothing
that could fall directly within that overall subject. (For example, if
the Document is in part a textbook of mathematics, a Secondary Section
may not explain any mathematics.) The relationship could be a matter of
historical connection with the subject or with related matters, or of
legal, commercial, philosophical, ethical or political position regarding
them. The "Invariant Sections" are certain Secondary Sections
whose titles are designated, as being those of Invariant Sections, in
the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are
listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says
that the Document is released under this License. A "Transparent"
copy of the Document means a machine-readable copy, represented in a format
whose specification is available to the general public, whose contents
can be viewed and edited directly and straightforwardly with generic text
editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for
input to text formatters or for automatic translation to a variety of
formats suitable for input to text formatters. A copy made in an otherwise
Transparent file format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is
not "Transparent" is called "Opaque". Examples of
suitable formats for Transparent copies include plain ASCII without markup,
Texinfo input format, LaTeX input format, SGML or XML using a publicly
available DTD, and standard-conforming simple HTML designed for human
modification. Opaque formats include PostScript, PDF, proprietary formats
that can be read and edited only by proprietary word processors, SGML
or XML for which the DTD and/or processing tools are not generally available,
and the machine-generated HTML produced by some word processors for output
purposes only. The "Title Page" means, for a printed book, the
title page itself, plus such following pages as are needed to hold, legibly,
the material this License requires to appear in the title page. For works
in formats which do not have any title page as such, "Title Page"
means the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
2. VERBATIM COPYING You may copy and distribute the Document
in any medium, either commercially or noncommercially, provided that this
License, the copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that you add
no other conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further copying
of the copies you make or distribute. However, you may accept compensation
in exchange for copies. If you distribute a large enough number of copies
you must also follow the conditions in section 3. You may also lend copies,
under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY If you publish printed copies of
the Document numbering more than 100, and the Document's license notice
requires Cover Texts, you must enclose the copies in covers that carry,
clearly and legibly, all these Cover Texts: Front-Cover Texts on the front
cover, and Back-Cover Texts on the back cover. Both covers must also clearly
and legibly identify you as the publisher of these copies. The front cover
must present the full title with all words of the title equally prominent
and visible. You may add other material on the covers in addition. Copying
with changes limited to the covers, as long as they preserve the title
of the Document and satisfy these conditions, can be treated as verbatim
copying in other respects. If the required texts for either cover are
too voluminous to fit legibly, you should put the first ones listed (as
many as fit reasonably) on the actual cover, and continue the rest onto
adjacent pages. If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the general
network-using public has access to download anonymously at no charge using
public-standard network protocols. If you use the latter option, you must
take reasonably prudent steps, when you begin distribution of Opaque copies
in quantity, to ensure that this Transparent copy will remain thus accessible
at the stated location until at least one year after the last time you
distribute an Opaque copy (directly or through your agents or retailers)
of that edition to the public. It is requested, but not required, that
you contact the authors of the Document well before redistributing any
large number of copies, to give them a chance to provide you with an updated
version of the Document.
4. MODIFICATIONS You may copy and distribute a Modified
Version of the Document under the conditions of sections 2 and 3 above,
provided that you release the Modified Version under precisely this License,
with the Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever possesses
a copy of it. In addition, you must do these things in the Modified Version:
- A. Use in the Title Page (and on the covers, if any)
a title distinct from that of the Document, and from those of previous
versions (which should, if there were any, be listed in the History
section of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
- B. List on the Title Page, as authors, one or more
persons or entities responsible for authorship of the modifications
in the Modified Version, together with at least five of the principal
authors of the Document (all of its principal authors, if it has less
than five).
- C. State on the Title page the name of the publisher
of the Modified Version, as the publisher.
- D. Preserve all the copyright notices of the Document.
- E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
- F. Include, immediately after the copyright notices,
a license notice giving the public permission to use the Modified Version
under the terms of this License, in the form shown in the Addendum below.
- G. Preserve in that license notice the full lists of
Invariant Sections and required Cover Texts given in the Document's
license notice.
- H. Include an unaltered copy of this License.
- I. Preserve the section entitled "History",
and its title, and add to it an item stating at least the title, year,
new authors, and publisher of the Modified Version as given on the Title
Page. If there is no section entitled "History" in the Document,
create one stating the title, year, authors, and publisher of the Document
as given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
- J. Preserve the network location, if any, given in
the Document for public access to a Transparent copy of the Document,
and likewise the network locations given in the Document for previous
versions it was based on. These may be placed in the "History"
section. You may omit a network location for a work that was published
at least four years before the Document itself, or if the original publisher
of the version it refers to gives permission.
- K. In any section entitled "Acknowledgements"
or "Dedications", preserve the section's title, and preserve
in the section all the substance and tone of each of the contributor
acknowledgements and/or dedications given therein.
- L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers or the
equivalent are not considered part of the section titles.
- M. Delete any section entitled "Endorsements".
Such a section may not be included in the Modified Version.
- N. Do not retitle any existing section as "Endorsements"
or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections
or appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the list
of Invariant Sections in the Modified Version's license notice. These
titles must be distinct from any other section titles. You may add a section
entitled "Endorsements", provided it contains nothing but endorsements
of your Modified Version by various parties--for example, statements of
peer review or that the text has been approved by an organization as the
authoritative definition of a standard. You may add a passage of up to
five words as a Front-Cover Text, and a passage of up to 25 words as a
Back-Cover Text, to the end of the list of Cover Texts in the Modified
Version. Only one passage of Front-Cover Text and one of Back-Cover Text
may be added by (or through arrangements made by) any one entity. If the
Document already includes a cover text for the same cover, previously
added by you or by arrangement made by the same entity you are acting
on behalf of, you may not add another; but you may replace the old one,
on explicit permission from the previous publisher that added the old
one. The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
5. COMBINING DOCUMENTS You may combine the Document with
other documents released under this License, under the terms defined in
section 4 above for modified versions, provided that you include in the
combination all of the Invariant Sections of all of the original documents,
unmodified, and list them all as Invariant Sections of your combined work
in its license notice. The combined work need only contain one copy of
this License, and multiple identical Invariant Sections may be replaced
with a single copy. If there are multiple Invariant Sections with the
same name but different contents, make the title of each such section
unique by adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of Invariant
Sections in the license notice of the combined work. In the combination,
you must combine any sections entitled "History" in the various
original documents, forming one section entitled "History";
likewise combine any sections entitled "Acknowledgements", and
any sections entitled "Dedications". You must delete all sections
entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS You may make a collection
consisting of the Document and other documents released under this License,
and replace the individual copies of this License in the various documents
with a single copy that is included in the collection, provided that you
follow the rules of this License for verbatim copying of each of the documents
in all other respects. You may extract a single document from such a collection,
and distribute it individually under this License, provided you insert
a copy of this License into the extracted document, and follow this License
in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS A compilation of
the Document or its derivatives with other separate and independent documents
or works, in or on a volume of a storage or distribution medium, does
not as a whole count as a Modified Version of the Document, provided no
compilation copyright is claimed for the compilation. Such a compilation
is called an "aggregate", and this License does not apply to
the other self-contained works thus compiled with the Document, on account
of their being thus compiled, if they are not themselves derivative works
of the Document. If the Cover Text requirement of section 3 is applicable
to these copies of the Document, then if the Document is less than one
quarter of the entire aggregate, the Document's Cover Texts may be placed
on covers that surround only the Document within the aggregate. Otherwise
they must appear on covers around the whole aggregate.
8. TRANSLATION Translation is considered a kind of modification,
so you may distribute translations of the Document under the terms of
section 4. Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include translations
of some or all Invariant Sections in addition to the original versions
of these Invariant Sections. You may include a translation of this License
provided that you also include the original English version of this License.
In case of a disagreement between the translation and the original English
version of this License, the original English version will prevail.
9. TERMINATION You may not copy, modify, sublicense, or
distribute the Document except as expressly provided for under this License.
Any other attempt to copy, modify, sublicense or distribute the Document
is void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such parties
remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE The Free Software
Foundation may publish new, revised versions of the GNU Free Documentation
License from time to time. Such new versions will be similar in spirit
to the present version, but may differ in detail to address new problems
or concerns. See http://www.gnu.org/copyleft/. Each version of the License
is given a distinguishing version number. If the Document specifies that
a particular numbered version of this License "or any later version"
applies to it, you have the option of following the terms and conditions
either of that specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If the Document
does not specify a version number of this License, you may choose any
version ever published (not as a draft) by the Free Software Foundation.
Copyright (c) 1999, 2000 Aurora University, Christopher
Kolar. Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no Invariant
Sections, with no Front-Cover Texts specified, and with no Back-Cover
Texts specified. A copy of the license is included in the section entitled
"GNU Free Documentation License".
ckolar@admin.aurora.edu