Browsing Hebrew translation

84.

Edit the public HTML pages

308.

Your membership in the %(realname)s mailing list is
currently disabled due to excessive bounces. Your confirmation is
required in order to re-enable delivery to your address. We have the
following information on file:

<ul><li><b>Member address:</b> %(member)s
<li><b>Member name:</b> %(username)s
<li><b>Last bounce received on:</b> %(date)s
<li><b>Approximate number of days before you are permanently removed
from this list:</b> %(daysleft)s
</ul>

Hit the <em>Re-enable membership</em> button to resume receiving postings
from the mailing list. Or hit the <em>Cancel</em> button to defer
re-enabling your membership.

309.

Re-enable membership

552.

who password [address=<address>]
See everyone who is on this mailing list. The roster is limited to
list members only, and you must supply your membership password to
retrieve it. 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!)

626.

The maximum member bounce score before the member's
subscription is disabled. This value can be a floating point
number.

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.

642.

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. Then, each <tt>multipart/alternative</tt> section will
be replaced by just the first alternative that is non-empty after
filtering.

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

650.

One of these actions is take when the message matches one of
the content filtering rules, meaning, the top-level
content type matches one of the <a
href="?VARHELP=contentfilter/filter_mime_types"
>filter_mime_types</a>, or the top-level content type does
<strong>not</strong> match one of the
<a href="?VARHELP=contentfilter/pass_mime_types"
>pass_mime_types</a>, or if after filtering the subparts of the
message, the message ends up empty.

<p>Note this action is not taken if after filtering the message
still contains content. In that case the message is always
forwarded on to the list membership.

<p>When messages are discarded, a log entry is written
containing the Message-ID of the discarded message. When
messages are rejected or forwarded to the list owner, a reason
for the rejection is included in the bounce message to the
original author. When messages are preserved, they are saved in
a special queue directory on disk for the site administrator to
view (and possibly rescue) but otherwise discarded. This last
option is only available if enabled by the site
administrator.

697.

This text will be prepended to subject lines of messages
posted to the list, to distinguish mailing list messages in 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.

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.