path: root/mailman/kunder.py

## "kunder" mailing list configuration settings -*- python -*-
## captured on Thu Jun  5 08:58:41 2003

## General options
#
# Fundamental list characteristics, including descriptive info and basic
# behaviors.

# 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 :-)
real_name = 'Kunder'

# 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.
owner = ['jonas@bitbase.dk']

# 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.
moderator = []

# 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.
description = 'Kunder ved Bitbase (til annonceringer)'

# 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.
info = """Kunder ved Bitbase (til annonceringer)

Denne liste er til annonceringer til (dansk-talende) kunder ved Bitbase, f.eks. ved ændringer af services eller driftsforstyrrelser.

Listen er lukket for tilmelding, og kun Bitbase administratorer kan sende til den.

Arkivet er offentligt tilgængeligt."""

# 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.
subject_prefix = '[Bitbase] '

# Hide the sender of a message, replacing it with the list address
# (Removes From, Sender and Reply-To fields)
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
anonymous_list = 1

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
first_strip_reply_to = 0

# 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 <a href="?VARHELP=general/reply_to_address">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 <a
# href="http://www.unicom.com/pw/reply-to-harmful.html">`Reply-To'
# Munging Considered Harmful for a general discussion of this issue.
# See <a
# href="http://www.metasystema.org/essays/reply-to-useful.mhtml">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.
#
# legal values are:
#    0 = "Poster"
#    1 = "This list"
#    2 = "Explicit address"
reply_goes_to_list = 2

# This is the address set in the Reply-To: header when the <a
# href="?VARHELP=general/reply_goes_to_list">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 <a
# href="http://www.unicom.com/pw/reply-to-harmful.html">`Reply-To'
# Munging Considered Harmful for a general discussion of this issue.
# See <a
# href="http://www.metasystema.org/essays/reply-to-useful.mhtml">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.
reply_to_address = 'teknik@bitbase.dk'

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
umbrella_list = 0

# 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".
umbrella_member_suffix = '-owner'

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
send_reminders = 0

# 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.
# 
welcome_msg = ''

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
send_welcome_msg = 1

# Text sent to people leaving the list.  If empty, no special text will
# be added to the unsubscribe message.
goodbye_msg = ''

# Send goodbye message to members when they are unsubscribed?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
send_goodbye_msg = 1

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
admin_immed_notify = 1

# Should administrator get notices of subscribes and unsubscribes?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
admin_notify_mchanges = 1

# Approval notices are sent when mail triggers certain of the limits
# except routine list moderation and spam filters, for which notices are
# not sent.  This option overrides ever sending the notice.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
respond_to_post_requests = 1

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
emergency = 0

# When a new member is subscribed to this list, their initial set of
# options is taken from the this variable's setting.
new_member_options = 256

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
administrivia = 1

# Maximum length in kilobytes (KB) of a message body.  Use 0 for no
# limit.
max_message_size = 40

# 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.
host_name = 'bitbase.dk'

# 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).
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
include_rfc2369_headers = 1

# 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.)
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
include_list_post_header = 1

## Language options
#
# Natural language (internationalization) options.

# This is the default natural language for this mailing list. If more
# than one language is supported then users will be able to select their
# own preferences for when they interact with the list.  All other
# interactions will be conducted in the default language.  This applies
# to both web-based and email-based messages, but not to email posted by
# list members.
preferred_language = 'en'

# These are all the natural languages supported by this list. Note that
# the default language must be included.
available_languages = ['en']

# If your mailing list's default language uses a non-ASCII character set
# and the prefix contains non-ASCII characters, the prefix will always
# be encoded according to the relevant standards.  However, if your
# 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.
# 
# 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.
#
# legal values are:
#    0 = "Never"
#    1 = "Always"
#    2 = "As needed"
encode_ascii_prefixes = 0

## Nondigest options
#
# Policies concerning immediately delivered list traffic.

# Can subscribers choose to receive mail immediately, rather than in
# batched digests?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
nondigestable = 1

# Text prepended to the top of every immediately-delivery message. This
# text can include Python format strings which are resolved against list
# attributes.  The list of substitutions allowed are:
# 
# 
# real_name - The `pretty' name of the list; usually the list name with
# capitalization.
# 
# list_name - The name by which the list is identified in URLs, where
# case is significant.  (For backwards compability, _internal_name is
# equivalent.)
# 
# host_name - The fully qualified domain name that the list server runs
# on.
# 
# web_page_url - The base URL for Mailman.  This can be appended with,
# e.g. listinfo/%(internal_name)s to yield the listinfo page for the
# mailing list.
# 
# description - The brief description of the mailing list.
# 
# info - The full description of the mailing list.
# 
# cgiext - The extension added to CGI scripts.
# 
# 
msg_header = ''

