Browsing Bosnian translation

464.

This page allows you as the list owner, to permanent
remove this mailing list from the system. <strong>This action is not
undoable</strong> so you should undertake it only if you are absolutely
sure this mailing list has served its purpose and is no longer necessary.

<p>Note that no warning will be sent to your list members and after this
action, any subsequent messages sent to the mailing list, or any of its
administrative addreses will bounce.

<p>You also have the option of removing the archives for this mailing list
at this time. It is almost always recommended that you do
<strong>not</strong> remove the archives, since they serve as the
historical record of your mailing list.

<p>For your safety, you will be asked to reconfirm the list password.

523.

set help
Show this detailed help.

set show [address=<address>]
View your current option settings. If you're posting from an address
other than your membership address, specify your membership address
with `address=<address>' (no brackets around the email address, and no
quotes!).

set authenticate <password> [address=<address>]
To set any of your options, you must include this command first, along
with your membership password. If you're posting from an address
other than your membership address, specify your membership address
with `address=<address>' (no brackets around the email address, and no
quotes!).

set ack on
set ack off
When the `ack' option is turned on, you will receive an
acknowledgement message whenever you post a message to the list.

set digest plain
set digest mime
set digest off
When the `digest' option is turned off, you will receive postings
immediately when they are posted. Use `set digest plain' if instead
you want to receive postings bundled into a plain text digest
(i.e. RFC 1153 digest). Use `set digest mime' if instead you want to
receive postings bundled together into a MIME digest.

set delivery on
set delivery off
Turn delivery on or off. This does not unsubscribe you, but instead
tells Mailman not to deliver messages to you for now. This is useful
if you're going on vacation. Be sure to use `set delivery on' when
you return from vacation!

set myposts on
set myposts off
Use `set myposts off' to not receive copies of messages you post to
the list. This has no effect if you're receiving digests.

set hide on
set hide off
Use `set hide on' to conceal your email address when people request
the membership list.

set duplicates on
set duplicates off
Use `set duplicates off' if you want Mailman to not send you messages
if your address is explicitly mentioned in the To: or Cc: fields of
the message. This can reduce the number of duplicate postings you
will receive.

set reminders on
set reminders off
Use `set reminders off' if you want to disable the monthly password
reminder for this mailing list.

650.

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.

661.

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 <em>Yes</em> 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.

<p>If you really can't be bothered, then set this variable to
<em>No</em> and all non-detected bounces will be discarded
without further processing.

<p><b>Note:</b> 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
<em>No</em> those messages too will get discarded. You may want
to set up an
<a href="?VARHELP=autoreply/autoresponse_admin_text">autoresponse
message</a> for email to the -owner and -admin address.

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.

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.

760.

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

786.

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.

796.

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>