templates/web/howto/mailman21.xsl

   1 <?xml version="1.0" encoding="UTF-8"?>
   2
   3 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   4
   5    <!-- WRAPPER -->
   6       <xsl:import href="../../wrapper.xsl"/>
   7       <xsl:template match="/"> <xsl:apply-imports/> </xsl:template>
   8
   9       <xsl:variable name="docroot" select="'..'"/>
  10
  11    <!-- Title -->
  12       <xsl:variable name="html.head.title" select="'HOWTO - Using Exim 4 and Mailman 2.1 together'"/>
  13
  14    <xsl:variable name="html.head.append">
  15
  16       <!-- CSS -->
  17          <link rel="stylesheet" type="text/css" href="mailman21.css"/>
  18
  19       <!-- Canonical -->
  20          <link rel="canonical" href="https://www.exim.org/howto/mailman21.html"/>
  21
  22    </xsl:variable>
  23
  24    <!-- CONTENT -->
  25       <xsl:template name="content">
  26
  27          <h2>
  28             <xsl:value-of select="$html.head.title"/>
  29          </h2>
  30
  31          <p>Mailman is a list manager with web front end and built in archiving functions.  Details can be found at <a href="http://www.list.org/">http://www.list.org/</a>. This documentation describes the configuration of Exim (version 4) to work with Mailman version 2.1</p>
  32
  33          <h3 id="index">Index</h3>
  34
  35          <ul>
  36             <li><a href="#scope">Scope of this document</a></li>
  37             <li><a href="#basic">Basic Configuration</a></li>
  38
  39             <li class="sublist">
  40                <ul>
  41                   <li><a href="#mmconf">Mailman configuration</a></li>
  42                   <li><a href="#exconf">Exim configuration</a></li>
  43                   <li><a href="#maconf">Main configuration settings</a></li>
  44                   <li><a href="#roconf">Exim Router</a></li>
  45                   <li><a href="#taconf">Exim Transport</a></li>
  46                </ul>
  47             </li>
  48
  49             <li><a href="#batune">Basic mailing list MTA tuning</a></li>
  50
  51             <li class="sublist">
  52                <ul>
  53                   <li><a href="#retune">Receiver verification</a></li>
  54                   <li><a href="#rctune">Tuning of numbers of recipients</a></li>
  55                   <li><a href="#smtune">SMTP callback</a></li>
  56                </ul>
  57             </li>
  58
  59             <li><a href="#verpin">Doing VERP and personalisation with exim and Mailman</a></li>
  60
  61             <li class="sublist">
  62                <ul>
  63                   <li><a href="#verpmm">VERP within Mailman</a></li>
  64                   <li><a href="#persmm">Mailing list personalisation by Mailman</a></li>
  65                   <li><a href="#verpex">VERP expansion by Exim rather than Mailman</a></li>
  66                </ul>
  67             </li>
  68
  69             <li><a href="#virdom">Virtual domains</a></li>
  70             <li><a href="#lispol">List policy management</a></li>
  71
  72             <li class="sublist">
  73                <ul>
  74                   <li><a href="#conpol">Content scanning</a></li>
  75                   <li><a href="#incpol">Incoming message checks</a></li>
  76                   <li><a href="#mmapol">Mailman specific ACL checks</a></li>
  77                </ul>
  78             </li>
  79
  80             <li><a href="#lisver">List verification</a></li>
  81             <li><a href="#problem">Possible Problems</a></li>
  82             <li><a href="#dochis">Document History</a></li>
  83             <li><a href="#doccha">Document Changes</a></li>
  84             <li><a href="#docfin">Final Word</a></li>
  85          </ul>
  86
  87          <h4><a href="#index" id="scope">Scope of this document</a></h4>
  88
  89          <p>This document describes how to set up a basic working configuration using Exim 4 as an MTA for the Mailman MLM.  The assumption is made that the receiving MTA, Mailman and the list distribution MTA are all on the same machine, and that Mailman talks to Exim using SMTP to address 127.0.0.1</p>
  90
  91          <p>It also describes ways of using VERP delivery, both conventionally (doing VERP from Mailman), and an alternative more efficient technique where VERP expansion is done within exim.</p>
  92
  93          <p>Tuning and setting appropriate mailing list protection policies is also covered in passing.</p>
  94
  95          <p>General installation, use, running and administration of either Mailman or exim is not covered here - the documentation for the programs concerned should be read for this information.</p>
  96
  97          <h3><a href="#index" id="basic">Basic Configuration</a></h3>
  98
  99          <h4><a href="#index" id="mmconf">Mailman configuration</a></h4>
 100
 101          <p>For basic operation there is no Mailman configuration needed other than the standard options detailed in the Mailman install documentation.  The user/group settings for Mailman must match those in the config fragments given below, and you need to have at least configured DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST within Mailman, for example by editing ~mailman/Mailman/mm_cfg.py and setting the following (substituting in your own domains):-</p>
 102
 103          <pre># The host part of the URL used for your mailman install
 104 DEFAULT_URL_HOST = 'www.example.com'
 105 #
 106 # The email domain of your lists
 107 DEFAULT_EMAIL_HOST = 'list.example.com'
 108 #
 109 # Let Mailman know that the MTA needs no aliases setting
 110 MTA = None</pre>
 111
 112          <p>The final setting above informs Mailman that it does not need to prompt you to add aliases when creating a list (like Sendmail), or modify other settings (like Postfix).  Not setting this will mean that Mailman nags you to do things that aren't necessary in an Exim configuration.</p>
 113
 114          <p>After making a change to the Mailman configuration file you need to restart the Mailman queue runners.</p>
 115
 116          <pre>~mailman/bin/mailmanctl restart</pre>
 117
 118          <p>Mailman should also be set to deliver to the MTA using SMTP - this is done by having DELIVERY_MODULE = 'SMTPDirect' in the config file (which is the default mode of operation)</p>
 119
 120          <h4><a href="#index" id="exconf">Exim configuration</a></h4>
 121
 122          <p>The Exim configuration is built so that a list created within Mailman automatically appears to Exim without the need for defining any additional aliases (however Mailman may helpfully show or email you a list of required aliases when you create a list - you can just ignore those - if you have set the MTA parameter it will stop doing this).</p>
 123
 124          <p>The drawback of this configuration is that it will work poorly on systems supporting lists in several different mail domains. While Mailman handles virtual domains, it does not yet support having two distinct lists with the same name in different virtual domains, using the same Mailman installation.  This will eventually change.  (But see below for a variation on this scheme that should accommodate virtual domains better.)</p>
 125
 126          <p>The configuration file excerpts below are for use in an already functional Exim configuration.  You also need to have an alias for mailman within the mm_domains, this picks up mail sent to the site list (or basically just sent in error), and should forward to the Mailman Administrator.  It appears that a couple of Mailman messages mention the mailman-admin address (this appears to be an error in Mailman or maybe a packaging error), so I would suggest that mailman-admin is aliased also to the Mailman Administrator.</p>
 127
 128          <p><i>[Note: the instructions in this document will work only with Exim 4.  It may be possible to adapt them for Exim 3, but frankly it is not worth the trouble]</i></p>
 129
 130          <p>You will need to add some macros to the main section of your Exim config file.  You will also need to define one new transport and add new routers.  Additional ACLs may be used to handle policy enforcement.  Remember that the exim daemon needs restarting before it sees configuration changes.</p>
 131
 132          <h4><a href="#index" id="maconf">Main configuration settings</a></h4>
 133
 134          <p>First, you need to add some macros to the top of your Exim config file.  These just make the routers and transport below a bit cleaner.  Obviously, you'll need to edit these based on how you configured and installed Mailman.</p>
 135
 136          <pre># Home dir for your Mailman installation -- aka Mailman's prefix
 137 # directory.
 138 # By default this is set to "/usr/local/mailman"
 139 # On a Red Hat/Fedora system using the RPM use "/var/mailman"
 140 # On Debian using the deb package use "/var/lib/mailman"
 141 # This is normally the same as ~mailman
 142 MM_HOME=/var/mailman
 143 #
 144 # User and group for Mailman, should match your --with-mail-gid
 145 # switch to Mailman's configure script.
 146 # Value is normally "mailman"
 147 MM_UID=mailman
 148 MM_GID=mailman
 149 #
 150 # Domains that your lists are in - colon separated list
 151 # you may wish to add these into local_domains as well
 152 domainlist mm_domains=list.example.com
 153 #
 154 # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 155 #
 156 # These values are derived from the ones above and should not need
 157 # editing unless you have munged your mailman installation
 158 #
 159 # The path of the Mailman mail wrapper script
 160 MM_WRAP=MM_HOME/mail/mailman
 161 #
 162 # The path of the list config file (used as a required file when
 163 # verifying list addresses).  The option used takes a list
 164 # which is list-split before string-expansion, so we change the
 165 # default list-separator.
 166 MM_LISTCHK=MM_HOME/lists/${lc:$local_part}/config.pck</pre>
 167
 168          <h4><a href="#index" id="roconf">Exim Router</a></h4>
 169
 170          <p>This router picks up all the addresses going to the Mailman lists.  Initially it selects only the domains that have may have lists in, then selects where local_part matches a list name (ie you can see a list config file).  The suffixes pick up all the Mailman admin addresses</p>
 171
 172          <p>The router should be placed in the router section (ie somewhere after the "begin routers" line of your config file). Normally you would place it just after the aliases router (since that will pick up the mailman master contact address).</p>
 173
 174          <pre>mailman_router:
 175   driver            = accept
 176   domains           = +mm_domains
 177   local_parts       = dsearch,filter=dir;MM_HOME/lists
 178   require_files     = MM_LISTCHK
 179   local_part_suffix_optional
 180   local_part_suffix = -admin     : \
 181          -bounces   : -bounces+* : \
 182          -confirm   : -confirm+* : \
 183          -join      : -leave     : \
 184          -owner     : -request   : \
 185          -subscribe : -unsubscribe
 186   transport         = mailman_transport</pre>
 187
 188          <h4><a href="#index" id="taconf">Exim Transport</a></h4>
 189
 190          <p>The transport for Exim 4 can be placed anywhere where under the begin transports line of your Exim config file.</p>
 191
 192          <p>The if def:local_part_suffix section selects whether the suffix is used as the mailman command, or whether there is no suffix and so post is passed as a command.</p>
 193
 194          <p>The sg phrase strips the VERP information (if any) from the suffix,</p>
 195
 196          <pre>mailman_transport:
 197   driver  = pipe
 198   command = MM_WRAP \
 199           '${if def:local_part_suffix \
 200                 {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
 201                 {post}}' \
 202           $local_part_data
 203   current_directory = MM_HOME
 204   home_directory    = MM_HOME
 205   user              = MM_UID
 206   group             = MM_GID</pre>
 207
 208
 209          <h4><a href="#index" id="batune">Basic mailing list MTA tuning</a></h4>
 210
 211          <p>Exim has a lot configurability, especially where the ACL (Access Control Lists) used during SMTP reception are concerned. MTA policy needs to be tuned so that list traffic is not affected by ACLs intended for qualifying traffic coming in from outside. Later in this document some suggestions are made regarding filtering traffic that is going into the mailing list, however</p>
 212
 213          <h4><a href="#index" id="retune">Receiver verification</a></h4>
 214
 215          <p>Exim's receiver verification feature is very useful -- it lets Exim reject unrouteable addresses at SMTP time.  However, this is most useful for externally-originating mail that is addresses to mail in one of your local domains.  For Mailman list traffic, mail originates on your server, and is addressed to random external domains that are not under your control.  Furthermore, each message is addressed to many recipients -- up to 500 if you use Mailman's default configuration, and don't tweak SMTP_MAX_RCPTS.</p>
 216
 217          <p>Doing receiver verification on Mailman list traffic is a recipe for trouble.  In particular, Exim will attempt to route every recipient addresses in outgoing Mailman list posts.  Even though this requires nothing more than a few DNS lookups for each address, it can still introduce significant delays (because these verifications have to be done serially as you attempt handoff to exim).  Therefore, you should disable recipient verification for Mailman traffic.</p>
 218
 219          <p>Under Exim 4, this is probably already taken care of for you by the default recipient verification ACL statement (in the "RCPT TO"
 220 ACL):</p>
 221
 222          <pre>accept  domains = +local_domains
 223         endpass
 224         message = unknown user
 225         verify  = recipient</pre>
 226
 227          <p>which only does recipient verification on addresses in your domain.  (That's not exactly the same as doing recipient verification only on messages coming from non-127.0.0.1 hosts, but it should do the trick for Mailman).  Obviously if the next ACL does verification on non-local addresses you will need to deal with that.</p>
 228
 229          <p>Alternatively you can add an early get-out in the "RCPT TO" ACL), which <i>trusts</i> all traffic coming from the loopback IP address:</p>
 230
 231          <pre>accept hosts = 127.0.0.1</pre>
 232
 233          <h4><a href="#index" id="rctune">Tuning of numbers of recipients</a></h4>
 234
 235          <p>By default Mailman will send up to 500 recipients on each message it injects into exim.  However this is not necessarily a good configuration for exim since it will route all those recipients before starting deliveries to any of them. Additionally some ACL configurations have tests on the maximum number of recipients (which is a good reason for having a get out ACL for list traffic as described above)</p>
 236
 237          <p>I would suggest setting Mailman to send a maximum of 5 to 50 recipients on a single mail (setting it lower decreases list latency, but increases the work that Mailman and exim have to do), and change it to send a maximum of 30 messages per SMTP connection.  To reflect this you should also change the exim parameter smtp_accept_queue_per_connection to be 30 as well.</p>
 238
 239          <p>For example, add the following lines to ~mailman/Mailman/mm_cfg.py:</p>
 240
 241          <pre># Max recipients for each message
 242 SMTP_MAX_RCPTS = 15
 243 # Max messages sent in each SMTP connection
 244 SMTP_MAX_SESSIONS_PER_CONNECTION = 30</pre>
 245
 246          <p>Tuning a mailing list system is very much a black art, and depends on the type of lists you host, their throughput, size and the bandwidth available.  In general, tuning is only a significant issue if you are pushing your system near its operational limits.</p>
 247
 248          <h3><a href="#index" id="verpin">Doing VERP and personalisation with exim and Mailman</a></h3>
 249
 250          <h4><a href="#index" id="verpmm">VERP within Mailman</a></h4>
 251
 252          <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>
 253
 254          <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>
 255
 256          <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>
 257
 258          <pre>VERP_PASSWORD_REMINDERS      = 1
 259 VERP_PERSONALIZED_DELIVERIES = 1
 260 VERP_CONFIRMATIONS           = 1
 261 VERP_DELIVERY_INTERVAL       = 1</pre>
 262
 263          <p>(The router and ACLs above are smart enough to deal with VERP bounces.)</p>
 264
 265          <p>This configuration on its own will make the monthly password reminders, confirmations and all list postings be sent out using VERP</p>
 266
 267          <p>If you wish to have the advantages of VERP with a lower bandwidth cost, you can enable VERP on occasional list postings rather than on every posting.  Mailman will still VERP on all password reminders and confirmations (these are already inherently single recipient mailings), but only on occasional list postings. To make Mailman use VERP on every twentieth list posting (using bulk delivery for the other 19), change:-</p>
 268
 269          <pre>VERP_DELIVERY_INTERVAL = 20</pre>
 270
 271          <p>The downside to doing this is that Mailman may fail to notice a bouncing address if it does not receive at least one bounce per day, so ideally this approach should only be taken if the lists have more than 20 message per day throughput.</p>
 272
 273          <h4><a href="#index" id="persmm">Mailing list personalisation by Mailman</a></h4>
 274
 275          <p>Mailman can also personalise each message it sends out on a list.  This allows, for example, the recipient's own address to appear as the To: header, or information specific to them to be placed in the mail footer (although at present personalisation can only be done for normal mail delivery - not for digest subscribers).  This personalisation comes at a cost of an individual message per recipient (ie same bandwidth requirements as full VERP) and some processing costs for Mailman.</p>
 276
 277          <p>To enable personalisation, add the following configuration item to ~mailman/Mailman/mm_cfg.py (you should also set the VERP settings from above since you have already incurred the costs of VERP):-</p>
 278
 279          <pre>OWNERS_CAN_ENABLE_PERSONALIZATION = 1</pre>
 280
 281          <p>You will then find that in the list administration web interface a new set of options has appeared in the <i>Non-digest options</i> section.</p>
 282
 283          <h4><a href="#index" id="verpex">VERP expansion by exim rather than Mailman</a></h4>
 284
 285          <p>One drawback of VERP is that as well as increasing the bandwidth outgoing mail requires, it also causes Mailman to send one separate message per recipient from Mailman to exim - causing exim to have many many more queue entries and consequently more queue disk space.  For example a 20,000 recipient list would require 400MB minimum temporary queue storage for each 20KB message sent to the list.  There are also issues of increasing disk traffic/throughput and losing some disk caching advantages.</p>
 286
 287          <p>These local load problems can be overcome by doing the VERP expansion as the message is sent out from the MTA over network SMTP rather than as the message is injected into the MTA.  It will come as no surprise that exim can be configured to do just this.</p>
 288
 289          <p>Firstly we need to pick up outgoing Mailman mail and send it to a specialised VERP transport.  This is done using a router which should be placed just before your normal dnslookup router for remote addresses:-</p>
 290
 291          <pre><![CDATA[# Pick up on messages from our local mailman and route them via our
 292 # special VERP-enabled transport
 293 #
 294 mailman_verp_router:
 295 driver = dnslookup
 296 # we only consider messages sent in through loopback
 297 condition = ${if or{{eq{$sender_host_address}{127.0.0.1}} \
 298                     {eq{$sender_host_address}{::1}}}{yes}{no}}
 299 # we do not do this for traffic going to the local machine
 300 domains = !+local_domains:!+mm_domains
 301 ignore_target_hosts = <; 0.0.0.0; \
 302                          64.94.110.11; \
 303                          127.0.0.0/8; \
 304                          ::1/128;fe80::/10;fe \
 305                          c0::/10;ff00::/8
 306 # only the un-VERPed bounce addresses are handled
 307 senders = "*-bounces@*"
 308 transport = mailman_verp_smtp]]></pre>
 309
 310          <p>Addresses selected by this router should then be passed on to an SMTP transport that does VERP expansion.  This should be placed anywhere within the transport section:-</p>
 311
 312          <pre># Mailman VERP envelope sender address formatting.  This seems not to use
 313 # quoted-printable encoding of the address, but instead just replaces the
 314 # '@' in the recipient address with '='.
 315 #
 316 mailman_verp_smtp:
 317   driver = smtp
 318 # put recipient address into return_path
 319   return_path = \
 320     ${local_part:$return_path}+$local_part=$domain@${domain:$return_path}
 321 # must restrict to one recipient at a time
 322   max_rcpt = 1
 323 # Errors-To: may carry old return_path
 324   headers_remove = Errors-To
 325   headers_add = Errors-To: ${return_path}</pre>
 326
 327          <p>Once this has been configured, Mailman can be set to not do VERP expansion on normal list deliveries - the VERP configuration should now look like:-</p>
 328
 329          <pre>VERP_PASSWORD_REMINDERS      = 1
 330 VERP_PERSONALIZED_DELIVERIES = 1
 331 VERP_CONFIRMATIONS           = 1
 332 VERP_DELIVERY_INTERVAL       = 0</pre>
 333
 334          <p>If you have set personalisation on any list, this will still be handled, and VERPed, by Mailman.</p>
 335
 336          <h3><a href="#index" id="virdom">Virtual domains</a></h3>
 337
 338          <p>One approach to handling virtual domains is to use a separate Mailman installation for each virtual domain.  (Currently, this is the only way to have lists with the same name in different virtual domains handled by the same machine.)</p>
 339
 340          <p>In this case, you must change the MM_HOME macro to something like this:-</p>
 341
 342          <pre>MM_HOME=/virtual/${lc:$domain_data}/mailman</pre>
 343
 344          <p>and modify the mm_domains domain list appropriately.</p>
 345
 346          <h3><a href="#index" id="lispol">List policy management</a></h3>
 347
 348          <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>
 349
 350          <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 accept clause early on in your ACLs that causes Mailman generated traffic to bypass the machine intensive checks.</p>
 351
 352          <h4><a href="#index" id="conpol">Content scanning</a></h4>
 353
 354          <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>
 355
 356          <p>The best way to do this is using the <a href="https://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>
 357
 358          <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>
 359
 360          <h4><a href="#index" id="incpol">Incoming message checks</a></h4>
 361
 362          <p>You may wish to apply various checks to incoming messages to ensure that they are sane.  These may include:-</p>
 363
 364          <ul>
 365             <li>DNSBL checks</li>
 366             <li>Header checks</li>
 367             <li>Sender callback verification</li>
 368          </ul>
 369
 370          <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>
 371
 372          <h4><a href="#index" id="mmapol">Mailman specific ACL checks</a></h4>
 373
 374          <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>
 375
 376          <pre># Reject bounce (null sender) messages to the list
 377 deny message   = "Recipient never sends mail so cannot cause bounces"
 378      senders   = :
 379      domains   = +mm_domains
 380      condition = ${if exists{MM_LISTCHK} {yes}{no}}</pre>
 381
 382          <p>Additionally other mailman addresses do not generate mail (as the envelope sender, although they may be mentioned in the header addresses.  The ACL is split into 2 so that it can be written without the local_part condition wrapping.</p>
 383
 384          <pre># Reject bounce (null sender) messages to the list
 385 deny message     = "Recipient never sends mail so cannot cause bounces"
 386      senders     = :
 387      domains     = +mm_domains
 388      local_parts = \N^.*-(admin|join|leave|owner|request)$\N
 389 deny message     = "Recipient never sends mail so cannot cause bounces"
 390      senders     = :
 391      domains     = +mm_domains
 392      local_parts = \N^.*-(subscribe|unsubscribe)$\N</pre>
 393
 394          <h4><a href="#index" id="smtune">SMTP callbacks</a></h4>
 395
 396          <p>Exim's SMTP callback feature is an even more powerful way to detect bogus sender addresses than normal sender verification. They are specially useful for checking envelope sender addresses at RCPT time within SMTP, and have been to date the most effective single anti-SPAM measure (however it should be noted that CBV is hated vehemently by some mail admins, and does increase both latency and traffic, as well as theoretically being a means to set up a DDOS situation).</p>
 397
 398          <p>It is recommended that SMTP Sender CBV is not carried out on messages to the Mailman bounce handlers, so that broken remote MTAs (specifcally ones which send bounces with something other than a null sender address) do not get excluded from being taken off mailing lists</p>
 399
 400          <pre># Do callback verification unless Mailman incoming bounce
 401 deny !local_parts = *-bounces : *-bounces+*
 402      !verify = sender/callout=30s,defer_ok</pre>
 403
 404          <p>Callback verification can also be done on header addresses, but care should be taken not to reject messages unnecessarily, especially when the message is going to Mailman's bounce processor</p>
 405
 406          <h3><a href="#index" id="lisver">List verification</a></h3>
 407
 408          <p>This is how a set of address tests for the Exim lists look on a working system.  The list in question is testlist@list.example.com, and these commands were run on the list.example.com mail server ("% "indicates the Unix shell prompt):</p>
 409
 410          <pre>% exim -bt testlist@list.example.com
 411 testlist@list.example.com
 412 router = mailman_router, transport = mailman_transport
 413
 414 % exim -bt testlist-request@list.example.com
 415 testlist-request@list.example.com
 416 router = mailman_router, transport = mailman_transport
 417
 418 % exim -bt testlist-bounces@list.example.com
 419 testlist-bounces@list.example.com
 420 router = mailman_router, transport = mailman_transport
 421
 422 % exim -bt testlist-bounces+luser=example.com@list.example.com
 423 testlist-bounces+luser=example.com@list.example.com
 424 router = mailman_router, transport = mailman_transport</pre>
 425
 426          <p>If your "exim -bt" output looks something like this, that's a start: at least it means Exim will pass the right messages to the right Mailman commands.  It by no means guarantees that your Exim/Mailman installation is functioning perfectly, though!</p>
 427
 428          <h3><a href="#index" id="problem">Possible Problems</a></h3>
 429
 430          <ul>
 431             <li> Mailman will send as many MAIL FROM/RCPT TO as it needs. It may result in more than 10 or 100 messages sent in one connection, which will exceed the default value of Exim's smtp_accept_queue_per_connection This is bad because it will cause Exim to switch into queue mode and severely delay delivery of your list messages.  The way to fix this is to set mailman's SMTP_MAX_SESSIONS_PER_CONNECTION (in ~mailman/Mailman/mm_cfg.py) to a smaller value than Exim's smtp_accept_queue_per_connection</li>
 432
 433             <li>Mailman should ignore Exim delay warning messages, even though Exim should never send this to list messages.  Mailman 2.1's general bounce detection and VERP support should greatly improve the bounce detector's hit rates.</li>
 434
 435             <li>List existence is determined by the existence of a config.pck file for a list.  If you delete lists by foul means, be aware of this.</li>
 436
 437             <li>If you are getting Exim or Mailman complaining about user ids when you send mail to a list, check that the MM_UID and MM_GID match those of Mailman itself (i.e. what were used in the configure script). Also make sure you do not have aliases in the main alias file for the list.</li>
 438
 439          </ul>
 440
 441          <h3><a href="#index" id="dochis">Document History</a></h3>
 442
 443          <ul>
 444             <li>Originally written by Nigel Metheringham.</li>
 445             <li>Updated by Marc Merlin for Mailman 2.1, Exim 4</li>
 446             <li>Overhauled/reformatted/clarified/simplified by Greg Ward.</li>
 447             <li>Rehashed again by Nigel Metheringham</li>
 448          </ul>
 449
 450          <h4><a href="#index" id="doccha">Document Changes</a></h4>
 451
 452          <ul>
 453             <li><b>14 June 2004</b> Originally written by Nigel Metheringham.</li>
 454
 455             <li><b>28 June 2004</b> Fixed a problem with the Exim VERP transport which caused locally aliased recipient addresses to have incorrect VERP extensions added.  Followed posting to exim-users list by Arkadiusz Miskiewicz -- <i>Nigel Metheringham</i>.</li>
 456             <li><b>19 November 2004</b> Fixed previously unnoticed brainstorm where reject had been used as a ACL verb rather than deny.  Fixes to the VERP router/transport pair. -- <i>Nigel Metheringham</i></li>
 457
 458          </ul>
 459
 460
 461          <h3><a href="#index" id="docfin">Final Word</a></h3>
 462
 463          <p>Like many documents of this type, it has evolved and taken on contributions by many many helpful folks, mainly those on the Mailman and exim mailing lists.  To all of you, who have made contributions yet had their names shamefully lost by me, <i>Thank You</i>.</p>
 464
 465       </xsl:template>
 466 </xsl:stylesheet>