# Text appended to the bottom of every immediately-delivery message.
# This text can include Python format strings which are resolved against
# list attributes.  The list of substitutions allowed are:
# 
# 
# real_name - The `pretty' name of the list; usually the list name with
# capitalization.
# 
# list_name - The name by which the list is identified in URLs, where
# case is significant.  (For backwards compability, _internal_name is
# equivalent.)
# 
# host_name - The fully qualified domain name that the list server runs
# on.
# 
# web_page_url - The base URL for Mailman.  This can be appended with,
# e.g. listinfo/%(internal_name)s to yield the listinfo page for the
# mailing list.
# 
# description - The brief description of the mailing list.
# 
# info - The full description of the mailing list.
# 
# cgiext - The extension added to CGI scripts.
# 
# 
msg_footer = """_______________________________________________
%(real_name)s mailing list
%(real_name)s@%(host_name)s
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s"""

## Digest options
#
# Batched-delivery digest characteristics.

# Can list members choose to receive list traffic bunched in digests?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
digestable = 0

# Which delivery mode is the default for new users?
#
# legal values are:
#    0 = "Regular"
#    1 = "Digest"
digest_is_default = 0

# When receiving digests, which format is default?
#
# legal values are:
#    0 = "Plain"
#    1 = "MIME"
mime_is_default_digest = 1

# How big in Kb should a digest be before it gets sent out?
digest_size_threshhold = 30

# Should a digest be dispatched daily when the size threshold isn't
# reached?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
digest_send_periodic = 1

# Text attached (as an initial message, before the table of contents) to
# the top of digests. This text can include Python format strings which
# are resolved against list attributes.  The list of substitutions
# allowed are:
# 
# 
# real_name - The `pretty' name of the list; usually the list name with
# capitalization.
# 
# list_name - The name by which the list is identified in URLs, where
# case is significant.  (For backwards compability, _internal_name is
# equivalent.)
# 
# host_name - The fully qualified domain name that the list server runs
# on.
# 
# web_page_url - The base URL for Mailman.  This can be appended with,
# e.g. listinfo/%(internal_name)s to yield the listinfo page for the
# mailing list.
# 
# description - The brief description of the mailing list.
# 
# info - The full description of the mailing list.
# 
# cgiext - The extension added to CGI scripts.
# 
# 
digest_header = ''

# Text attached (as a final message) to the bottom of digests. This text
# can include Python format strings which are resolved against list
# attributes.  The list of substitutions allowed are:
# 
# 
# real_name - The `pretty' name of the list; usually the list name with
# capitalization.
# 
# list_name - The name by which the list is identified in URLs, where
# case is significant.  (For backwards compability, _internal_name is
# equivalent.)
# 
# host_name - The fully qualified domain name that the list server runs
# on.
# 
# web_page_url - The base URL for Mailman.  This can be appended with,
# e.g. listinfo/%(internal_name)s to yield the listinfo page for the
# mailing list.
# 
# description - The brief description of the mailing list.
# 
# info - The full description of the mailing list.
# 
# cgiext - The extension added to CGI scripts.
# 
# 
digest_footer = """_______________________________________________
%(real_name)s mailing list
%(real_name)s@%(host_name)s
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s"""

# When a new digest volume is started, the volume number is incremented
# and the issue number is reset to 1.
#
# legal values are:
#    0 = "Yearly"
#    1 = "Monthly"
#    2 = "Quarterly"
#    3 = "Weekly"
#    4 = "Daily"
digest_volume_frequency = 1

## Privacy options
#
# This section allows you to configure subscription and membership
# exposure policy.  You can also control whether this list is public or
# not.  See also the <a
# href="http://mail.bitbase.dk/mailman/admin/kunder/archive">Archival
# Options</a> section for separate archive-related privacy settings.

# Advertise this list when people ask what lists are on this machine?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
advertised = 1

# Confirm (*) - email confirmation required Require approval - require
# list administrator approval for subscriptions Confirm and approve -
# both confirm and approve
# 
# (*) when someone requests a subscription, Mailman sends them a notice
# with a unique subscription request number that they must reply to in
# order to subscribe. This prevents mischievous (or malicious) people
# from creating subscriptions for others without their consent.
#
# legal values are:
#    1 = "Confirm"
#    2 = "Require approval"
#    3 = "Confirm and approve"
subscribe_policy = 2

