Browsing Portuguese translation

627.

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.

689.

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.

691.

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.

705.

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.org/essays/reply-to-useful.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.

712.

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

716.

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>

752.

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 <em>Never</em> 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 <em>As
needed</em>. 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.

762.

Normally, Mailman sends the regular delivery messages to
the mail server in batches. This is much more efficent
because it reduces the amount of traffic between Mailman and
the mail server.

<p>However, some lists can benefit from a more personalized
approach. In this case, Mailman crafts a new message for
each member on the regular delivery list. Turning this
feature on may degrade the performance of your site, so you
need to carefully consider whether the trade-off is worth it,
or whether there are other ways to accomplish what you want.
You should also carefully monitor your system load to make
sure it is acceptable.

<p>Select <em>No</em> to disable personalization and send
messages to the members in batches. Select <em>Yes</em> to
personalize deliveries and allow additional substitution
variables in message headers and footers (see below). In
addition, by selecting <em>Full Personalization</em>, the
<code>To</code> header of posted messages will be modified to
include the member's address instead of the list's posting
address.

<p>When personalization is enabled, a few more expansion
variables that can be included in the <a
href="?VARHELP=nondigest/msg_header">message header</a> and
<a href="?VARHELP=nondigest/msg_footer">message footer</a>.

<p>These additional substitution variables will be available
for your headers and footers, when this feature is enabled:

<ul><li><b>user_address</b> - The address of the user,
coerced to lower case.
<li><b>user_delivered_to</b> - The case-preserved address
that the user is subscribed with.
<li><b>user_password</b> - The user's password.
<li><b>user_name</b> - The user's full name.
<li><b>user_optionsurl</b> - The url to the user's option
page.
</ul>

763.

When <a href="?VARHELP=nondigest/personalize">personalization</a> is enabled
for this list, additional substitution variables are allowed in your headers
and footers:

<ul><li><b>user_address</b> - The address of the user,
coerced to lower case.
<li><b>user_delivered_to</b> - The case-preserved address
that the user is subscribed with.
<li><b>user_password</b> - The user's password.
<li><b>user_name</b> - The user's full name.
<li><b>user_optionsurl</b> - The url to the user's option
page.
</ul>

779.

None - no verification steps (<em>Not
Recommended </em>)<br>
Confirm (*) - email confirmation step required <br>
Require approval - require list administrator
Approval for subscriptions <br>
Confirm and approve - both confirm and approve

<p>(*) 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.<br>

This prevents mischievous (or malicious) people
from creating subscriptions for others without
their consent.