The General Options Section pertains to the fundamental list characteristics, including descriptive info and basic behaviors.

General list personality 
The public name of this list (make case-changes only). real_name (general): The public name of this list (make case-changes only).

The capitalization of this name can be changed to make it presentable in polite company as a proper noun, or to make an acronym part all upper case, etc. However, the name will be advertised as the email address (e.g., in subscribe confirmation notices), so it should not be otherwise altered. (Email addresses are not case sensitive, but they are sensitive to almost everything else :-) 
The list administrator email addresses. Multiple administrator addresses, each on separate line is okay. owner (general): The list administrator email addresses. Multiple administrator addresses, each on separate line is okay.

There are two ownership roles associated with each mailing list. The list administrators are the people who have ultimate control over all parameters of this mailing list. They are able to change any list configuration variable available through these administration web pages.

The list moderators have more limited permissions; they are not able to change any list configuration variable, but they are allowed to tend to pending administration requests, including approving or rejecting held subscription requests, and disposing of held postings. Of course, the list administrators can also tend to pending requests.

In order to split the list ownership duties into administrators and moderators, you must set a separate moderator password, and also provide the email addresses of the list moderators. Note that the field you are changing here specifies the list administrators.
The list moderator email addresses. Multiple moderator addresses, each on separate line is okay. moderator (general): The list moderator email addresses. Multiple moderator addresses, each on separate line is okay.

There are two ownership roles associated with each mailing list. The list administrators are the people who have ultimate control over all parameters of this mailing list. They are able to change any list configuration variable available through these administration web pages.

The list moderators have more limited permissions; they are not able to change any list configuration variable, but they are allowed to tend to pending administration requests, including approving or rejecting held subscription requests, and disposing of held postings. Of course, the list administrators can also tend to pending requests.

In order to split the list ownership duties into administrators and moderators, you must set a separate moderator password, and also provide the email addresses of the list moderators in this section. Note that the field you are changing here specifies the list moderators.
 A terse phrase identifying this list. description (general): A terse phrase identifying this list.

This description is used when the mailing list is listed with other mailing lists, or in headers, and so forth. It should be as succinct as you can get it, while still identifying what the list is.
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 - see the details for more info. info (general): 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 - see the details for more info.

The text will be treated as html except that newlines will be translated to <br> - so you can use links, preformatted text, etc, but don't put in carriage returns except where you mean to separate paragraphs. And review your changes - bad html (like some unterminated HTML constructs) can prevent display of the entire listinfo page.
Prefix for subject line of list postings. subject_prefix (general): Prefix for subject line of list postings.

This text will be prepended to subject lines of messages posted to the list, to distinguish mailing list messages in in mailbox summaries. Brevity is premium here, it's ok to shorten long mailing list names to something more concise, as long as it still identifies the mailing list. You can also add a sequencial number by %d substitution directive. eg.; [listname %d] -> [listname 123] (listname %05d) -> (listname 00123)
Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields) anonymous_list (general): Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields)
Reply-To: header munging
Should any existing Reply-To: header found in the original message be stripped? If so, this will be done regardless of whether an explict Reply-To: header is added by Mailman or not. first_strip_reply_to (general): Should any existing Reply-To: header found in the original message be stripped? If so, this will be done regardless of whether an explict Reply-To: header is added by Mailman or not.
Where are replies to list messages directed? Poster is strongly recommended for most mailing lists. reply_goes_to_list (general): Where are replies to list messages directed? Poster is strongly recommended for most mailing lists.

This option controls what Mailman does to the Reply-To: header in messages flowing through this mailing list. When set to Poster, no Reply-To: header is added by Mailman, although if one is present in the original message, it is not stripped. Setting this value to either This list or Explicit address causes Mailman to insert a specific Reply-To: header in all messages, overriding the header in the original message if necessary (Explicit address inserts the value of reply_to_address).

There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful for a general discussion of this issue. See Reply-To Munging Considered Useful for a dissenting opinion.

Some mailing lists have restricted posting privileges, with a parallel list devoted to discussions. Examples are `patches' or `checkin' lists, where software changes are posted by a revision control system, but discussion about the changes occurs on a developers mailing list. To support these types of mailing lists, select Explicit address and set the Reply-To: address below to point to the parallel list.
Explicit Reply-To: header. reply_to_address (general): Explicit Reply-To: header.

This is the address set in the Reply-To: header when the reply_goes_to_list option is set to Explicit address.

There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful for a general discussion of this issue. See Reply-To Munging Considered Useful for a dissenting opinion.

Some mailing lists have restricted posting privileges, with a parallel list devoted to discussions. Examples are `patches' or `checkin' lists, where software changes are posted by a revision control system, but discussion about the changes occurs on a developers mailing list. To support these types of mailing lists, specify the explicit Reply-To: address here. You must also specify Explicit address in the reply_goes_to_list variable.

