+ <p>and modify the <tt>mm_domains</tt> domain list appropriately.</p>
+
+ <h2><a href="#index"><a name="lispol">List policy management</a></a></h2>
+
+ <p>Most list policy handling is done within Mailman using the Web
+ GUI. However some issues may be better handled by the MTA,
+ especially matters of overall site policy (not just mailing list
+ policy). For example you may wish to do virus or spam scanning on
+ incoming messages.</p>
+
+ <p>In general you exclude outgoing list mail from any policy
+ controls. This is because outgoing list mail has already been
+ through the policy controls on the way into the system.
+ Additionally spam scanning (for example) is a machine intensive
+ operation, and scanning a message that has already been scanned,
+ and then replicated to many recipients, is going to be very
+ expensive as well as ineffective. For this reason you will
+ normally have an <tt>accept</tt> clause early on in your ACLs that
+ causes Mailman generated traffic to bypass the machine intensive
+ checks.</p>
+
+ <h3><a href="#index"><a name="conpol">Content scanning</a></a></h3>
+
+ <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>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>
+
+ <h3><a href="#index"><a name="incpol">Incoming message checks</a></a></h3>
+
+ <p>You may wish to apply various checks to incoming messages to
+ ensure that they are sane. These may include:-</p>
+
+ <ul>
+ <li>DNSBL checks</li>
+ <li>Header checks</li>
+ <li>Sender callback verification</li>
+ </ul>
+
+ <p>However all of these do have some degree of false positive
+ ratings. You need to be aware of how much of your user base you
+ may alienate by imposing too strict a set of controls, and balance
+ that against the reduced amount of unwanted bulk mail.</p>
+
+ <h3><a href="#index"><a name="mmapol">Mailman specific ACL checks</a></a></h3>
+
+ <p>Lists should never receive bounce messages to the posting
+ address unless the bounced message is either a forgery using the
+ list address as the sender address, or the bouncing MTA is
+ terminally broken. In either of these cases we really are not
+ interested in receiving the messages and can reject them at SMTP
+ time with a clear conscience. The ACL to do this (as part of the
+ RCPT ACL) is:-</p>
git://git.exim.org / exim-website.git / blobdiff