# 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 (they get really upset if they can't get
# off lists!).
# 
# For some lists though, you may want to impose moderator approval
# before an unsubscription request is processed.  Examples of such lists
# include a corporate mailing list that all employees are required to be
# members of.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
unsubscribe_policy = 0

# Addresses in this list are banned outright from subscribing to this
# mailing list, with no further moderation required.  Add addresses one
# per line; start the line with a ^ character to designate a regular
# expression match.
ban_list = []

# When set, the list of subscribers is protected by member or admin
# password authentication.
#
# legal values are:
#    0 = "Anyone"
#    1 = "List members"
#    2 = "List admin only"
private_roster = 1

# Setting this option causes member email addresses to be transformed
# when they are presented on list web pages (both in text and as links),
# so they're not trivially recognizable as email addresses.  The
# intention is to prevent the addresses from being snarfed up by
# automated web scanners for use by spammers.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
obscure_addresses = 1

## Privacy options
#
# When a message is posted to the list, a series of moderation steps are
# take to decide whether the a moderator must first approve the message
# or not.  This section contains the controls for moderation of both
# member and non-member postings.
# 
# <p>Member postings are held for moderation if their <b>moderation
# flag</b> is turned on.  You can control whether member postings are
# moderated by default or not.
# 
# <p>Non-member postings can be automatically <a
# href="?VARHELP=privacy/sender/accept_these_nonmembers" >accepted</a>,
# <a href="?VARHELP=privacy/sender/hold_these_nonmembers">held for
# moderation</a>, <a
# href="?VARHELP=privacy/sender/reject_these_nonmembers" >rejected</a>
# (bounced), or <a
# href="?VARHELP=privacy/sender/discard_these_nonmembers"
# >discarded</a>, 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 <a
# href="?VARHELP=privacy/sender/generic_nonmember_action">general
# non-member rules</a>.
# 
# <p>In the text boxes below, add one address per line; start the line
# with a ^ character to designate a <a href=
# "http://www.python.org/doc/current/lib/module-re.html" >Python regular
# expression</a>.  When entering backslashes, do so as if you were using
# Python raw strings (i.e. you generally just use a single backslash).
# 
# <p>Note that non-regexp matches are always done first.

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
default_member_moderation = 1

# Hold -- this holds the message for approval by the list moderators.
# 
# Reject -- this automatically rejects the message by sending a bounce
# notice to the post's author.  The text of the bounce notice can be <a
# href="?VARHELP=privacy/sender/member_moderation_notice" >configured by
# you.
# 
# Discard -- this simply discards the message, with no notice sent to
# the post's author.
# 
#
# legal values are:
#    0 = "Hold"
#    1 = "Reject"
#    2 = "Discard"
member_moderation_action = 0

# Text to include in any <a
# href="?VARHELP/privacy/sender/member_moderation_action" >rejection
# notice to be sent to moderated members who post to this list.
member_moderation_notice = ''

# Postings from any of these non-members will be automatically accepted
# with no further moderation applied.  Add member addresses one per
# line; start the line with a ^ character to designate a regular
# expression match.
accept_these_nonmembers = ['jonas@bitbase.dk', 'jonas@jones.dk']

# 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.  Add member addresses one per line; start the line
# with a ^ character to designate a regular expression match.
hold_these_nonmembers = []

# 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 <a
# href="?VARHELP=privacy/sender/discard_these_nonmembers" >automatically
# discarded.
# 
# Add member addresses one per line; start the line with a ^ character
# to designate a regular expression match.
reject_these_nonmembers = []

# 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
# <a href="?VARHELP=privacy/sender/forward_auto_discards" >receive
# copies of auto-discarded messages..
# 
# Add member addresses one per line; start the line with a ^ character
# to designate a regular expression match.
discard_these_nonmembers = []

# When a post from a non-member is received, the message's sender is
# matched against the list of explicitly <a
# href="?VARHELP=privacy/sender/accept_these_nonmembers" >accepted,
# held, <a href="?VARHELP=privacy/sender/reject_these_nonmembers"
# >rejected (bounced), and <a
# href="?VARHELP=privacy/sender/discard_these_nonmembers" >discarded
# addresses.  If no match is found, then this action is taken.
#
# legal values are:
#    0 = "Accept"
#    1 = "Hold"
#    2 = "Reject"
#    3 = "Discard"
generic_nonmember_action = 1

