<link rel="stylesheet" type="text/css" href="mailman21.css"/>
<!-- Canonical -->
- <link rel="canonical" href="http://www.exim.org/howto/mailman21.html"/>
+ <link rel="canonical" href="https://www.exim.org/howto/mailman21.html"/>
</xsl:variable>
MM_WRAP=MM_HOME/mail/mailman
#
# The path of the list config file (used as a required file when
-# verifying list addresses)
-MM_LISTCHK=MM_HOME/lists/${lc::$local_part}/config.pck</pre>
+# verifying list addresses). The option used takes a list
+# which is list-split before string-expansion, so we change the
+# default list-separator.
+MM_LISTCHK=<@ MM_HOME/lists/${lc:$local_part}/config.pck</pre>
<h4><a href="#index" id="roconf">Exim Router</a></h4>
<pre>mailman_router:
driver = accept
domains = +mm_domains
+ local_parts = dsearch,filter=dir;MM_HOME/lists
require_files = MM_LISTCHK
local_part_suffix_optional
local_part_suffix = -admin : \
'${if def:local_part_suffix \
{${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
{post}}' \
- $local_part
+ $local_part_data
current_directory = MM_HOME
home_directory = MM_HOME
user = MM_UID
<h4><a href="#index" id="verpmm">VERP within Mailman</a></h4>
- <p><a href="http://cr.yp.to/proto/verp.txt">VERP</a> (Variable Envelope Return Paths) encodes the (original) receipient address in the sender address. The reason for doing this is that it means bounces are sent to an address which has the original recipient address encoded in it - meaning you know which recipient address caused the bounce. This makes automatic bounce handling very effective - the normal method of parsing the bouncing address out of the bounce message is very prone to failure, especially in the case of foreign MTAs which use different addressing standards, or where mail forwarding is involved.</p>
+ <p><a href="https://cr.yp.to/proto/verp.txt">VERP</a> (Variable Envelope Return Paths) encodes the (original) receipient address in the sender address. The reason for doing this is that it means bounces are sent to an address which has the original recipient address encoded in it - meaning you know which recipient address caused the bounce. This makes automatic bounce handling very effective - the normal method of parsing the bouncing address out of the bounce message is very prone to failure, especially in the case of foreign MTAs which use different addressing standards, or where mail forwarding is involved.</p>
- <p>VERP will send one email, with a separate envelope sender (return path), for each of your subscribers - this means that it will generate more traffic since you cannot bundle up deliveries together. An <a href="http://wiki.list.org/display/DOC/So+what+is+this+VERP+stuff">analysis of the costs of VERP</a> can be found in the <a href="http://wiki.list.org/">Mailman WIKI</a>.</p>
+ <p>VERP will send one email, with a separate envelope sender (return path), for each of your subscribers - this means that it will generate more traffic since you cannot bundle up deliveries together. An <a href="https://wiki.list.org/display/DOC/So+what+is+this+VERP+stuff">analysis of the costs of VERP</a> can be found in the <a href="https://wiki.list.org/">Mailman WIKI</a>.</p>
<p>VERP settings within Mailman are done on a per-installation basis - ie they affect all the lists within the installation. To configure VERP within Mailman read the information in ~mailman/Mailman/Default.py for the options that start with VERP. In a nutshell, all you need to do to enable VERP with Exim is to add these lines to ~mailman/Mailman/mm_cfg.py:</p>
<p>In this case, you must change the MM_HOME macro to something like this:-</p>
- <pre>MM_HOME=/virtual/${lc::$domain}/mailman</pre>
+ <pre>MM_HOME=/virtual/${lc:$domain_data}/mailman</pre>
<p>and modify the mm_domains domain list appropriately.</p>
<p>I would recommend that mailing lists now scan for both spam and viruses on incoming mail - this is due to the potential for a compromised windows machine belonging to a subscriber managing to distribute unwanted content via the list. This causes problems not only to the list reputation, but also to the list manager who will get many many bounces from subscribers who do content scanning on their own incoming mail.</p>
- <p>The best way to do this is using the <a href="http
://duncanthrax.net/exiscan-acl/">exiscan</a> extension along with a virus scanner such as <a href="http://duncanthrax.net/exiscan-acl/">clam-av</a> and a spam content scanner such as <a href="http://www.spamassassin.org/">SpamAssassin</a>. Configuring these is beyond the scope of this document, however Tim Jackson has a very good set of <a href="http://www.timj.co.uk/linux/Exim-SpamAndVirusScanning.pdf">PDF documentation</a> on integrating these.</p>
+ <p>The best way to do this is using the <a href="http
s://duncanthrax.net/exiscan-acl/">exiscan</a> extension along with a virus scanner such as <a href="https://duncanthrax.net/exiscan-acl/">clam-av</a> and a spam content scanner such as <a href="https://spamassassin.apache.org/">SpamAssassin</a>. Configuring these is beyond the scope of this document, however Tim Jackson has a very good set of <a href="http://www.timj.co.uk/linux/Exim-SpamAndVirusScanning.pdf">PDF documentation</a> on integrating these.</p>
<p>One thing to note is that if you add full SpamAssassin headers onto list messages this bulks up the messages significantly. These headers are also available to list subscribers, which might make it easier for someone malicious to work out how to evade your spam scanning strategy. I would suggest that Spam headers are not added for Mailman incoming mail, or minimal (short) headers added, or that they are stripped somewhere. However having minimal headers on means that you can, for example, moderate all messages which have a given spam rating (as well as bouncing messages with a very high rating).</p>
git://git.exim.org / exim-website.git / blobdiff