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. Please note that a Manager's Quick Reference is available, and should help solve about 90% of list owners' problems.
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 your 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.
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 Mailman. The description content provides a brief description of each setting as well as guidelines for use when appropriate.
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.
| 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). |
| 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 not make changes to the list configuration, but can tend to pending administration requests, including approving or rejecting held subscription requests, and disposing of held postings. Of course, the list administrator can also tend to pending requests. |
| 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. |
| Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields) | This allows you to hide the sender of the message, so that the message is from the list. |
| Setting | Description |
|---|---|
| Should any existing Reply-To: header found in the original message be stripped? If so, this will be done regardless of whether an explicit Reply-To: header is added by Mailman or not. | This will remove any existing Reply-To: address in a message. |
| 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. |
| Setting | Description |
|---|---|
| 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? | When set to yes, list members will receive password reminders once a month. Note that members may disable their own individual password reminders. |
| Setting | Description |
|---|---|
| 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 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. |
| 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 enabled members leaving the list will receive a goodbye message |
| Should the list administrators get immediate notice of new requests, as well as daily notices about collected ones? | This setting dictates the frequency with which the list administrators (and 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. |
| Setting | Description |
|---|---|
| Emergency moderation of all list traffic | When this option is enabled, all list traffic is emergency moderated, i.e. held for moderation. Turn this option on when your list is experiencing a flamewar and you want a cooling off period. |
| Default options for new members joining this list | This defines the initial basic settings for new members joining the list. |
| (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.
If you do not wish to have a limit on the size of message, set this value to 0. |
| 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.) |
The passwords section allows list administrators and list moderators to change their list ownership passwords.
The membership management section allows you to do two things: add/remove users from your list, or adjust custom user settings.
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.
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 |
|---|---|
| unsub | If you check this box and then submit the changes on this page the user will be removed from the list. |
| mod | This is the user's personal moderation flag. If this is set, postings from them will be moderated, otherwise they will be approved. |
| 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 | This shows whether delivery of mail to the member has been disabled. An abbreviation will be given describing the reason for the disabled delivery:
|
| ack | Members may request that Mailman send a short acknowledgement when 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. |
| nodupes | This will allow users to avoid duplicates of the same message. |
| 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. |
Additional Member Tasks
The list owner can toggle on or off everyone's moderation bit, including those members not currently visible.
In this section the list owner can add subscribers to the list. Subscribers can be added automatically, or the list owner can send out an invitation to subscribe to the list. There is an option of whether to send a welcome message (defined in the General Options configuration category) when a person is added. An option of notifying the list owners of new subscribers is available. List owners can mass subscribe a list of addresses, or import a file that contains addresses the list owner wishes to subscribe. There is also an optional section where the list owner can add extra text to the subscription invitation or subscription notification.
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.
In this section the list owner can remove people from your list. The list owner has the option to send unsubscribe acknowledgements and notifications to list owners of people that have been unsubscribed. List owners can mass remove a list of addresses, or import a rule that contains addresses to be unsubscribed.
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. |
| How often should a new digest volume be started? | This allows you to set the timing of when a new digest volume is started |
| Should Mailman start a new digest volume? | Setting this option instructs Mailman to start a new volume with the next digest sent out. |
| Should Mailman send the next digest right now, if it is not empty? | This allows you to send the next digest immediately |
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.
| 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://lists.ucla.edu/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. |
| Is the list moderator's approval required for unsubscription requests? (No is recommended) | When members want to leave a list, they will make an unsubscription request, either via the web or via email. Normally it is best for you to allow open unsubscriptions so that users can easily remove themselves from mailing lists.
For some lists though, you may want to impose moderator approval before an unsubscription request is processed. Examples of such lists include a class mailing list that all students are required to be members of. |
| List of addresses which are banned from membership in this mailing list. | Addresses in this list are banned outright from subscribing to this mailing list, with no further moderation required. |
| 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 setting 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. |
When a message is posted to the list, a series of moderation steps are take to decide whether the moderator must first approve the message or not. This section contains the controls for moderation of both member and non-member postings.
Member postings are held for moderation if their moderation flag is turned on. You can control whether member postings are moderated by default or not.
Non-member postings can be automatically accepted, held for moderation, rejected (bounced), or discarded, either individually or as a group. Any posting from a non-member who is not explicitly accepted, rejected, or discarded, will have their posting filtered by the general non-member rules.
| Description | Value |
|---|---|
| By default, should new list member postings be moderated? | Each list member has a moderation flag which says whether messages from the list member can be posted directly to the list, or must first be approved by the list moderator. When the moderation flag is turned on, list member postings must be approved first. You, the list administrator, can decide whether a specific individual's postings will be moderated or not.
When a new member is subscribed, their initial moderation flag takes its value from this option. Turn this option off to accept member postings by default. Turn this option on to, by default, moderate member postings first. You can always manually set an individual member's moderation bit by using the membership management screens. |
| Action to take when a moderated member posts to the list. | You can specify one of three actions:
|
| List of non-member addresses whose postings should be automatically accepted. | Postings from any of these non-members will be automatically accepted with no further moderation applied. |
| List of non-member addresses whose postings will be immediately held for moderation. | Postings from any of these non-members will be immediately and automatically held for moderation by the list moderators. The sender will receive a notification message which will allow them to cancel their held message. |
| List of non-member addresses whose postings will be automatically rejected. | Postings from any of these non-members will be automatically rejected. In other words, their messages will be bounced back to the sender with a notification of automatic rejection. This option is not appropriate for known spam senders; their messages should be automatically discarded. |
| List of non-member addresses whose postings will be automatically discarded. | Postings from any of these non-members will be automatically discarded. That is, the message will be thrown away with no further processing or notification. The sender will not receive a notification or a bounce, however the list moderators can optionally receive copies of auto-discarded messages. |
| Action to take for postings from non-members for which no explicit action is defined. | When a post from a non-member is received, the message's sender is matched against the list of explicitly accepted, held, rejected (bounced), and discarded addresses. If no match is found, then this action is taken. |
| Should messages from non-members, which are automatically discarded, be forwarded to the list moderator? | If the list moderator wants to maintain a record of discarded posts, this option should be enabled. |
| Description | Value |
|---|---|
| Must posts have list named in destination (to, cc) field (or be among the acceptable alias names, specified below)? | Many (in fact, most) spams do not explicitly name their myriad destinations in the explicit destination addresses - in fact often the To: field has a totally bogus address for obfuscation. The constraint applies only to the stuff in the address before the '@' sign, but still catches all such spams.
The cost is that the list will not accept unhindered any postings relayed from other addresses, unless
|
| Alias names (regexps) which qualify as explicit to or cc destination names for this list. | Alternate addresses that are acceptable when `require_explicit_destination' is enabled. This option takes a list of regular expressions, one per line, which is matched against every recipient address in the message. The matching is performed with Python's re.match() function, meaning they are anchored to the start of the string.
For backwards compatibility with Mailman 1.1, if the regexp does not contain an `@', then the pattern is matched against just the local part of the recipient address. If that match fails, or if the pattern does contain an `@', then the pattern is matched against the entire recipient address. Matching against the local part is deprecated; in a future release, the pattern will always be matched against the entire recipient address. |
| Ceiling on acceptable number of recipients for a posting. | If a posting has this number, or more, of recipients, it is held for admin approval. Use 0 for no ceiling. |
Use this to prohibit posts according to specific header values. The target value is a regular-expression for matching against the specified header. The match is done disregarding letter case. Lines beginning with '#' are ignored as comments.
For example:
to: .*@public.com
says to hold all postings with a To: mail header containing '@public.com' anywhere among the addresses. Note that leading whitespace is trimmed from the regexp. This can be circumvented in a number of ways, e.g. by escaping or bracketing it.
When a bounce is received, Mailman tries to extract two pieces of information from the message: the address of the member the message was intended for, and the severity of the problem causing the bounce. The severity can be either hard or soft meaning either a fatal error occurred, or a transient error occurred. When in doubt, a hard severity is used.
If no member address can be extracted from the bounce, then the bounce is usually discarded. Otherwise, each member is assigned a bounce score and every time we encounter a bounce from this member we increment the score. Hard bounces increment by 1 while soft bounces increment by 0.5. We only increment the bounce score once per day, so even if we receive ten hard bounces from a member per day, their score will increase by only 1 for that day.
When a member's bounce score is greater than the bounce score threshold, the subscription is disabled. Once disabled, the member will not receive any postings from the list until their membership is explicitly re-enabled (either by the list administrator or the user). However, they will receive occasional reminders that their membership has been disabled, and these reminders will include information about how to re-enable their membership.
You can control both the number of reminders the member will receive and the frequency with which these reminders are sent.
There is one other important configuration variable; after a certain period of time -- during which no bounces from the member are received -- the bounce information is considered stale and discarded. Thus by adjusting this value, and the score threshold, you can control how quickly bouncing members are disabled. You should tune both of these to the frequency and traffic volume of your list.
| Value | Description |
|---|---|
| Should Mailman perform automatic bounce processing? | By setting this value to No, you disable all automatic bounce processing for this list, however bounce messages will still be discarded so that the list administrator isn't inundated with them. |
| The maximum member bounce score before the member's subscription is disabled. This value can be a floating point number. | The default value is 5.0. |
| The number of days after which a member's bounce information is discarded, if no new bounces have been received in the interim. This value must be an integer. | The default value is 7 |
| How many "Your Membership Is Disabled" warnings a disabled member should get before their address is removed from the mailing list. Set to 0 to immediately remove an address from the list once their bounce score exceeds the threshold. This value must be an integer. | The default value is 3. |
| The number of days between sending the Your Membership Is Disabled warnings. This value must be an integer. | The default value is 7. |
| Should Mailman send you, the list owner, any bounce messages that failed to be detected by the bounce processor? | While Mailman's bounce detector is fairly robust, it's impossible to detect every bounce format in the world. You should keep this variable set to Yes for two reasons: 1) If this really is a permanent bounce from one of your members, you should probably manually remove them from your list, and 2) you might want to send the message on to the Mailman developers so that this new format can be added to its known set.
If you really can't be bothered, then set this variable to No and all non-detected bounces will be discarded without further processing. Note: This setting will also affect all messages sent to your list's -admin address. This address is deprecated and should never be used, but some people may still send mail to this address. If this happens, and this variable is set to No those messages too will get discarded. You may want to set up an autoresponse message for email to the -owner and -admin address. |
| Should Mailman notify you, the list owner, when bounces cause a member's subscription to be disabled? | By setting this value to No, you turn off notification messages that are normally sent to the list owners when a member's delivery is disabled due to excessive bounces. An attempt to notify the member will always be made. |
| Should Mailman notify you, the list owner, when bounces cause a member to be unsubscribed? | By setting this value to No, you turn off notification messages that are normally sent to the list owners when a member is unsubscribed due to excessive bounces. An attempt to notify the member will always be made. |
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. |
| 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. |
The auto-responder 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. | 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. |
List owners can set policies concerning the content of list traffic.
Content filtering works like this: when a message is received by the list and you have enabled content filtering, the individual attachments are first compared to the filter types. If the attachment type matches an entry in the filter types, it is discarded.
Then, if there are pass types defined, any attachment type that does not match a pass type is also discarded. If there are no pass types defined, this check is skipped.
After this initial filtering, any multipart attachments that are empty are removed. If the outer message is left empty after this filtering, then the whole message is discarded. Then, each multipart/alternative section will be replaced by just the first alternative that is non-empty after filtering.
Finally, any text/html parts that are left in the message may be converted to text/plain if convert_html_to_plaintext is enabled and the site is configured to allow these conversions.
| Value | Description |
|---|---|
| Should Mailman filter the content of list traffic according to the settings below? | Default value is No, but if you wish to use content filtering select Yes. |
| Remove message attachments that have a matching content type. | Use this option to remove each message attachment that matches one of these content types. Each line should contain a string naming a MIME type/subtype, e.g. image/gif. Leave off the subtype to remove all parts with a matching major content type, e.g. image. Blank lines are ignored. |
| Remove message attachments that don't have a matching content type. Leave this field blank to skip this filter test. | Use this option to remove each message attachment that does not have a matching content type. Requirements and formats are exactly like filter_mime_types.
Note: if you add entries to this list but don't add multipart to this list, any messages with attachments will be rejected by the pass filter. |
| Should Mailman convert text/html parts to plain text? This conversion happens after MIME attachments have been stripped. | This option converts HTML to plain text so that older email clients can view the message. |
| Action to take when a message matches the content filtering rules. | One of these actions is take when the message matches one of the content filtering rules, meaning, the top-level content type matches one of the filter_mime_types, or the top-level content type does not match one of the pass_mime_types, or if after filtering the subparts of the message, the message ends up empty.
Note this action is not taken if after filtering the message still contains content. In that case the message is always forwarded on to the list membership. When messages are discarded, a log entry is written containing the Message-ID of the discarded message. When messages are rejected or forwarded to the list owner, a reason for the rejection is included in the bounce message to the original author. When messages are preserved, they are saved in a special queue directory on disk for the site administrator to view (and possibly rescue) but otherwise discarded. This last option is only available if enabled by the site administrator. |
| Value | Description |
|---|---|
| Should the topic filter be enabled or disabled? | The topic filter categorizes each incoming email message according to regular expression filters you specify below. If the message's Subject: or Keywords: header contains a match against a topic filter, the message is logically placed into a topic bucket. Each user can then choose to only receive messages from the mailing list for a particular topic bucket (or buckets). Any message not categorized in a topic bucket registered with the user is not delivered to the list.
Note that this feature only works with regular delivery, not digest delivery. The body of the message can also be optionally scanned for Subject: and Keywords: headers, as specified by the topics_bodylines_limit configuration variable. |
| How many body lines should the topic matcher scan? | The topic matcher will scan this many lines of the message body looking for topic keyword matches. Body scanning stops when either this many lines have been looked at, or a non-header-like body line is encountered. By setting this value to zero, no body lines will be scanned (i.e. only the Keywords: and Subject: headers will be scanned). By setting this value to a negative number, then all body lines will be scanned until a non-header-like line is encountered. |
| Topic keywords, one per line, to match against each message | Each topic keyword is actually a regular expression, which is matched against certain parts of a mail message, specifically the Keywords: and Subject: message headers. Note that the first few lines of the body of the message can also contain a Keywords: and Subject: "header" on which matching is also performed. |
In addition to the web-based access to list settings, Mailman provides three links at the top of each administrative page for "other" activities.
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.
When choosing the action you will have two additional options:
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.
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.
Following this link takes you the archives of the list. You can view each monthly archive by thread, subject, author, or date. You can also download an individual archive or the full archive.
This documentation is based on the GNU Mailman List Management Guide v 2.0 by Christopher Kolar and is covered under the GNU Free Documentation License