Browsing German translation

690.

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.

701.

One of these actions is taken 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.

712.

How big in Kb should a digest be before it gets sent out? 0 implies no maximum size.

749.

Munge From

750.

Wrap Message

751.

Replace the From: header address with the list's posting
address to mitigate issues stemming from the original From:
domain's DMARC or similar policies.

752.

Several protocols now in wide use attempt to ensure that use
of the domain in the author's address (ie, in the From: header
field) is authorized by that domain. These protocols may be
incompatible with common list features such as footers, causing
participating email services to bounce list traffic merely
because of the address in the From: field. <b>This has resulted
in members being unsubscribed despite being perfectly able to
receive mail.</b>
<p>
The following actions are applied to all list messages when
selected here. To apply these actions only to messages where the
domain in the From: header is determined to use such a protocol,
see the <a
href="?VARHELP=privacy/sender/dmarc_moderation_action">
dmarc_moderation_action</a> settings under Privacy options...
-&gt; Sender filters.
<p>Settings:<p>
<dl>
<dt>No</dt>
<dd>Do nothing special. This is appropriate for anonymous lists.
It is appropriate for dedicated announcement lists, unless the
From: address of authorized posters might be in a domain with a
DMARC or similar policy. It is also appropriate if you choose to
use dmarc_moderation_action other than Accept for this list.</dd>
<dt>Munge From</dt>
<dd>This action replaces the poster's address in the From: header
with the list's posting address and adds the poster's address to
the addresses in the original Reply-To: header.</dd>
<dt>Wrap Message</dt>
<dd>Just wrap the message in an outer message with the From:
header containing the list's posting address and with the original
From: address added to the addresses in the original Reply-To:
header and with Content-Type: message/rfc822. This is effectively
a one message MIME format digest.</dd>
</dl>
<p>The transformations for anonymous_list are applied before
any of these actions. It is not useful to apply actions other
than No to an anonymous list, and if you do so, the result may
be surprising.
<p>The Reply-To: header munging actions below interact with these
actions as follows:
<p> first_strip_reply_to = Yes will remove all the incoming
Reply-To: addresses but will still add the poster's address to
Reply-To: for all three settings of reply_goes_to_list which
respectively will result in just the poster's address, the
poster's address and the list posting address or the poster's
address and the explicit reply_to_address in the outgoing
Reply-To: header. If first_strip_reply_to = No the poster's
address in the original From: header, if not already included in
the Reply-To:, will be added to any existing Reply-To:
address(es).
<p>These actions, whether selected here or via <a
href="?VARHELP=privacy/sender/dmarc_moderation_action">
dmarc_moderation_action</a>, do not apply to messages in digests
or archives or sent to usenet via the Mail&lt;-&gt;News gateways.
<p>If <a
href="?VARHELP=privacy/sender/dmarc_moderation_action">
dmarc_moderation_action</a> applies to this message with an
action other than Accept, that action rather than this is
applied

762.

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.

796.

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

831.

Other mailing lists on this site whose members are
excluded from the regular (non-digest) delivery if those
list addresses appear in a To: or Cc: header.