# Should messages from non-members, which are automatically discarded,
# be forwarded to the list moderator?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
forward_auto_discards = 1

## Privacy options
#
# This section allows you to configure various filters based on the
# recipient of the message.

# 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
# 
# 
# The relaying address has the same name, or
# 
# The relaying address name is included on the options that specifies
# acceptable aliases for the list.
# 
# 
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
require_explicit_destination = 1

# 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.
acceptable_aliases = ''

# If a posting has this number, or more, of recipients, it is held for
# admin approval.  Use 0 for no ceiling.
max_num_recipients = 10

## Privacy options
#
# This section allows you to configure various anti-spam filters posting
# filters, which can help reduce the amount of spam your list members
# end up receiving.
# 

# Use this option 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.
bounce_matching_headers = """# Lines that *start* with a '#' are comments.
to: friend@public.com
message-id: relay.comanche.denmark.eu
from: list@listme.com
from: .*@uplinkpro.com"""

## Bounce options
#
# These policies control the automatic bounce processing system in
# Mailman.  Here's an overview of how it works.
# 
# <p>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 <em>hard</em> or <em>soft</em> meaning
# either a fatal error occurred, or a transient error occurred.  When in
# doubt, a hard severity is used.
# 
# <p>If no member address can be extracted from the bounce, then the
# bounce is usually discarded.  Otherwise, each member is assigned a
# <em>bounce score</em> 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.
# 
# <p>When a member's bounce score is greater than the <a
# href="?VARHELP=bounce/bounce_score_threshold">bounce score
# threshold</a>, 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.
# 
# <p>You can control both the <a
# href="?VARHELP=bounce/bounce_you_are_disabled_warnings">number of
# reminders</a> the member will receive and the <a
# href="?VARHELP=bounce/bounce_you_are_disabled_warnings_interval"
# >frequency</a> with which these reminders are sent.
# 
# <p>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 <a
# href="?VARHELP=bounce/bounce_info_stale_after">considered stale</a>
# 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.

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
bounce_processing = 1

# The maximum member bounce score before the member's subscription is
# disabled.  This value can be a floating point number.
bounce_score_threshold = 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.
bounce_info_stale_after = 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.
bounce_you_are_disabled_warnings = 3

# The number of days between sending the Your Membership Is Disabled
# warnings.  This value must be an integer.
bounce_you_are_disabled_warnings_interval = 7

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
bounce_unrecognized_goes_to_list_owner = 1

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
bounce_notify_owner_on_disable = 1

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
bounce_notify_owner_on_removal = 1

## Archive options
#
# List traffic archival policies.

# Archive messages?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
archive = 1

# Is archive file source for public or private archival?
#
# legal values are:
#    0 = "public"
#    1 = "private"
archive_private = 0

# How often should a new archive volume be started?
#
# legal values are:
#    0 = "Yearly"
#    1 = "Monthly"
#    2 = "Quarterly"
#    3 = "Weekly"
#    4 = "Daily"
archive_volume_frequency = 2

## Gateway options
#
# Mail-to-News and News-to-Mail gateway services.

# The News server is not part of Mailman proper.  You have to already
# have access to a NNTP server, and that NNTP server has to recognize
# the machine this mailing list runs on as a machine capable of reading
# and posting news.
nntp_host = ''

# The name of the Usenet group to gateway to and/or from.
linked_newsgroup = ''

# Should new posts to the mailing list be sent to the newsgroup?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
gateway_to_news = 0

# Should new posts to the newsgroup be sent to the mailing list?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
gateway_to_mail = 0

# This setting determines the moderation policy of the newsgroup and its
# interaction with the moderation policy of the mailing list.  This only
# applies to the newsgroup that you are gatewaying to, so if you are
# only gatewaying from Usenet, or the newsgroup you are gatewaying to is
# not moderated, set this option to None.
# 
# If the newsgroup is moderated, you can set this mailing list up to be
# the moderation address for the newsgroup.  By selecting Moderated, an
# additional posting hold will be placed in the approval process.  All
# messages posted to the mailing list will have to be approved before
# being sent on to the newsgroup, or to the mailing list membership.
# 
# Note that if the message has an Approved header with the list's
# administrative password in it, this hold test will be bypassed,
# allowing privileged posters to send messages directly to the list and
# the newsgroup.
# 
# Finally, if the newsgroup is moderated, but you want to have an open
# posting policy anyway, you should select Open list, moderated group.
# The effect of this is to use the normal Mailman moderation facilities,
# but to add an Approved header to all messages that are gatewayed to
# Usenet.
#
# legal values are:
#    0 = "None"
#    1 = "Open list, moderated group"
#    2 = "Moderated"
news_moderation = 0

