Browsing Ukrainian translation

611.

Vietnamese

670.

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.

<p> Then, each <tt>multipart/alternative</tt> section will
be replaced by just the first alternative that is non-empty after
filtering if
<a href="?VARHELP=contentfilter/collapse_alternatives"
>collapse_alternatives</a> is enabled.

<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.

678.

Should Mailman collapse multipart/alternative to its
first part content?

736.

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

<p>There are many reasons not to introduce or override the
<tt>Reply-To:</tt> header. One is that some posters depend on
their own <tt>Reply-To:</tt> settings to convey their valid
return address. Another is that modifying <tt>Reply-To:</tt>
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</a> for a general discussion of this
issue. See <a
href="http://www.metasystema.net/essays/reply-to.mhtml">Reply-To
Munging Considered Useful</a> for a dissenting opinion.

<p>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 <tt>Explicit address</tt> and set the
<tt>Reply-To:</tt> address below to point to the parallel
list.

738.

This is the address set in the <tt>Reply-To:</tt> header
when the <a
href="?VARHELP=general/reply_goes_to_list">reply_goes_to_list</a>
option is set to <em>Explicit address</em>.

<p>There are many reasons not to introduce or override the
<tt>Reply-To:</tt> header. One is that some posters depend on
their own <tt>Reply-To:</tt> settings to convey their valid
return address. Another is that modifying <tt>Reply-To:</tt>
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</a> for a general discussion of this
issue. See <a
href="http://www.metasystema.net/essays/reply-to.mhtml">Reply-To
Munging Considered Useful</a> for a dissenting opinion.

<p>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 <tt>Reply-To:</tt> address here. You
must also specify <tt>Explicit address</tt> in the
<tt>reply_goes_to_list</tt>
variable.

<p>Note that if the original message contains a
<tt>Reply-To:</tt> header, it will not be changed.

764.

Maximum number of members to show on one page of the
Membership List.

771.

Should the <tt>Sender</tt> header be rewritten for this
mailing list to avoid stray bounces? <em>Yes</em> is
recommended.

772.

<a href="http://www.faqs.org/rfcs/rfc2822.html">RFC
2822</a> defines the <tt>Sender</tt> header and defines it
as "the mailbox of the agent responsible for the actual
transmission of the message." Mailman replaces this header
by default with the list's bounce address.

<p>While it is debatable if Mailman is such an agent, setting
this header helps directing bounces from some broken MTAs to
the right destination. On the other hand, some mail
readers show unexpected behaviour if this header is set (like
missing addresses in forwarded mails and copies sent to the
bounce address on reply-to-all), so it can be disabled
here.

775.

The <b>info</b> attribute you saved
contains suspicious HTML that could potentially expose your users to cross-site
scripting attacks. This change has therefore been rejected. If you still want
to make these changes, you must have shell access to your Mailman server.
This change can be made with bin/withlist or with bin/config_list by setting
mlist.info.

776.

<b>admin_member_chunksize</b> attribute not
changed! It must be an integer > 0.