Update of /cvsroot/mailman/mailman3/src/mailman/categories/specs
In directory
sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31133/src/mailman/categories/specs
Added Files:
Tag: 3.0
delivery.xml general.xml languages.xml privacy.xml
Log Message:
Initial checkin of Mailman3 source
--- NEW FILE: delivery.xml ---
<!--
Copyright (C) 2004 Barry A. Warsaw
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-->
<category
name="delivery"
heading="Message delivery options"
description="Options controlling the delivery of messages.">
<variable type="Radio"
enum="DeliveryModes"
style="Vertical">
<name>delivery_modes</name>
<description>Allowable modes of message delivery</description>
<details>
This option describes how messages posted to the list can
be delivered to the membership. <span
class="value">Regular</span> delivery means that as soon
as a message is posted to the list, a copy of the message
is immediately delivered to each member, as a single
email.
<p/><span class="value">Digest</span> delivery means that
members can elect instead to receive a single message
containing several bundled postings. This usually results
in fewer messages received from the list, but requires a
mail reader that can understand the standard digest
bundling formats. Note that the actual frequency and size
of digests can be approximately, but not completely
controlled.
<p/>When you select <span class="value">Either</span>, it
means that members can elect to receive list messages as
either individual message copies, or as digest bundles.
They can't receive both types.
</details>
</variable>
<variable type="Toggle"
labels="Regular;Digest">
<name>digest_is_default</name>
<description>
Which delivery mode is the default for new users?
</description>
</variable>
<variable type="Toggle">
<name>shared_decorations</name>
<description>
Should regular and digest messages use the same header and
footer decorations?
</description>
<details>
Both regular and digest messages can be decorated with
headers and footers containing additional useful
information, such as links to the list's archives, or
personalized links for unsubscribing from the list. These
decorations can be the same for both styles of messages,
or regular and digest decorations can be different.
<p/>When this option is set to <span
class="value">Yes</span> then the $msg_header and
$msg_footer options are used for both modes of delivery.
<p/>Note that this setting is different than the
table-of-contents header that is always included in a
digest message.
</details>
</variable>
<variable type="Radio"
labels="No;Yes;Full Personalization"
enum="PersonalizationChoices"
style="Vertical">
<name>personalize</name>
<description>Should Mailman personalize each message?</description>
<details>
"Personalization" controls how Mailman sends the regular
message copies and digests to individual list members.
Normally, Mailman sends the messages to the mail server
in batches, which is the more efficient delivery option
because each recipient sees an exact copy of the message,
thus reducing the amount of traffic between Mailman and
the mail server.
<p/>However, some lists can benefit from a more
personalized approach. When this option is set to <span
class="value">Yes</span>, Mailman crafts a new copy of
the message for each recipient, personalizing some parts
of the message. For example, the list headers and
footers can contain information specific to the
recipient, such as the URL to their personal options
page.
<p/>Also, when personalization is enabled, Mailman can
use a technique called <a
href="http://cr.yp.to/proto/verp.txt";>VERP</a> to ensure
that bounces are unambiguously attributed to the correct
recipient. (The non-VERP approach is more error prone,
due to the wide variety of mail servers out in the wild.)
So, personalization is less efficient but more accurate,
and can provide a better end-user experience.
<p/><span class="value">Full Personalization</span>
enables all the personalization features that the
<span class="value">Yes</span> option provides, with the
addition that the To header in the sent message will be
modified to include the recipient's address and name,
instead of the list's posting address.
<p/>When either personalization option is enabled, a few
more substitution variables can be included in the
message header ($msg_header and $digest_header) and
message footer ($msg_footer and $digest_footer).
</details>
</variable>
<category
name="regular"
heading="Regular delivery options">
<variable type="Text" rows="10">
<name>msg_header</name>
<description>
Additional text added to the front of all regular messages.
</description>
<details>
When non-empty, this text is prepended to regular message
copies sent to the list. When $shared_decorations is set
to <span class="value">Yes</span>, this same text is
included near the top of digest deliveries.
<p/>Inside the header text, you can include some
substitution variables, which will be filled in by Mailman
when the message is delivered. The available substitution
variables are:
<ul>
<li><span class="value">listname</span> - The "short"
name for the list, i.e. the name by which the list is
identified in URLs.</li>
<li><span class="value">$$public_name</span> - The
value of the $public_name option.</li>
<li><span class="value">$$domain</span> - The URL domain
the list lives in.</li>
<li><span class="value">$$hostname</span> - The email
domain that the list lives in (this might be the same
as the $$domain).</li>
<li><span class="value">$$listinfo</span> - The URL to the
list's public information page.</li>
<li><span class="value">$$description</span> - The value
of the $description option.</li>
</ul>
<p/>When the $personalize option is set to either <span
class="value">Yes</span> or <span class="value">Full
Personalization</span>, these additional substitution
variables are available:
<ul>
<li><span class="value">$$member_address</span> - The
subscribed address of the list member receiving this
message, coerced to lower case.</li>
<li><span class="value">$$member_delivered_to</span> - The
case-preserved address of the list member.</li>
<li><span class="value">$$member_name</span> - The
member's full name.</li>
<li><span class="value">$$member_page</span> - The URL of
the member's personal options page.</li>
</ul>
</details>
</variable>
<variable type="Text" rows="10">
<name>msg_footer</name>
<description>
Additional text added to the end of all regular messages.
</description>
<details>
When non-empty, this text is appended to regular message
copies sent to the list. When $shared_decorations is set
to <span class="value">Yes</span>, this same text is
included at the bottom of digest deliveries.
<p/>Inside the footer text, you can include some
substitution variables, which will be filled in by Mailman
when the message is delivered. The available substitution
variables are:
<ul>
<li><span class="value">$$listname</span> - The "short"
name for the list, i.e. the name by which the list is
identified in URLs.</li>
<li><span class="value">$$public_name</span> - The
value of the $public_name option.</li>
<li><span class="value">$$domain</span> - The URL domain
the list lives in.</li>
<li><span class="value">$$hostname</span> - The email
domain that the list lives in (this might be the same
as the $$domain).</li>
<li><span class="value">$$listinfo</span> - The URL to the
list's public information page.</li>
<li><span class="value">$$description</span> - The value
of the $description option.</li>
</ul>
<p/>when the $personalize option is set to either <span
class="value">Yes</span> or <span class="value">Full
Personalization</span>, these additional substitution
variables are available:
<ul>
<li><span class="value">$$member_address</span> - The
subscribed address of the list member receiving this
message, coerced to lower case.</li>
<li><span class="value">$$member_delivered_to</span> - The
case-preserved address of the list member.</li>
<li><span class="value">$$member_name</span> - The
member's full name.</li>
<li><span class="value">$$member_page</span> - The URL of
the member's personal options page.</li>
</ul>
</details>
</variable>
</category>
<category
name="digest"
description="Digest delivery options">
<variable type="Toggle"
labels="Plain Text;MIME">
<name>mime_is_default</name>
<description>
When receiving digests, which format is the default?
</description>
</variable>
<variable type="Number">
<name>digest_size_threshold</name>
<description>
What is the approximate maximum size of a digest in kilobytes?
</description>
<details>
When a digest gets bigger than this value, it is sent out
immediately, even if a digest has already been sent out
for today. Note that this is an approximate size limit
only.
<p/>If you set this value to zero, a maximum of one digest
per day will be sent out, however on active lists, this
digest may be very large.
</details>
</variable>
<variable type="Toggle">
<name>send_digest_daily</name>
<description>
Should a digest be sent daily, even if the size threshold
hasn't been reached?
</description>
<details>
Note that if no messages have been sent to the list since
the last digest was sent, no new digests will be sent.
</details>
</variable>
<variable type="Radio"
enum="DigestVolumeFrequency">
<name>digest_volume_frequency</name>
<description>
How often should a new digest volume be started?
</description>
</variable>
<variable type="Text" rows="10">
<name>digest_header</name>
<description>
Additional text added to the front of all digest messages.
</description>
<details>
When non-empty, this text is prepended to digest message
copies sent to the list, but only when $shared_decorations
is set to <span class="value">No</span>.
<p/>Inside the header text, you can include some
substitution variables, which will be filled in by Mailman
when the message is delivered. The available substitution
variables are:
<ul>
<li><span class="value">$$listname</span> - The "short"
name for the list, i.e. the name by which the list is
identified in URLs.</li>
<li><span class="value">$$public_name</span> - The
value of the $public_name option.</li>
<li><span class="value">$$domain</span> - The URL domain
the list lives in.</li>
<li><span class="value">$$hostname</span> - The email
domain that the list lives in (this might be the same
as the $$domain).</li>
<li><span class="value">$$listinfo</span> - The URL to the
list's public information page.</li>
<li><span class="value">$$description</span> - The value
of the $description option.</li>
</ul>
<p/>When the $personalize option is set to either <span
class="value">Yes</span> or <span class="value">Full
Personalization</span>, these additional substitution
variables are available:
<ul>
<li><span class="value">$$member_address</span> - The
subscribed address of the list member receiving this
message, coerced to lower case.</li>
<li><span class="value">$$member_delivered_to</span> - The
case-preserved address of the list member.</li>
<li><span class="value">$$member_name</span> - The
member's full name.</li>
<li><span class="value">$$member_page</span> - The URL of
the member's personal options page.</li>
</ul>
</details>
</variable>
<variable type="Text" rows="10">
<name>digest_footer</name>
<description>
Additional text added to the end of all digest messages.
</description>
<details>
When non-empty, this text is appended to digest message
copies sent to the list, but only when $shared_decorations
is set to <span class="value">No</span>.
<p/>Inside the footer text, you can include some
substitution variables, which will be filled in by Mailman
when the message is delivered. The available substitution
variables are:
<ul>
<li><span class="value">$$listname</span> - The "short"
name for the list, i.e. the name by which the list is
identified in URLs.</li>
<li><span class="value">$$public_name</span> - The
value of the $public_name option.</li>
<li><span class="value">$$domain</span> - The URL domain
the list lives in.</li>
<li><span class="value">$$hostname</span> - The email
domain that the list lives in (this might be the same
as the $$domain).</li>
<li><span class="value">$$listinfo</span> - The URL to the
list's public information page.</li>
<li><span class="value">$$description</span> - The value
of the $description option.</li>
</ul>
<p/>when the $personalize option is set to either <span
class="value">Yes</span> or <span class="value">Full
Personalization</span>, these additional substitution
variables are available:
<ul>
<li><span class="value">$$member_address</span> - The
subscribed address of the list member receiving this
message, coerced to lower case.</li>
<li><span class="value">$$member_delivered_to</span> - The
case-preserved address of the list member.</li>
<li><span class="value">$$member_name</span> - The
member's full name.</li>
<li><span class="value">$$member_page</span> - The URL of
the member's personal options page.</li>
</ul>
</details>
</variable>
</category>
<category
name="actions"
description="Digest actions">
<action>
<name>action_new_volume</name>
<label>Start new digest</label>
<description>
Should Mailman start a new digest volume right now?
</description>
</action>
<action>
<name>action_send_digest</name>
<label>Send digest now</label>
<description>
Should Mailman send the next digest right now, if it is
not empty?
</description>
</action>
</category>
</category>
--- NEW FILE: general.xml ---
<?xml version="1.0" encoding="us-ascii" ?>
<!--
Copyright (C) 2004 Barry A. Warsaw
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-->
<category
name="general"
heading="General Options"
description="Fundamental list characteristics">
<section>General list personality</section>
<variable type="String">
<name>public_name</name>
<description>The public name of this list.</description>
<details>
This list name is used in various descriptive places and has
no semantic significance. You can change this string to
anything you want.
</details>
</variable>
<variable type="EmailList">
<name>owners</name>
<description>The list administrator email addresses.</description>
<details>
List administrators have control over the mailing list's
settings. They can also approve or reject postings and
subscription requests.
<p/>It is okay to have multiple addresses; put each on a
separate line. You can also include the administrators'
names in parentheses after the address. You must provide
at least one list administrator address.
</details>
</variable>
<variable type="EmailList">
<name>moderators</name>
<description>The list moderator email addresses.</description>
<details>
List moderators are people who have access only to the
moderator interface for the list. They cannot change list
configurations, but they can approve or reject postings
and subscription requests.
<p/>It is okay to have multiple addresses; put each on a
separate line. You can also include the moderators' names
in parentheses after the address.
</details>
</variable>
<variable type="String">
<name>description</name>
<description>A terse phrase identifying this list.</description>
<details>
This description is used when the mailing list is
displayed in the overview with other mailing lists, or in
List-* headers, and so forth. It should be as succinct as
you can get it, while still identifying what the list is.
</details>
</variable>
<variable type="Text">
<name>info</name>
<description>
A few paragraphs that provide an introduction to the
mailing list on the list's information page.
</description>
<details>
The text will be treated as HTML <em>except</em> that
newlines will be translated to <br> - so you can use
links, preformatted text, etc, but don't put in newlines
except where you mean to separate paragraphs. Be sure to
review your changes - bad HTML (like some unterminated
HTML constructs) can prevent display of the entire
information page.
</details>
</variable>
<variable type="String">
<name>subject_prefix</name>
<description>
A prefix for the Subject line of list postings.
</description>
<details>
This text will be prepended to Subject lines of messages
posted to the list. Brevity is important here; it's okay
since Subject header real-estate is limit.
<p/>This text can include the variable "$seqnum", which will
be substituted with the sequence number of the posted
message.
</details>
</variable>
<variable type="Toggle">
<name>anonymous_list</name>
<description>
An anonymous hides the sender of a message, replacing it
with the list address. This affects From, Sender, and
Reply-To fields, but does not anonymize the body of the
message.
</description>
</variable>
<section>Reply-To header munging</section>
<variable type="Toggle">
<name>first_strip_reply_to</name>
<description>
Should any existing Reply-To header found in the
original message be stripped?
</description>
<details>
Any existing Reply-To header will be removed regardless of
whether an explicit Reply-To header is added by Mailman or
not.
</details>
</variable>
<variable type="Radio"
labels="No;Yes, this list's address;Yes, an explicit address"
enum="AppendReplyTo"
style="Vertical">
<name>append_reply_to</name>
<description>
Should Mailman add any values to the Reply-To header?
</description>
<details>
This option controls what Mailman does to the Reply-To
header in messages flowing through this mailing list.
When set to <span class="value">No</span>, no Reply-To
header is added by Mailman, although if one is present in
the original message, it is not stripped. What Mailman
does with an existing Reply-To address is controlled by
the $first_strip_reply_to variable.
<p/>Setting the value of this variable to one of the <span
class="value">Yes, ...</span> values causes Mailman to add
a specific value to the Reply-To header of the message.
If the original message does not have a Reply-To header,
one is added. If the original message has a Reply-To
header, a value is appended to the existing header.
<p/>When set to <span class="value">Yes, this list's
address</span>, this list's posting address is added to
the Reply-To header. When set to <span class="value">Yes,
an explicit address</span>, the value of the
$reply_to_address variable is added.
<p/>This variable controls a behavior commonly known as
"Reply-To Munging", which tends to be a contentious issue.
General consensus is that most discussion mailing lists
should not munge Reply-To. Some announce-only lists may
want to set Reply-To to an explicit address; for example,
a one-way band announce list might want to redirect follow
ups to a fan discussion list.
<p/>See <a
href="http://www.unicom.com/pw/reply-to-harmful.html";>`Reply-To'
Munging Considered Harmful</a> for a general discussion of
this issue. See <a
href="http://www.metasystema.org/essays/reply-to-useful.mhtml";
>Reply-To Munging Considered Useful</a> for a dissenting opinion.
</details>
</variable>
<variable type="Email">
<name>reply_to_address</name>
<description>Explicit Reply-To address</description>
<details>
This is the address added to the Reply-To header when the
$reply_goes_to_list option is set to <span
class="value">Yes, an explicit address</span>.
</details>
</variable>
<section>Notifications</section>
<variable type="Toggle">
<name>send_welcome_msg</name>
<description>Send a welcome message to new members?</description>
<details>
When a new member subscribes to a mailing list, Mailman
will send them a welcome message when this option is
enabled. You can add some additional text to the welcome
message by editing the $welcome_msg option.
</details>
</variable>
<variable type="Text">
<name>welcome_msg</name>
<description>
Text prepended to the welcome message sent to new members.
</description>
<details>
The text for this option will be added to the front of the
welcome message sent to new members. The rest of the
welcome message already describes the important addresses
and URLs for the mailing list.
<p/>Note that this text will be wrapped, according to the
following rules:
<ul><li>Each paragraph is reformatted so that no line is
longer than 70 characters</li>
<li>Any line that begins with whitespace is not
reformatted</li>
<li>A blank line separates paragraphs</li>
</ul>
</details>
</variable>
<variable type="Toggle">
<name>send_goodbye_msg</name>
<description>
Send a message to members when they unsubscribe from this
list?
</description>
<details>
See also $goodbye_msg for additional text sent to the
unsubscribing member.
</details>
</variable>
<variable type="Text">
<name>goodbye_msg</name>
<description>
Text prepended to the message sent to members who
unsubscribe from this list.
</description>
<details>
The text for this option will be added to the front of the
welcome message sent to new members. The rest of the
welcome message already describes the important addresses
and URLs for the mailing list.
<p/>Note that this text will be wrapped, according to the
following rules:
<ul><li>Each paragraph is reformatted so that no line is
longer than 70 characters</li>
<li>Any line that begins with whitespace is not
reformatted</li>
<li>A blank line separates paragraphs</li>
</ul>
</details>
</variable>
<variable type="Toggle">
<name>notify_admin_immediately</name>
<description>
Should the list moderators get immediate notice of new
pending requests (held messages and subscriptions
requiring moderator approval)?
</description>
<details>
List moderators and administrators are sent daily
reminders of requests pending approval, such as
subscriptions to a moderated list, or postings that are
being held for one reason or another. Setting this option
causes notices to also be sent immediately on the arrival
of a new request.
</details>
</variable>
<variable type="Toggle">
<name>notify_admin_of_membership_changes</name>
<description>
Should the list moderators get notifications of changes to
membership, such as when someone subscribes or
unsubscribes from the list?
</description>
</variable>
<variable type="Toggle">
<name>notify_sender_of_held_posting</name>
<description>
When a posting is held for approval, should a notification
be sent to the sender?
</description>
</variable>
<section>Additional settings</section>
<variable type="Toggle">
<name>check_for_administrivia</name>
<description>
Should Mailman check messages sent to the posting address
for administrivia?
</description>
<details>
<em>Administrivia</em> is defined as the set of email
commands that Mailman's email robot (i.e. -request
address) recognizes. Occasionally people misdirect such
messages to the mailing list; by enabling this option,
Mailman checks for such misdirected mail and if found,
holds the message for approval.
</details>
</variable>
<variable type="Toggle">
<name>include_rfc2369_headers</name>
<description>
Should message from this mailing list include the
<a href="http://www.faqs.org/rfcs/rfc2369.html";>RFC 2369</a>
(i.e. List-*) headers? <span class="value">Yes</span> is
highly recommended.
</description>
<details>
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.
<p/>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).
</details>
</variable>
<variable type="Toggle">
<name>include_list_post_header</name>
<description>
Should postings include the List-Post header?
</description>
<details>
The List-Post header is one of the headers recommended by
<a href="http://www.faqs.org/rfcs/rfc2369.html";>RFC
2369</a>. 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 <span class="value">No</span> to
disable the inclusion of this header. (This does not
affect the inclusion of the other List-* headers.)
</details>
</variable>
</category>
--- NEW FILE: languages.xml ---
<?xml version="1.0" encoding="us-ascii" ?>
<!--
Copyright (C) 2004 Barry A. Warsaw
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-->
<category
name="languages"
heading="Language Options"
description="Natural language and internationalization options.">
<variable type="Pulldown"
enum="Languages">
<name>preferred_language</name>
<description>Default language for this list.</description>
<details>
This is the default natural language for this mailing
list. If more than one language is enabled for this list
(see $available_languages) then users will be able to
select their own preference of natural language for when
they interact with the list. All other interactions will
be conducted in the list's default language. This applies
to both web-based and email-based messages (but note that
email posted by list members is never translated).
</details>
</variable>
<variable type="Select"
enum="Languages"
style="Vertical">
<name>available_languages</name>
<description>Languages supported by this list.</description>
<details>
These are all the natural languages supported by this list.
Note that the default language (see $preferred_language)
will always be enabled.
</details>
</variable>
<variable type="Radio"
enum="EncodePrefixes"
labels="Never;Always;As needed"
style="Vertical">
<name>encode_ascii_prefixes</name>
<description>
Encode the $subject_prefix even when it consists only of
ASCII characters?
</description>
<details>
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
<span class="value">Never</span> 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.
<p/>Note however, that if your mailing list receives both
encoded and unencoded subject headers, you might want to
choose <span class="value">As needed</span>. 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.
</details>
</variable>
</category>
--- NEW FILE: privacy.xml ---
<?xml version="1.0" encoding="us-ascii" ?>
<!--
Copyright (C) 2004 Barry A. Warsaw
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-->
<category name="privacy" heading="Privacy options...">
<subcategory
name="subscribing"
heading="Subscription rules"
description="Options controlling subscription.">
</subcategory>
<subcategory
name="sender"
heading="Sender rules"
description="Options controlling who can post to this list.">
</subcategory>
<subcategory
name="recipient"
heading="Recipient rules"
description="Options specifying additional recipient rules.">
</subcategory>
<subcategory
name="spam"
heading="Anti-spam rules"
description="Options controlling spam defenses.">
</subcategory>
</category>
_______________________________________________
Mailman-checkins mailing list
[EMAIL PROTECTED]
Unsubscribe: http://mail.python.org/mailman/options/mailman-checkins/archive%40jab.org
