 |
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+ +
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
This document was generated using the LaTeX2HTML translator. @@ -75,33 +74,36 @@ October 2, 2004, Release 2.1
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
Barry A. Warsaw, Terri Oda
-terri (at) zone12.com
-Release 2.1
-October 2, 2004
- +
Barry A. Warsaw
+Release 2.1
+December 13, 2004
-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
Barry A. Warsaw, Terri Oda
-terri (at) zone12.com
-Release 2.1
-October 2, 2004
- +
Barry A. Warsaw
+Release 2.1
+December 13, 2004
-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-The General Options category is where you can set a variety of -variables that affect basic behavior and public information. In the -descriptions that follow, the variable name is given first, along with -an overview and a description of what that variable controls. +These variables, grouped under the general list personality section, +control some public information about the mailing list.
+
mylist in mylist@example.com. The posting
+ name is always presented in lower case, with alphanumeric
+ characters and no spaces. The list's real name is used in some
+ public information and email responses, such as in the general
+ list overview. The real name can differ from the posting name by
+ case only. For example, if the posting name is mylist, the
+ real name can be Posting.
-+
moderator addresses (see below).
+
++
owner addresses. For example, when
+ you email mylist-owner@example.com, both the owner and
+ moderator addresses will receive a copy of the message.
+
++
+
+
+
+ Subject: This is a message +
+and the subject_prefix is [My List] (note the
+ trailing space!), then the message will be received like so:
+
+
+
+ Subject: [My List] This is a message +
+If you leave subject_prefix empty, no prefix will be added
+ to the Subject:. Mailman is careful not to add a
+ prefix when the header already has one, as is the case in replies
+ for example. The prefix can also contain characters in the list's
+ preferred language. In this case, because of vagarities of the
+ email standards, you may or may not want to add a trailing space.
+
+
+
+Note that this option is simply an aid for anonymization, it + doesn't guarantee it. For example, a poster's identity could be + evident in their signature, or in other mail headers, or even in + the style of the content of the message. There's little Mailman + can do about this kind of identity leakage. +
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-These variables, grouped under the general list personality section, -control some public information about the mailing list. +This section controls what happens to the Reply-To: +headers of messages posted through your list.
-
mylist in mylist@example.com. The posting
- name is always presented in lower case, with alphanumeric
- characters and no spaces. The list's real name is used in some
- public information and email responses, such as in the general
- list overview. The real name can differ from the posting name by
- case only. For example, if the posting name is mylist, the
- real name can be Posting.
+Beware! Reply-To: munging is considered a religious issue
+and the policies you set here can ignite some of the most heated
+off-topic flame wars on your mailing lists. We'll try to stay as
+agnostic as possible, but our biases may still peak through.
-
moderator addresses (see below).
+Reply-To: is a header that is commonly used to redirect
+replies to messages. Exactly what happens when your uses reply to
+such a message depends on the mail readers your users use, and what
+functions they provide. Usually, there is both a ``reply to sender''
+button and a ``reply to all'' button. If people use these buttons
+correctly, you will probably never need to munge
+Reply-To:, so the default values should be fine.
-
owner addresses. For example, when
- you email mylist-owner@example.com, both the owner and
- moderator addresses will receive a copy of the message.
+Since an informed decision is always best, here are links to two
+articles that discuss the opposing viewpoints in great detail:
-
-
-
- Subject: This is a message -
-and the subject_prefix is [My List] (note the
- trailing space!), then the message will be received like so:
+If this option is set to No, then any existing
+ Reply-To: header will be retained in the posted
+ message. If Mailman adds its own header, it will contain
+ addresses which are the union of the original header and the
+ Mailman added addresses. The mail standards specify that a
+ message may only have one Reply-To: header, but that
+ that header may contain multiple addresses.
-
- Subject: [My List] This is a message -
+When you set this variable to Poster, no additional + Reply-To: header will be added by Mailman. This + setting is strongly recommended.
-If you leave subject_prefix empty, no prefix will be added
- to the Subject:. Mailman is careful not to add a
- prefix when the header already has one, as is the case in replies
- for example. The prefix can also contain characters in the list's
- preferred language. In this case, because of vagarities of the
- email standards, you may or may not want to add a trailing space.
+When you set this variable to This list, a
+ Reply-To: header pointing back to your list's posting
+ address will be added.
+
+
+When you set this variable to Explicit address, the value
+ of the variable reply_to_address (see below) will be
+ added. Note that this is one situation where
+ Reply-To: munging may have a legitimate purpose. Say
+ you have two lists at your site, an announce list and a discussion
+ list. The announce list might allow postings only from a small
+ number of approved users; the general list membership probably
+ can't post to this list. But you want to allow comments on
+ announcements to be posted to the general discussion list by any
+ list member. In this case, you can set the Reply-To:
+ header for the announce list to point to the discussion list's
+ posting address.
-Note that this option is simply an aid for anonymization, it - doesn't guarantee it. For example, a poster's identity could be - evident in their signature, or in other mail headers, or even in - the style of the content of the message. There's little Mailman - can do about this kind of identity leakage. +
reply_goes_to_list is set
+ to Explicit address.
+
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-This section controls what happens to the Reply-To: -headers of messages posted through your list. - -
-Beware! Reply-To: munging is considered a religious issue -and the policies you set here can ignite some of the most heated -off-topic flame wars on your mailing lists. We'll try to stay as -agnostic as possible, but our biases may still peak through. - -
-Reply-To: is a header that is commonly used to redirect -replies to messages. Exactly what happens when your uses reply to -such a message depends on the mail readers your users use, and what -functions they provide. Usually, there is both a ``reply to sender'' -button and a ``reply to all'' button. If people use these buttons -correctly, you will probably never need to munge -Reply-To:, so the default values should be fine. - -
-Since an informed decision is always best, here are links to two -articles that discuss the opposing viewpoints in great detail: - -
- -
- --The three options in this section work together to provide enough -flexibility to do whatever Reply-To: munging you might -(misguidingly :) feel you need to do. - -
-
-If this option is set to No, then any existing - Reply-To: header will be retained in the posted - message. If Mailman adds its own header, it will contain - addresses which are the union of the original header and the - Mailman added addresses. The mail standards specify that a - message may only have one Reply-To: header, but that - that header may contain multiple addresses. - -
-
-When you set this variable to Poster, no additional - Reply-To: header will be added by Mailman. This - setting is strongly recommended. - -
-When you set this variable to This list, a - Reply-To: header pointing back to your list's posting - address will be added. - -
-When you set this variable to Explicit address, the value
- of the variable reply_to_address (see below) will be
- added. Note that this is one situation where
- Reply-To: munging may have a legitimate purpose. Say
- you have two lists at your site, an announce list and a discussion
- list. The announce list might allow postings only from a small
- number of approved users; the general list membership probably
- can't post to this list. But you want to allow comments on
- announcements to be posted to the general discussion list by any
- list member. In this case, you can set the Reply-To:
- header for the announce list to point to the discussion list's
- posting address.
-
-
-
reply_goes_to_list is set
- to Explicit address.
-
--
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-TBD. Note that umbrella lists are deprecated and will be replace with -a better mechanism for Mailman 3.0. +Mailman sends notifications to the list administrators or list members +under a number of different circumstances. Most of these +notifications can be configured in this section, but see the Bounce +Processing and Auto-responder categories for other notifications that +Mailman can send. + +
+
+Some people get annoyed with these monthly reminders, and they can
+ disable the reminders via their subscription options page. For
+ some lists, the monthly reminders aren't appropriate for any of
+ the members, so you can disable them list-wide by setting the
+ send_reminders variable to No.
+
+
+
welcome_msg
+ text box. Note that because this text is sent as part of an
+ email, it should not contain HTML.
+
++
+
welcome_msg, a ``goodbye'' message can be sent to
+ members when they unsubscribe from the list. Unlike the welcome
+ message, there's no boilerplate for the goodbye message. Enter
+ the entire goodbye message you'd like unsubscribing members to
+ receive into the goodbye_msg text box.
+
++
+
admin_immed_notify variable controls whether these
+ immediate notifications are sent or not. It's generally a good
+ idea to leave this set to Yes.
+
++
+
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Mailman sends notifications to the list administrators or list members -under a number of different circumstances. Most of these -notifications can be configured in this section, but see the Bounce -Processing and Auto-responder categories for other notifications that -Mailman can send. +This section contains some miscellaneous settings for your mailing +list.
-Some people get annoyed with these monthly reminders, and they can
- disable the reminders via their subscription options page. For
- some lists, the monthly reminders aren't appropriate for any of
- the members, so you can disable them list-wide by setting the
- send_reminders variable to No.
+
-
welcome_msg
- text box. Note that because this text is sent as part of an
- email, it should not contain HTML.
+This variable presents a set of checkboxes which control the
+ defaults for some of the member options. Conceal the
+ member's address specifies whether or not the address is
+ displayed in the list roster. Acknowledge the member's
+ posting controls whether or not Mailman sends an acknowledgement
+ to a member when they post a message to the list. Do not
+ send a copy of a member's own post specifies whether a member
+ posting to the list will get a copy of their own posting.
+ Filter out duplicate messages to list members (if possible)
+ specifies whether members who are explicitly listed as a recipient
+ of a message (e.g. via the Cc: header) will also get a
+ copy from Mailman.
-
welcome_msg, a ``goodbye'' message can be sent to
- members when they unsubscribe from the list. Unlike the welcome
- message, there's no boilerplate for the goodbye message. Enter
- the entire goodbye message you'd like unsubscribing members to
- receive into the goodbye_msg text box.
+-request address for the
+ list. Setting this to Yes helps prevent such things as
+ unsubscribe messages getting erroneously posted to the list.
-
admin_immed_notify variable controls whether these
- immediate notifications are sent or not. It's generally a good
- idea to leave this set to Yes.
+
example.com part of
+ the posting address mylist@example.com.
+
++It's generally not a good idea to change this value, since its + default value is specified when the mailing list is created. + Changing this to an incorrect value could make it difficult to + contact your mailing list. Also not that the url used to visit + the list's pages is not configurable through the web interface. + This is because if you messed it up, you'd have to have the site + administrator fix it.
List-* headers.
+
++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.
List-* headers.)
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-This section contains some miscellaneous settings for your mailing -list. - -
-
-
-This variable presents a set of checkboxes which control the - defaults for some of the member options. Conceal the - member's address specifies whether or not the address is - displayed in the list roster. Acknowledge the member's - posting controls whether or not Mailman sends an acknowledgement - to a member when they post a message to the list. Do not - send a copy of a member's own post specifies whether a member - posting to the list will get a copy of their own posting. - Filter out duplicate messages to list members (if possible) - specifies whether members who are explicitly listed as a recipient - of a message (e.g. via the Cc: header) will also get a - copy from Mailman. - -
-Of course, members can always override these defaults by making - changes on their membership options page. - -
-
-request address for the
- list. Setting this to Yes helps prevent such things as
- unsubscribe messages getting erroneously posted to the list.
-
--If a message seems to contain administrivia, it is held for - moderator approval. - -
-
-
example.com part of
- the posting address mylist@example.com.
-
--It's generally not a good idea to change this value, since its - default value is specified when the mailing list is created. - Changing this to an incorrect value could make it difficult to - contact your mailing list. Also not that the url used to visit - the list's pages is not configurable through the web interface. - This is because if you messed it up, you'd have to have the site - administrator fix it. - -
-
List-* headers.
+-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. +The list owner has total control over the configuration of their +mailing list (within some bounds as specified by the site +administrator). Note that on this page, for historical reasons, the +list owner role is described here as the list administrator. +You can set the list owner's password by entering it in the password +field on the left. You must type it twice for confirmation. Note +that if you forget this password, the only way for you to get back +into your list's administrative pages is to ask the site administrator +to reset it for you (there's no password reminders for list owners).
-
List-* headers.)
-moderator variable in the
+General options category page.
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+However, if your site administrator has enabled its support, you can +set your list up to support any of about two dozen languages, such as +German, Italian, Japanese, or Spanish. Your list members can then +choose any of your supported languages as their preferred +language for interacting with the list. Such things as their member +options page will be displayed in this language. Each mailing list +also has its own preferred language which is the language the +list supports if no other language context is known. + +
+These variables control the language settings for your mailing list: + +
+
available_languages variable.
+
++
preferred_language variable.
-The list owner has total control over the configuration of their -mailing list (within some bounds as specified by the site -administrator). Note that on this page, for historical reasons, the -list owner role is described here as the list administrator. -You can set the list owner's password by entering it in the password -field on the left. You must type it twice for confirmation. Note -that if you forget this password, the only way for you to get back -into your list's administrative pages is to ask the site administrator -to reset it for you (there's no password reminders for list owners). +
subject_prefix contains non-ASCII
+ characters, the prefix will always be encoded according to the
+ relevant standards. However, if your subject prefix contains only
+ ASCII characters, you may want to set this option to Never
+ to disable prefix encoding. This can make the subject headers
+ slightly more readable for users with mail readers that don't
+ properly handle non-ASCII encodings.
-If you want to delegate list moderation to someone else, you can enter
-a different moderator password in the field on the right (typed twice
-for confirmation). Note that if you aren't going to delegate
-moderation, and the same people are going to both configure the list
-and moderate postings to the list, don't enter anything into the
-moderator password fields. If you do enter a separate moderator
-password, be sure to fill in the moderator variable in the
-General options category page.
+Note however, that if your mailing list receives both encoded and
+ unencoded subject headers, you might want to choose As
+ needed. Using this setting, Mailman will not encode ASCII
+ prefixes when the rest of the header contains only ASCII
+ characters, but if the original header contains non-ASCII
+ characters, it will encode the prefix. This avoids an ambiguity
+ in the standards which could cause some mail readers to display
+ extra, or missing spaces between the prefix and the original
+ header.
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-However, if your site administrator has enabled its support, you can -set your list up to support any of about two dozen languages, such as -German, Italian, Japanese, or Spanish. Your list members can then -choose any of your supported languages as their preferred -language for interacting with the list. Such things as their member -options page will be displayed in this language. Each mailing list -also has its own preferred language which is the language the -list supports if no other language context is known. - -
-These variables control the language settings for your mailing list: - -
-
available_languages variable.
-
--
preferred_language variable.
-
subject_prefix contains non-ASCII
- characters, the prefix will always be encoded according to the
- relevant standards. However, if your subject prefix contains only
- ASCII characters, you may want to set this option to Never
- to disable prefix encoding. This can make the subject headers
- slightly more readable for users with mail readers that don't
- properly handle non-ASCII encodings.
+The Membership Management category is unlike the other
+administrative categories. It doesn't contain configuration variables
+or list settings. Instead, it presents a number of pages that allow
+you to manage the membership of you list. This includes pages for
+subscribing and unsubscribing members, and for searching for members,
+and for changing various member-specific settings.
-Note however, that if your mailing list receives both encoded and - unencoded subject headers, you might want to choose As - needed. Using this setting, Mailman will not encode ASCII - prefixes when the rest of the header contains only ASCII - characters, but if the original header contains non-ASCII - characters, it will encode the prefix. This avoids an ambiguity - in the standards which could cause some mail readers to display - extra, or missing spaces between the prefix and the original - header. -
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-The Membership Management category is unlike the other -administrative categories. It doesn't contain configuration variables -or list settings. Instead, it presents a number of pages that allow -you to manage the membership of you list. This includes pages for -subscribing and unsubscribing members, and for searching for members, -and for changing various member-specific settings. +Mailman delivers messages to users via two modes. List members can +elect to receive postings in bundles call digests one or a few +times a day, or they can receive messages immediately whenever the +message is posted to the list. This latter delivery mode is also +called non-digest delivery. There are two administrative +categories available for separately controlling digest and non-digest +delivery. You can even disable one or the other forms of delivery +(but not both).
-More details on membership management are described in the Membership -Management section. +Both kinds of delivery can have list-specific headers and footers +added to them which can contain other useful information you want your +list members to see. For example, you can include instructions for +unsubscribing, or a url to the lists digest, or any other information.
+Non-digest deliveries can also be personalized which means +certain parts of the message can contain information tailored to the +member receiving the message. For example, the To: header +will contain the address of the member when deliveries are +personalized. Footers and headers can contain personalized +information as well, such as a link to the individual user's options +page. +
+In addition, personalized messages will contain extra information that +Mailman can use to unambiguously track bounces from members. +Ordinarily, Mailman does some pattern recognition on bounce messages +to determine list members whose addresses are no longer valid, but +because of the vagaries of mail systems, and the countless forwards +people can put in place, it's often the case that bounce messages +don't contain any useful information in them. Personalized messages +avoid this problem by encoding information in certain headers that +unambiguously identify the recipient of a message. If that message +bounces, Mailman will know exactly which member it was intended for. + +
+Note that because personalization requires extra system resources, it +must be enabled by the site administrator before you can choose it. + +
+Here are the variables which control non-digest delivery: + +
+
+
+
+See below for more information on what can go in the headers and + footers. If you leave this text box empty, no header will be + added. + +
+
+Headers and footers can contain any text you want. For non-English
+lists, the headers and footers can contain any character in the
+character set of the list's preferred language. The headers and
+footers can also contain substitution variables which Mailman
+will fill in with information taken from the mailing list. These
+substitutions are in Python string interpolation format, where
+something like %(list_name)s is substituted with he name of
+the mailing list. Note that the trailing "s" is
+required2.
+
+
+For example, a footer containing the following text: + +
+
+This is the \%(list_name)s mailing list +Description: \%(description)s +
+might get attached to postings like so: + +
+
+This is the Example mailing list +Description: An example of Mailman mailing lists +
+Here is the list of substitution variables available for your headers +and footers: + +
+
real_name configuration variable
+ in the General options category.
+
++
+
+
listinfo/%(list_name)s to yield the
+ general list information page for the mailing list.
+
++
+
+
.cgi, or something else depending on how your site
+ is configured.
+
+Note that real_name, host_name, description, and
+info substitution variables take their values from the list
+configuration variables of the same name.
+
+
+When personalization is enabled, the following substitution variables +are also available: + +
+
+
+
+
+
+
$list_name or
+${list_name} would be substituted with the mailing list's
+name. Ask your site administrator if the've configured your list this
+way.
+
+_internal_name is
+ equivalent.
+
+user_address and user_delivered_to is used, but it's
+ important to remember that they can be different. When they're
+ different, Mailman always uses the lower case address as the key
+ to the member's subscription information, but it always delivers
+ messages to the case-preserved version.
+
+ |
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Mailman delivers messages to users via two modes. List members can -elect to receive postings in bundles call digests one or a few -times a day, or they can receive messages immediately whenever the -message is posted to the list. This latter delivery mode is also -called non-digest delivery. There are two administrative -categories available for separately controlling digest and non-digest -delivery. You can even disable one or the other forms of delivery -(but not both). +Digest delivery is a way to bundle many articles together into one +package, which can be delivered once per day (if there were any posted +articles), or whenever the package is bigger than a specified limit. +Some users may prefer this style of delivery for higher traffic lists +since they will receive fewer messages.
-Both kinds of delivery can have list-specific headers and footers -added to them which can contain other useful information you want your -list members to see. For example, you can include instructions for -unsubscribing, or a url to the lists digest, or any other information. +Mailman supports two standard digest formats, and if digests are +enabled, users can select which of the two formats they receive. One +is MIME digests, where each message is an attachment inside a +multipart/digest. This format also contains a summary +table of contents, and of course the an optional header and footer, +and it retains most of the headers of the original messages.
-Non-digest deliveries can also be personalized which means -certain parts of the message can contain information tailored to the -member receiving the message. For example, the To: header -will contain the address of the member when deliveries are -personalized. Footers and headers can contain personalized -information as well, such as a link to the individual user's options -page. +The second type is called ``plaintext'' digests because they are +readable in mail readers that don't support MIME. Actually, they +adhere to the RFC 1153 digest standard. The retain some, but not +all of the original messages, but can also include a summary and +headers and footers.
-In addition, personalized messages will contain extra information that -Mailman can use to unambiguously track bounces from members. -Ordinarily, Mailman does some pattern recognition on bounce messages -to determine list members whose addresses are no longer valid, but -because of the vagaries of mail systems, and the countless forwards -people can put in place, it's often the case that bounce messages -don't contain any useful information in them. Personalized messages -avoid this problem by encoding information in certain headers that -unambiguously identify the recipient of a message. If that message -bounces, Mailman will know exactly which member it was intended for. +Like non-digest delivery, you can enable or disable digest delivery, +but you cannot disable both types of delivery. You can specify +different headers and footers for digest and non-digest deliveries. +You cannot personalize digest deliveries.
-Note that because personalization requires extra system resources, it -must be enabled by the site administrator before you can choose it. +As list administrator, you may want to send an urgent message to all +list members, bypassing the normal digest bundling. To do this, send +the message with a Urgent: header, where the value of the +header is the list administrator's password. Non-digest members will +receive the message like normal, but digest members will receive the +message immediately5.
-Here are the variables which control non-digest delivery: +Here are the variables which control digest delivery:
-
-See below for more information on what can go in the headers and - footers. If you leave this text box empty, no header will be - added. +
-Headers and footers can contain any text you want. For non-English
-lists, the headers and footers can contain any character in the
-character set of the list's preferred language. The headers and
-footers can also contain substitution variables which Mailman
-will fill in with information taken from the mailing list. These
-substitutions are in Python string interpolation format, where
-something like %(list_name)s is substituted with he name of
-the mailing list. Note that the trailing "s" is
-required2.
-
-
-For example, a footer containing the following text: - -
-
-This is the \%(list_name)s mailing list -Description: \%(description)s -
-might get attached to postings like so: - -
-
-This is the Example mailing list -Description: An example of Mailman mailing lists -
-Here is the list of substitution variables available for your headers -and footers: - -
-
real_name configuration variable
- in the General options category.
+
digest_size_threshold.
listinfo/%(list_name)s to yield the
- general list information page for the mailing list.
-
--
-
-
.cgi, or something else depending on how your site
- is configured.
-
-Note that real_name, host_name, description, and
-info substitution variables take their values from the list
-configuration variables of the same name.
-
-
-When personalization is enabled, the following substitution variables -are also available: - -
-
msg_header, except for the personalization variables.
$list_name or
-${list_name} would be substituted with the mailing list's
-name. Ask your site administrator if the've configured your list this
-way.
-
-_internal_name is
- equivalent.
-
-user_address and user_delivered_to is used, but it's
- important to remember that they can be different. When they're
- different, Mailman always uses the lower case address as the key
- to the member's subscription information, but it always delivers
- messages to the case-preserved version.
+ |
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Digest delivery is a way to bundle many articles together into one
-package, which can be delivered once per day (if there were any posted
-articles), or whenever the package is bigger than a specified limit.
-Some users may prefer this style of delivery for higher traffic lists
-since they will receive fewer messages.
+The Privacy category lets you control how much of the list's
+information is public, as well as who can send messages to your list.
+It also contains some spam detection filters. Note that this section
+is not used to control whether your list's archives are public or
+private; for that, use the
-Mailman supports two standard digest formats, and if digests are -enabled, users can select which of the two formats they receive. One -is MIME digests, where each message is an attachment inside a -multipart/digest. This format also contains a summary -table of contents, and of course the an optional header and footer, -and it retains most of the headers of the original messages. +There are four sub-categories: -
-The second type is called ``plaintext'' digests because they are -readable in mail readers that don't support MIME. Actually, they -adhere to the RFC 1153 digest standard. The retain some, but not -all of the original messages, but can also include a summary and -headers and footers. +
-Like non-digest delivery, you can enable or disable digest delivery, -but you cannot disable both types of delivery. You can specify -different headers and footers for digest and non-digest deliveries. -You cannot personalize digest deliveries. +
-As list administrator, you may want to send an urgent message to all -list members, bypassing the normal digest bundling. To do this, send -the message with a Urgent: header, where the value of the -header is the list administrator's password. Non-digest members will -receive the message like normal, but digest members will receive the -message immediately5. +
-Here are the variables which control digest delivery: +
-
-
-
-
-
digest_size_threshold.
+
+-
msg_header, except for the personalization variables.
+
+-
-
-
-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-The Privacy category lets you control how much of the list's
-information is public, as well as who can send messages to your list.
-It also contains some spam detection filters. Note that this section
-is not used to control whether your list's archives are public or
-private; for that, use the
-There are four sub-categories: - -
-
-
-
-The sender, recipient, and spam filtering rules are part of the -general list moderation features of Mailman. When a message is posted -to the list, it is matched against a number of criteria, the outcome -of which determines whether the message is reflected to the membership -or not. In general, the outcome is one of four states: +
-join@example.com, Mailman
+ will send a confirmation message to the requesting address.
+ This mail-back confirmation contains a unique identifier,
+ which the requester can present to Mailman in order to
+ confirm their subscription. This can be done either by
+ replying to the mail-back, or by visiting the url in the
+ mail-back message. The url points to a page that lets the
+ user either discard or confirm their request.
-Many of the fields in this section are text boxes accepting addresses, -one per line. Unless otherwise noted, these also accept regular -expressions which will be matched against an address, if the line -begins with a (caret) character. +
+
+
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-This subcategory controls the rules for exposing the existance of this -list, and for what new members must do in order to subscribe to the -list. +When a message is posted to the list, a series of moderation criteria are +applied to determine the disposition of the message. This section +contains the modeation controls for postings from both members and +non-members.
-
+E-newsletter style lists can also be set up by using the
+ moderation flag. By setting the member_moderation_action
+ to Reject, and by turning off the moderation flag for just
+ the few approved senders, your list will operate in essentially a
+ one-way direction. Note that you'd also need to reject or discard
+ postings from non-members.
-
+
+Note that when a moderated member posts to your list, and the
+ member_moderation_action is set to Hold, the message
+ will appear on the administrative requests page. When you dispose
+ of the message, you will be given an opportunity to clear the
+ moderation flag at the same time. If you're quarantining new
+ posts, this makes it very convenient to both approve a new
+ member's post and de-moderate them at the same time.
- -
-join@example.com, Mailman
- will send a confirmation message to the requesting address.
- This mail-back confirmation contains a unique identifier,
- which the requester can present to Mailman in order to
- confirm their subscription. This can be done either by
- replying to the mail-back, or by visiting the url in the
- mail-back message. The url points to a page that lets the
- user either discard or confirm their request.
+member_moderation_action is Reject, this variable
+ contains the text sent in the rejection notice.
+- -
-
-
discard_these_nonmembers, or because
+ generic_nonmember_action is Discard, you can choose
+ whether such messages are forwarded to the lsit administrators or
+ not.
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-When a message is posted to the list, a series of moderation criteria are -applied to determine the disposition of the message. This section -contains the modeation controls for postings from both members and -non-members. +The variables in this section control various filters based on the +recipient of the message.
-You can control whether new members get their moderation flag - turned on or off by default when they subscribe to the list. By - turning this flag off by default, postings by members will be - allowed without further intervention (barring other restrictions - such as size or implicit recipient lists - see below). By - turning the flag on, you can quarantine new member postings to - make sure that they meet your criteria for netiquette, topicality, - etc. Once you determine that the new member understands the - community's posting rules, you can turn off their moderation flag - and let their postings go through unstopped. - -
-E-newsletter style lists can also be set up by using the
- moderation flag. By setting the member_moderation_action
- to Reject, and by turning off the moderation flag for just
- the few approved senders, your list will operate in essentially a
- one-way direction. Note that you'd also need to reject or discard
- postings from non-members.
-
-
-
-Note that when a moderated member posts to your list, and the
- member_moderation_action is set to Hold, the message
- will appear on the administrative requests page. When you dispose
- of the message, you will be given an opportunity to clear the
- moderation flag at the same time. If you're quarantining new
- posts, this makes it very convenient to both approve a new
- member's post and de-moderate them at the same time.
+
-
member_moderation_action is Reject, this variable
- contains the text sent in the rejection notice.
--The next batch of variables controls what happens when non-members -post messages to the list. Each of these accepts one email address -per line; regular expressions are allowed if the line starts with the -(caret) character. These address lists are always consulted in the -order in which they're presented on this page (i.e. accepts first, -followed by holds, rejections, and discards). - -
-
-
-
-
require_explicit_destination is
+ enabled. This is useful for when there aliases for the main
+ posting address (e.g. help@example.com may be an alias for
+ help-list@example.com).
discard_these_nonmembers, or because
- generic_nonmember_action is Discard, you can choose
- whether such messages are forwarded to the lsit administrators or
- not.
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-The variables in this section control various filters based on the -recipient of the message. +This section provides some adjuncts to spam fighting tools; it +doesn't replace dedicated anti-spam tools such as SpamAssassin or +Spambayes.
-If the list is not explicitly addressed and this setting is turned - on, the message will be held for moderator approval. +This variable can be used to catch known spammers by writing + regexps that match against To: or Cc: + lines, or known-bad Message-ID:s. Perhaps more useful + though are patterns that match headers added by spam detection + tools higher up in the tool chain. For example, you might + configure SpamAssassin to add an X-Spam-Score: header + with between zero and 5 stars depending on the spam score. Then + you can add a line to this variable like:
-
require_explicit_destination is
- enabled. This is useful for when there aliases for the main
- posting address (e.g. help@example.com may be an alias for
- help-list@example.com).
+
+ X-Spam-Score: [*]{3,5}
+-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-This section provides some adjuncts to spam fighting tools; it -doesn't replace dedicated anti-spam tools such as SpamAssassin or -Spambayes. +These policies control the automatic bounce processing system in +Mailman. Here's an overview of how it works: + +
+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 for fatal errors, or +soft for transient errors. When in doubt, a hard severity is +used. + +
+If no member address can be extracted from the bounce, then the bounce +message is usually discarded. Every member has a bounce score, +initialized at zero, and every time we encounter a bounce from a +member we increment that member's 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 (see below), the member's 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.
-This variable can be used to catch known spammers by writing - regexps that match against To: or Cc: - lines, or known-bad Message-ID:s. Perhaps more useful - though are patterns that match headers added by spam detection - tools higher up in the tool chain. For example, you might - configure SpamAssassin to add an X-Spam-Score: header - with between zero and 5 stars depending on the spam score. Then - you can add a line to this variable like: +
-
- X-Spam-Score: [*]{3,5}
--This line will match from 3 to 5 stars in the value of this - field. +
+
+
+
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-These policies control the automatic bounce processing system in -Mailman. Here's an overview of how it works: - -
-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 for fatal errors, or -soft for transient errors. When in doubt, a hard severity is -used. - -
-If no member address can be extracted from the bounce, then the bounce -message is usually discarded. Every member has a bounce score, -initialized at zero, and every time we encounter a bounce from a -member we increment that member's 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 (see below), the member's 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. +Mailman comes with a built-in web-based archiver called +Pipermail, although it can be configured to use external, +third party archivers.
-
-
-
-
-
No (case insensitive), then the message will not be
+ archived, although it will be treated as normal in all other
+ ways.
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Mailman comes with a built-in web-based archiver called -Pipermail, although it can be configured to use external, -third party archivers. - -
-
-Note that senders can control whether their own posts are
- archived, on an individual per-message basis. If the posted
- message has a X-No-Archive: header (regardless of
- value), or a X-Archive: header with a value of
- No (case insensitive), then the message will not be
- archived, although it will be treated as normal in all other
- ways.
-
-
-
-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Mailman has a sophisticated mail-to-news gateway feature. It can -independently gate messages from news to mail and vice versa, and can -even be used to manage moderated newsgroups. - -
-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Warning: This documentation is not yet complete. It is known to be missing -sections and hasn't been proofread completely yet. However, I'm putting it -online anyhow because some questions have come up on the lists which are -answered in here. +GNU Mailman is software that lets you manage electronic mailing lists. +It supports a wide range of mailing list types, such as general +discussion lists and announce-only lists. Mailman has extensive +features for controlling the privacy of your lists, distributing your +list as personalized postings or digests, gatewaying postings to and +from Usenet, and providing automatic bounce detection. Mailman +provides a built-in archiver, multiple natural languages, as well as +advanced content and topic filtering. + +
+Mailman provides several interfaces to its functionality. Most list +administrators will primarily use the web interface to customize their +lists. There is also a limited email command interface to the +administrative functions, as well as a command line interface if you +have shell access on the Mailman server. This document does not cover +the command line interface; see the GNU Mailman site administrator's +manual for more details.
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+ +
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+To create an appendix in a Python HOWTO document, use markup like +this: + +
+
+\appendix
+
+\section{This is an Appendix}
+
+To create an appendix in a Python HOWTO document, ....
+
+
+\section{This is another}
+
+Just add another \section{}, but don't say \appendix again.
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
+Every mailing list has a set of email addresses that messages can be +sent to. There's always one address for posting messages to the list, +one address that bounces will be sent to, and addresses for processing +email commands. For example, for a mailing list called +mylist@example.com, you'd find these addresses: + +
+ +
+
+
-GNU Mailman is software that lets you manage electronic mailing lists. -It supports a wide range of mailing list types, such as general -discussion lists and announce-only lists. Mailman has extensive -features for controlling the privacy of your lists, distributing your -list as personalized postings or digests, gatewaying postings to and -from Usenet, and providing automatic bounce detection. Mailman -provides a built-in archiver, multiple natural languages, as well as -advanced content and topic filtering. +
-Mailman provides several interfaces to its functionality. Most list -administrators will primarily use the web interface to customize their -lists. There is also a limited email command interface to the -administrative functions, as well as a command line interface if you -have shell access on the Mailman server. This document does not cover -the command line interface; see the GNU Mailman site administrator's -manual for more details. +
+
+
+There's also an -admin address which also reaches the list +administrators, but this address only exists for compatibility with +older versions of Mailman. + +
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Every mailing list has a set of email addresses that messages can be -sent to. There's always one address for posting messages to the list, -one address that bounces will be sent to, and addresses for processing -email commands. For example, for a mailing list called -mylist@example.com, you'd find these addresses: - -
- -
-
-
-
-
-
-
-There's also an -admin address which also reaches the list -administrators, but this address only exists for compatibility with -older versions of Mailman. +In the sections that follow, we'll often use the terms list owner and +list administrator interchangably, meaning both roles. When +necessary, we'll distinguish the list moderator explicitly.
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-There are two primary administrative roles for each mailing list, a -list owner and a list moderator. A list owner is allowed to change -various settings of the list, such as the privacy and archiving -policies, the content filtering settings, etc. The list owner is also -allowed to subscribe or invite members, unsubscribe members, and -change any member's subscription options. +Every mailing list is also accessible by a number of web pages. Note +that the exact urls is configurable by the site administrator, so they +may be different than what's described below. We'll describe the most +common default configuration, but check with your site administrator +or hosting service for details. + +
+Mailman provides a set of web pages that list members use to get +information about the list, or manage their membership options. There +are also list archive pages, for browsing an online web-based archive +of the list traffic. These are described in more detail in the GNU +Mailman user's manual.
-The list moderator on the other hand, is only allowed to approve or -reject postings and subscription requests. The list moderator can -also do things like clear a member's moderation flag, or add an -address to a list of approved non-member posters. +Mailman also provides a set of pages for configuring an individual +list, as well as a set of pages for disposing of posting and +subscription requests.
-Normally, the list owner and list moderator are the same person. In
-fact, the list owner can always do all the tasks a list moderator can
-do. Access to both the owner's configuration pages, and the
-moderation pages are protected by the same password. However, if the
-list owner wants to delegate posting and subscription approval
-authority to other people, a separate list moderator password can be
-set, giving moderators access to the approval pages, but not the
-configuration pages. In this setup, list owners can still moderate
-the list, of course.
+For a mailing list called mylist hosted at the domain
+lists.example.com, you would typically access the administrative
+pages by going to http://lists.example.com/mailman/admin/mylist.
+The first time you visit this page, you will be presented with a login
+page, asking for the list owner's password. When you enter the
+password, Mailman will store a session cookie in your browser, so you
+don't have to re-authenticate for every action you want to take. This
+cookie is stored only until you exit your browser.
-In the sections that follow, we'll often use the terms list owner and
-list administrator interchangably, meaning both roles. When
-necessary, we'll distinguish the list moderator explicitly.
+To access the administrative requests page, you'd visit
+http://lists.example.com/mailman/admindb/mylist (note the
+admindb url as opposed to the admin url). Again, the
+first time you visit this page, you'll be presented with a login page,
+on which you can enter either the list moderator password or the list
+owner password. Again, a session cookie is dropped in your browser.
+Note also that if you've previously logged in as the list owner, you
+do not need to re-login to access the administrative requests page.
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-Every mailing list is also accessible by a number of web pages. Note -that the exact urls is configurable by the site administrator, so they -may be different than what's described below. We'll describe the most -common default configuration, but check with your site administrator -or hosting service for details. +This section will outline the basic architecture of GNU Mailman, such +as how messages are processed by the sytem. Without going into lots +of detail, this information will help you understand how the +configuration options control Mailman's functionality.
-Mailman provides a set of web pages that list members use to get -information about the list, or manage their membership options. There -are also list archive pages, for browsing an online web-based archive -of the list traffic. These are described in more detail in the GNU -Mailman user's manual. +When mail enters the system from your mail server, it is dropped into +one of several Mailman queues depending on the address the +message was sent to. For example, if your system has a mailing list +named mylist and your domain is example.com, people can +post messages to your list by sending them to +mylist@example.com. These messages will be dropped into the +incoming queue, which is also colloquially called the +moderate-and-munge queue. The incoming queue is where most of +the approval process occurs, and it's also where the message is +prepared for sending out to the list membership.
-Mailman also provides a set of pages for configuring an individual -list, as well as a set of pages for disposing of posting and -subscription requests. +There are separate queues for the built-in archiver, the bounce +processor, the email command processor, as well as the outgoing email +and news queues. There's also a queue for messages generated by the +Mailman system. Each of these queues typically has one queue +runner (or ``qrunner'') that processes messages in the queue. The +qrunners are idle when there are no messages to process.
-For a mailing list called mylist hosted at the domain
-lists.example.com, you would typically access the administrative
-pages by going to http://lists.example.com/mailman/admin/mylist.
-The first time you visit this page, you will be presented with a login
-page, asking for the list owner's password. When you enter the
-password, Mailman will store a session cookie in your browser, so you
-don't have to re-authenticate for every action you want to take. This
-cookie is stored only until you exit your browser.
+Every message in the queues are represented by two files, a message
+file and a metadata file. Both of these files share the same base
+name, which is a combination of a unique hash and the Unix time that
+the message was received. The metadata file has a suffix of
+.db and the message file has a suffix of either .msg if
+stored in plain text, or .pck if stored in a more efficient
+internal representation1.
-To access the administrative requests page, you'd visit
-http://lists.example.com/mailman/admindb/mylist (note the
-admindb url as opposed to the admin url). Again, the
-first time you visit this page, you'll be presented with a login page,
-on which you can enter either the list moderator password or the list
-owner password. Again, a session cookie is dropped in your browser.
-Note also that if you've previously logged in as the list owner, you
-do not need to re-login to access the administrative requests page.
+As a message moves through the incoming queue, it performs various
+checks on the message, such as whether it matches one of the
+moderation criteria, or contains disallowed MIME types. Once a
+message is approved for sending to the list membership, the message is
+prepared for sending by deleting, adding, or changing message headers,
+adding footers, etc. Messages in the incoming queue may also be
+stored for appending to digests.
+
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-This section will outline the basic architecture of GNU Mailman, such -as how messages are processed by the sytem. Without going into lots -of detail, this information will help you understand how the -configuration options control Mailman's functionality. +After logging into the list configuration pages, you'll see the +configuration options for the list, grouped in categories. All the +administrative pages have some common elements. In the upper section, +you'll see two columns labeled ``Configuration Categories''. Some +categories have sub-categories which are only visible when you click +on the category link. The first page you see after logging in will be +the ``General Options'' category. The specific option settings for +each category are described below.
-When mail enters the system from your mail server, it is dropped into -one of several Mailman queues depending on the address the -message was sent to. For example, if your system has a mailing list -named mylist and your domain is example.com, people can -post messages to your list by sending them to -mylist@example.com. These messages will be dropped into the -incoming queue, which is also colloquially called the -moderate-and-munge queue. The incoming queue is where most of -the approval process occurs, and it's also where the message is -prepared for sending out to the list membership. +On the right side of the top section, you'll see a column labeled +``Other Administrative Activities''. Here you'll find some other +things you can do to your list, as well as convenient links to the +list information page and the list archives. Note the big ``Logout'' +link; use this if you're finished configuring your list and don't want +to leave the session cookie active in your browser.
-There are separate queues for the built-in archiver, the bounce -processor, the email command processor, as well as the outgoing email -and news queues. There's also a queue for messages generated by the -Mailman system. Each of these queues typically has one queue -runner (or ``qrunner'') that processes messages in the queue. The -qrunners are idle when there are no messages to process. +Below this common header, you'll find a list of this category's +configuration variables, arranged in two columns. In the left column +is a brief description of the option, which also contains a +``details'' link. For many of the variables, more details are +available describing the semantics of the various available settings, +or information on the interaction between this setting and other list +options. Clicking on the details link brings up a page which contains +only the information for that option, as well as a button for +submitting your setting, and a link back to the category page.
-Every message in the queues are represented by two files, a message -file and a metadata file. Both of these files share the same base -name, which is a combination of a unique hash and the Unix time that -the message was received. The metadata file has a suffix of -.db and the message file has a suffix of either .msg if -stored in plain text, or .pck if stored in a more efficient -internal representation1. +On the right side of the two-column section, you'll see the variable's +current value. Some variables may present a limited set of values, +via radio button or check box arrays. Other variables may present +text entry boxes of one or multiple lines. Most variables control +settings for the operation of the list, but others perform immediate +actions (these are clearly labeled).
-As a message moves through the incoming queue, it performs various -checks on the message, such as whether it matches one of the -moderation criteria, or contains disallowed MIME types. Once a -message is approved for sending to the list membership, the message is -prepared for sending by deleting, adding, or changing message headers, -adding footers, etc. Messages in the incoming queue may also be -stored for appending to digests. +At the bottom of the page, you'll find a ``Submit'' button and a +footer with some more useful links and a few logos. Hitting the +submit button commits your list settings, after they've been +validated. Any invalid values will be ignored and an error message +will be displayed at the top of the resulting page. The results page +will always be the category page that you submitted.
-
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |
-After logging into the list configuration pages, you'll see the -configuration options for the list, grouped in categories. All the -administrative pages have some common elements. In the upper section, -you'll see two columns labeled ``Configuration Categories''. Some -categories have sub-categories which are only visible when you click -on the category link. The first page you see after logging in will be -the ``General Options'' category. The specific option settings for -each category are described below. - -
-On the right side of the top section, you'll see a column labeled -``Other Administrative Activities''. Here you'll find some other -things you can do to your list, as well as convenient links to the -list information page and the list archives. Note the big ``Logout'' -link; use this if you're finished configuring your list and don't want -to leave the session cookie active in your browser. +
-Below this common header, you'll find a list of this category's -configuration variables, arranged in two columns. In the left column -is a brief description of the option, which also contains a -``details'' link. For many of the variables, more details are -available describing the semantics of the various available settings, -or information on the interaction between this setting and other list -options. Clicking on the details link brings up a page which contains -only the information for that option, as well as a button for -submitting your setting, and a link back to the category page. +The General Options category is where you can set a variety of +variables that affect basic behavior and public information. In the +descriptions that follow, the variable name is given first, along with +an overview and a description of what that variable controls.
-On the right side of the two-column section, you'll see the variable's -current value. Some variables may present a limited set of values, -via radio button or check box arrays. Other variables may present -text entry boxes of one or multiple lines. Most variables control -settings for the operation of the list, but others perform immediate -actions (these are clearly labeled). -
-At the bottom of the page, you'll find a ``Submit'' button and a -footer with some more useful links and a few logos. Hitting the -submit button commits your list settings, after they've been -validated. Any invalid values will be ignored and an error message -will be displayed at the top of the resulting page. The results page -will always be the category page that you submitted. - -
- -
|
- |
- |
+ |
+ |
+ |
GNU Mailman - List Administration Manual | - |
- |
- |
+ |
+ |
+ |