Note that if the original message contains a Reply-To: header, it will not be changed.
Umbrella list settings
Send password reminders to, eg, "-owner" address instead of directly to user. umbrella_list (general): Send password reminders to, eg, "-owner" address instead of directly to user.

Set this to yes when this list is intended to cascade only to other mailing lists. When set, meta notices like confirmations and password reminders will be directed to an address derived from the member's address - it will have the value of "umbrella_member_suffix" appended to the member's account name.
Suffix for use when this list is an umbrella for other lists, according to setting of previous "umbrella_list" setting. umbrella_member_suffix (general): Suffix for use when this list is an umbrella for other lists, according to setting of previous "umbrella_list" setting.

When "umbrella_list" is set to indicate that this list has other mailing lists as members, then administrative notices like confirmations and password reminders need to not be sent to the member list addresses, but rather to the owner of those member lists. In that case, the value of this setting is appended to the member's account name for such notices. `-owner' is the typical choice. This setting has no effect when "umbrella_list" is "No".
Notifications
Send monthly password reminders? send_reminders (general): Send monthly password reminders?

Turn this on if you want password reminders to be sent once per month to your members. Note that members may disable their own individual password reminders.
List-specific text prepended to new-subscriber welcome message welcome_msg (general): List-specific text prepended to new-subscriber welcome message

This value, if any, will be added to the front of the new-subscriber welcome message. The rest of the welcome message already describes the important addresses and URLs for the mailing list, so you don't need to include any of that kind of stuff here. This should just contain mission-specific kinds of things, like etiquette policies or team orientation, or that kind of thing.

Note that this text will be wrapped, according to the following rules:
  • Each paragraph is filled so that no line is longer than 70 characters.
  • Any line that begins with whitespace is not filled.
  • A blank line separates paragraphs.
Send welcome message to newly subscribed members? send_welcome_msg (general): Send welcome message to newly subscribed members?

Turn this off only if you plan on subscribing people manually and don't want them to know that you did so. This option is most useful for transparently migrating lists from some other mailing list manager to Mailman.
Text sent to people leaving the list. If empty, no special text will be added to the unsubscribe message. goodbye_msg (general): Text sent to people leaving the list. If empty, no special text will be added to the unsubscribe message.
Send goodbye message to members when they are unsubscribed? send_goodbye_msg (general): Send goodbye message to members when they are unsubscribed?
Should the list moderators get immediate notice of new requests, as well as daily notices about collected ones? admin_immed_notify (general): Should the list moderators get immediate notice of new requests, as well as daily notices about collected ones?

List moderators (and list administrators) are sent daily reminders of requests pending approval, like subscriptions to a moderated list, or postings that are being held for one reason or another. Setting this option causes notices to be sent immediately on the arrival of new requests as well.
Should administrator get notices of subscribes and unsubscribes? admin_notify_mchanges (general): Should administrator get notices of subscribes and unsubscribes?
Send mail to poster when their posting is held for approval? respond_to_post_requests (general): Send mail to poster when their posting is held for approval?
Additional settings
Emergency moderation of all list traffic. emergency (general): 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. new_member_options (general): Default options for new members joining this list.

When a new member is subscribed to this list, their initial set of options is taken from the this variable's setting.
(Administrivia filter) Check postings and intercept ones that seem to be administrative requests? administrivia (general): (Administrivia filter) Check postings and intercept ones that seem to be administrative requests?

Administrivia tests will check postings to see whether it's really meant as an administrative request (like subscribe, unsubscribe, etc), and will add it to the the administrative requests queue, notifying the administrator of the new request, in the process.
Maximum length in kilobytes (KB) of a message body. Use 0 for no limit. max_message_size (general): Maximum length in kilobytes (KB) of a message body. Use 0 for no limit.
Host name this list prefers for email. host_name(general): Host name this list prefers for email.

The "host_name" is the preferred name for email to mailman-related addresses on this host, and generally should be the mail host's exchanger address, if any. This setting can be useful for selecting among alternative names of a host that has multiple addresses.

Should messages from this mailing list include the RFC 2369 (i.e. List-*) headers? Yes is highly recommended. include_rfc2369_headers (general): 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? include_list_post_header (general): 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.)

Discard held messages older than this number of days. Use 0 for no automatic discarding. max_days_to_hold (general): Discard held messages older than this number of days. Use 0 for no automatic discarding.

Specials

Tired of Mailbox Size Issues?
Get Hosted Exchange
Now with 100GB Mailboxes
Ask about our Free Migration Offer


Need Email Archiving?
Get StarMaille
Email Archiving and Protection