Browsing Portuguese translation

645.

Each subscriber is assigned a bounce score, as a floating
point number. Whenever Mailman receives a bounce from a list
member, that member's score is incremented. Hard bounces (fatal
errors) increase the score by 1, while soft bounces (temporary
errors) increase the score by 0.5. Only one bounce per day
counts against a member's score, so even if 10 bounces are
received for a member on the same day, their score will increase
by just 1.

This variable describes the upper limit for a member's bounce
score, above which they are automatically disabled, but not
removed from the mailing list.

667.

Remove message attachments that don't have a matching
filename extension. Leave this field blank to skip this filter
test.

668.

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

710.

There are two ownership roles associated with each mailing
list. The <em>list administrators</em> 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.

<p>The <em>list moderators</em> 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 <em>list
administrators</em> can also tend to pending requests.

<p>In order to split the list ownership duties into
administrators and moderators, you must
<a href="passwords">set a separate moderator password</a>,
and also provide the <a href="?VARHELP=general/moderator">email
addresses of the list moderators</a>. Note that the field you
are changing here specifies the list administrators.

712.

There are two ownership roles associated with each mailing
list. The <em>list administrators</em> 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.

<p>The <em>list moderators</em> 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 <em>list
administrators</em> can also tend to pending requests.

<p>In order to split the list ownership duties into
administrators and moderators, you must
<a href="passwords">set a separate moderator password</a>,
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.

718.

This text will be prepended to subject lines of messages
posted to the list, to distinguish mailing list messages 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 sequential number by %%d substitution
directive. eg.; [listname %%d] -> [listname 123]
(listname %%05d) -> (listname 00123)

726.

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.

728.

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.

733.

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

737.

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.

<p>Note that this text will be wrapped, according to the
following rules:
<ul><li>Each paragraph is filled so that no line is longer than
70 characters.
<li>Any line that begins with whitespace is not filled.
<li>A blank line separates paragraphs.
</ul>