# Mailman prefixes Subject: headers with text you can customize and
# normally, this prefix shows up in messages gatewayed to Usenet.  You
# can set this option to No to disable the prefix on gated messages.  Of
# course, if you turn off normal Subject: prefixes, they won't be
# prefixed for gated messages either.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
news_prefix_subject_too = 1

## Autoreply options
#
# Auto-responder characteristics.<p>
# 
# In the text fields below, string interpolation is performed with the
# following key/value substitutions: <p><ul> <li><b>listname</b> -
# <em>gets the name of the mailing list</em> <li><b>listurl</b> -
# <em>gets the list's listinfo URL</em> <li><b>requestemail</b> -
# <em>gets the list's -request address</em> <li><b>owneremail</b> -
# <em>gets the list's -owner address</em> </ul>
# 
# <p>For each text field, you can either enter the text directly into
# the text box, or you can specify a file on your local system to upload
# as the text.

# Should Mailman send an auto-response to mailing list posters?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
autorespond_postings = 0

# Auto-response text to send to mailing list posters.
autoresponse_postings_text = ''

# Should Mailman send an auto-response to emails sent to the -owner
# address?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
autorespond_admin = 0

# Auto-response text to send to -owner emails.
autoresponse_admin_text = ''

# 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.
#
# legal values are:
#    0 = "No"
#    1 = "Yes, w/discard"
#    2 = "Yes, w/forward"
autorespond_requests = 0

# Auto-response text to send to -request emails.
autoresponse_request_text = ''

# Number of days between auto-responses to either the mailing list or
# -request/-owner address from the same poster.  Set to zero (or
# negative) for no grace period (i.e. auto-respond to every message).
autoresponse_graceperiod = 90

## Contentfilter options
#
# Policies concerning the content of list traffic.
# 
# <p>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 <a
# href="?VARHELP=contentfilter/filter_mime_types">filter types</a>.  If
# the attachment type matches an entry in the filter types, it is
# discarded.
# 
# <p>Then, if there are <a
# href="?VARHELP=contentfilter/pass_mime_types">pass types</a> defined,
# any attachment type that does <em>not</em> match a pass type is also
# discarded.  If there are no pass types defined, this check is skipped.
# 
# <p>After this initial filtering, any <tt>multipart</tt> attachments
# that are empty are removed.  If the outer message is left empty after
# this filtering, then the whole message is discarded.  Then, each
# <tt>multipart/alternative</tt> section will be replaced by just the
# first alternative that is non-empty after filtering.
# 
# <p>Finally, any <tt>text/html</tt> parts that are left in the message
# may be converted to <tt>text/plain</tt> if <a
# href="?VARHELP=contentfilter/convert_html_to_plaintext"
# >convert_html_to_plaintext</a> is enabled and the site is configured
# to allow these conversions.

# Should Mailman filter the content of list traffic according to the
# settings below?
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
filter_content = 0

# 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.
# 
# See also <a href="?VARHELP=contentfilter/pass_mime_types"
# >pass_mime_types for a content type whitelist.
filter_mime_types = ''

# Use this option to remove each message attachment that does not have a
# matching content type.  Requirements and formats are exactly like <a
# href="?VARHELP=contentfilter/filter_mime_types" >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.
pass_mime_types = """multipart/mixed
multipart/alternative
text/plain"""

# Should Mailman convert text/html parts to plain text?  This conversion
# happens after MIME attachments have been stripped.
#
# legal values are:
#    0 = "No"
#    1 = "Yes"
convert_html_to_plaintext = 1

# 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 <a href="?VARHELP=contentfilter/filter_mime_types"
# >filter_mime_types, or the top-level content type does not match one
# of the <a href="?VARHELP=contentfilter/pass_mime_types"
# >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.
#
# legal values are:
#    0 = "Discard"
#    1 = "Reject"
#    2 = "Forward to List Owner"
#    3 = "Preserve"
filter_action = 0

## Topics options
#
# List topic keywords

# The topic filter categorizes each incoming email message according to
# <a href="http://www.python.org/doc/current/lib/module-re.html">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 <a
# href="?VARHELP=topics/topics_bodylines_limit">topics_bodylines_limit
# configuration variable.
#
# legal values are:
#    0 = "Disabled"
#    1 = "Enabled"
topics_enabled = 0

# 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.
# 
topics_bodylines_limit = 5

# 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.
topics = []