howto/mailman21.html

   1 <!-- -*-html-*- -->
   2 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
   3 <html>
   4   <head>
   5     <title>HOWTO - Using Exim 4 and Mailman together</title>
   6     <style type="text/css">
   7       body { color: #00005a; background: white; }
   8       a:link { color: #ff6600; }
   9       a:visited { color: #990000; }
  10       a:hover { color: #ff9933; }
  11     </style>
  12   </head>
  13   <body>
  14     <h1>HOWTO - Using Exim 4 and Mailman 2.1 together</h1>
  15
  16     <p>Mailman is a list manager with web front end and built in
  17     archiving functions.  Details can be found at <a
  18     href="http://www.list.org/"> http://www.list.org/</a>.  This
  19     documentation describes the configuration of Exim (version 4) to
  20     work with Mailman version 2.1</p>
  21
  22     <h2><a name="index">Index</a></h2>
  23
  24     <ul>
  25       <li><a href="#scope">Scope of this document</a></li>
  26       <li><a href="#basic">Basic Configuration</a></li>
  27     <ul>
  28       <li><a href="#mmconf">Mailman configuration</a></li>
  29       <li><a href="#exconf">Exim configuration</a></li>
  30       <li><a href="#maconf">Main configuration settings</a></li>
  31       <li><a href="#roconf">Exim Router</a></li>
  32       <li><a href="#taconf">Exim Transport</a></li>
  33     </ul>
  34     <li><a href="#batune">Basic mailing list MTA tuning</a></li>
  35     <ul>
  36       <li><a href="#retune">Receiver verification</a></li>
  37       <li><a href="#rctune">Tuning of numbers of recipients</a></li>
  38       <li><a href="#smtune">SMTP callback</a></li>
  39     </ul>
  40     <li><a href="#verpin">Doing VERP and personalisation with exim
  41  and Mailman</a></li>
  42     <ul>
  43       <li><a href="#verpmm">VERP within Mailman</a></li>
  44       <li><a href="#persmm">Mailing list personalisation by Mailman</a></li>
  45       <li><a href="#verpex">VERP expansion by Exim rather than
  46    Mailman</a></li>
  47     </ul>
  48     <li><a href="#virdom">Virtual domains</a></li>
  49     <li><a href="#lispol">List policy management</a></li>
  50     <ul>
  51       <li><a href="#conpol">Content scanning</a></li>
  52       <li><a href="#incpol">Incoming message checks</a></li>
  53       <li><a href="#mmapol">Mailman specific ACL checks</a></li>
  54     </ul>
  55     <li><a href="#lisver">List verification</a></li>
  56     <li><a href="#problem">Possible Problems</a></li>
  57     <li><a href="#dochis">Document History</a></li>
  58     <li><a href="#doccha">Document Changes</a></li>
  59     <li><a href="#docfin">Final Word</a></li>
  60   </ul>
  61
  62     <h2><a href="#index"><a name="scope">Scope of this document</a></a></h2>
  63
  64     <p>This document describes how to set up a basic working
  65     configuration using Exim 4 as an MTA for the Mailman MLM.  The
  66     assumption is made that the receiving MTA, Mailman and the list
  67     distribution MTA are all on the same machine, and that Mailman
  68     talks to Exim using SMTP to address <tt>127.0.0.1</tt></p>
  69
  70     <p>It also describes ways of using VERP delivery, both
  71     conventionally (doing VERP from Mailman), and an alternative more
  72     efficient technique where VERP expansion is done within exim.</p>
  73
  74     <p>Tuning and setting appropriate mailing list protection policies
  75     is also covered in passing.</p>
  76
  77     <p>General installation, use, running and administration of either
  78     Mailman or exim is not covered here - the documentation for the
  79     programs concerned should be read for this information.</p>
  80
  81     <h2><a href="#index"><a name="basic">Basic Configuration</a></a></h2>
  82
  83     <h3><a href="#index"><a name="mmconf">Mailman configuration</a></a></h3>
  84
  85     <p>For basic operation there is no Mailman configuration needed
  86     other than the standard options detailed in the Mailman install
  87     documentation.  The user/group settings for Mailman must match
  88     those in the config fragments given below, and you need to have at
  89     least configured <tt>DEFAULT_URL_HOST</tt> and
  90     <tt>DEFAULT_EMAIL_HOST</tt> within Mailman, for example by editing
  91     <tt>~mailman/Mailman/mm_cfg.py</tt> and setting the following
  92     (substituting in your own domains):-</p>
  93
  94 <pre>
  95   # The host part of the URL used for your mailman install
  96   DEFAULT_URL_HOST = 'www.example.com'
  97   #
  98   # The email domain of your lists
  99   DEFAULT_EMAIL_HOST = 'list.example.com'
 100   #
 101   # Let Mailman know that the MTA needs no aliases setting
 102   MTA = None
 103 </pre>
 104
 105     <p>The final setting above informs Mailman that it does not need
 106     to prompt you to add aliases when creating a list (like Sendmail),
 107     or modify other settings (like Postfix).  Not setting this will
 108     mean that Mailman nags you to do things that aren't necessary in
 109     an Exim configuration.</p>
 110
 111     <p>After making a change to the Mailman configuration file you
 112     need to restart the Mailman queue runners.</p>
 113
 114 <pre>
 115   ~mailman/bin/mailmanctl restart
 116 </pre>
 117
 118     <p>Mailman should also be set to deliver to the MTA using SMTP -
 119     this is done by having <tt>DELIVERY_MODULE = 'SMTPDirect'</tt> in
 120     the config file (which is the default mode of operation)</p>
 121
 122
 123     <h3><a href="#index"><a name="exconf">Exim configuration</a></a></h3>
 124
 125     <p>The Exim configuration is built so that a list created within
 126     Mailman automatically appears to Exim without the need for
 127     defining any additional aliases (however Mailman may helpfully
 128     show or email you a list of required aliases when you create a
 129     list - you can just ignore those - if you have set the
 130     <tt>MTA</tt> parameter it will stop doing this).</p>
 131
 132     <p>The drawback of this configuration is that it will work poorly
 133     on systems supporting lists in several different mail domains.
 134     While Mailman handles virtual domains, it does not yet support
 135     having two distinct lists with the same name in different virtual
 136     domains, using the same Mailman installation.  This will
 137     eventually change.  (But see below for a variation on this scheme
 138     that should accommodate virtual domains better.)</p>
 139
 140     <p>The configuration file excerpts below are for use in an already
 141     functional Exim configuration.  You also need to have an alias for
 142     <tt>mailman</tt> within the <tt>mm_domains</tt>, this picks up
 143     mail sent to the site list (or basically just sent in error), and
 144     should forward to the Mailman Administrator.  It appears that a
 145     couple of Mailman messages mention the <tt>mailman-admin</tt>
 146     address (this appears to be an error in Mailman or maybe a
 147     packaging error), so I would suggest that <tt>mailman-admin</tt>
 148     is aliased also to the Mailman Administrator.</p>
 149
 150     <p><i>[Note: the instructions in this document will work only with
 151     Exim 4.  It may be possible to adapt them for Exim 3, but frankly
 152     it is not worth the trouble]</i></p>
 153
 154     <p>You will need to add some macros to the main section of your
 155     Exim config file.  You will also need to define one new transport
 156     and add new routers.  Additional ACLs may be used to handle policy
 157     enforcement.  Remember that the exim daemon needs restarting
 158     before it sees configuration changes.</p>
 159
 160     <h3><a href="#index"><a name="maconf">Main configuration settings</a></a></h3>
 161
 162     <p>First, you need to add some macros to the top of your Exim
 163     config file.  These just make the routers and transport below a
 164     bit cleaner.  Obviously, you'll need to edit these based on how
 165     you configured and installed Mailman.</p>
 166
 167 <pre>
 168   # Home dir for your Mailman installation -- aka Mailman's prefix
 169   # directory.
 170   # By default this is set to "/usr/local/mailman"
 171   # On a Red Hat/Fedora system using the RPM use "/var/mailman"
 172   # On Debian using the deb package use "/var/lib/mailman"
 173   # This is normally the same as ~mailman
 174   MM_HOME=/var/mailman
 175   #
 176   # User and group for Mailman, should match your --with-mail-gid
 177   # switch to Mailman's configure script.
 178   # Value is normally "mailman"
 179   MM_UID=mailman
 180   MM_GID=mailman
 181   #
 182   # Domains that your lists are in - colon separated list
 183   # you may wish to add these into local_domains as well
 184   domainlist mm_domains=list.example.com
 185   #
 186   # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 187   #
 188   # These values are derived from the ones above and should not need
 189   # editing unless you have munged your mailman installation
 190   #
 191   # The path of the Mailman mail wrapper script
 192   MM_WRAP=MM_HOME/mail/mailman
 193   #
 194   # The path of the list config file (used as a required file when
 195   # verifying list addresses)
 196   MM_LISTCHK=MM_HOME/lists/${lc::$local_part}/config.pck
 197 </pre>
 198
 199     <h3><a href="#index"><a name="roconf">Exim Router</a></a></h3>
 200
 201     <p>This router picks up all the addresses going to the Mailman
 202     lists.  Initially it selects only the domains that have may have
 203     lists in, then selects where <tt>local_part</tt> matches a list
 204     name (ie you can see a list config file).  The suffixes pick up
 205     all the Mailman admin addresses<p>
 206
 207     <p>The router should be placed in the router section (ie somewhere
 208     after the <tt>"begin routers"</tt> line of your config file).
 209     Normally you would place it just after the aliases router (since
 210     that will pick up the <tt>mailman</tt> master contact
 211     address).</p>
 212
 213 <pre>
 214   mailman_router:
 215     driver = accept
 216     domains = +mm_domains
 217     require_files = MM_LISTCHK
 218     local_part_suffix_optional
 219     local_part_suffix = -admin     : \
 220  -bounces   : -bounces+* : \
 221                         -confirm   : -confirm+* : \
 222  -join      : -leave     : \
 223  -owner    : -request   : \
 224  -subscribe : -unsubscribe
 225     transport = mailman_transport
 226 </pre>
 227
 228     <h3><a href="#index"><a name="taconf">Exim Transport</a></a></h3>
 229
 230     <p>The transport for Exim 4 can be placed anywhere where under the
 231     <tt>begin transports</tt> line of your Exim config file.</p>
 232
 233     <p>The <tt>if def:local_part_suffix</tt> section selects whether
 234     the suffix is used as the mailman command, or whether there is no
 235     suffix and so <tt>post</tt> is passed as a command.</p>
 236
 237     <p>The <tt>sg</tt> phrase strips the VERP information (if any)
 238     from the suffix,</p>
 239
 240 <pre>
 241   mailman_transport:
 242     driver = pipe
 243     command = MM_WRAP \
 244               '${if def:local_part_suffix \
 245                     {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
 246                     {post}}' \
 247               $local_part
 248     current_directory = MM_HOME
 249     home_directory = MM_HOME
 250     user = MM_UID
 251     group = MM_GID
 252 </pre>
 253
 254
 255     <h2><a href="#index"><a name="batune">Basic mailing list MTA tuning</a></a></h2>
 256
 257     <p>Exim has a lot configurability, especially where the ACL
 258     (Access Control Lists) used during SMTP reception are concerned.
 259     MTA policy needs to be tuned so that list traffic is not affected
 260     by ACLs intended for qualifying traffic coming in from outside.
 261     Later in this document some suggestions are made regarding
 262     filtering traffic that is going into the mailing list, however
 263     </p>
 264
 265     <h3><a href="#index"><a name="retune">Receiver verification</a></a></h3>
 266
 267     <p>Exim's receiver verification feature is very useful -- it lets
 268     Exim reject unrouteable addresses at SMTP time.  However, this is
 269     most useful for externally-originating mail that is addresses to
 270     mail in one of your local domains.  For Mailman list traffic, mail
 271     originates on your server, and is addressed to random external
 272     domains that are not under your control.  Furthermore, each
 273     message is addressed to many recipients -- up to 500 if you use
 274     Mailman's default configuration, and don't tweak
 275     <tt>SMTP_MAX_RCPTS</tt>.</p>
 276
 277     <p>Doing receiver verification on Mailman list traffic is a recipe
 278     for trouble.  In particular, Exim will attempt to route every
 279     recipient addresses in outgoing Mailman list posts.  Even though
 280     this requires nothing more than a few DNS lookups for each
 281     address, it can still introduce significant delays (because these
 282     verifications have to be done serially as you attempt handoff to
 283     exim).  Therefore, you should disable recipient verification for
 284     Mailman traffic.</p>
 285
 286     <p>Under Exim 4, this is probably already taken care of for you by
 287     the default recipient verification ACL statement (in the "RCPT TO"
 288     ACL):</p>
 289
 290 <pre>
 291   accept  domains       = +local_domains
 292           endpass
 293           message       = unknown user
 294           verify        = recipient
 295 </pre>
 296
 297     <p>which only does recipient verification on addresses in your
 298     domain.  (That's not exactly the same as doing recipient
 299     verification only on messages coming from non-127.0.0.1 hosts, but
 300     it should do the trick for Mailman).  Obviously if the next ACL
 301     does verification on non-local addresses you will need to deal
 302     with that.</p>
 303
 304     <p>Alternatively you can add an early get-out in the "RCPT TO"
 305     ACL), which <i>trusts</i> all traffic coming from the loopback IP
 306     address:</p>
 307
 308 <pre>
 309   accept  hosts         = 127.0.0.1
 310 </pre>
 311
 312     <h3><a href="#index"><a name="rctune">Tuning of numbers of recipients</a></a></h3>
 313
 314     <p>By default Mailman will send up to 500 recipients on each
 315     message it injects into exim.  However this is not necessarily a
 316     good configuration for exim since it will route all those
 317     recipients before starting deliveries to any of them.
 318     Additionally some ACL configurations have tests on the maximum
 319     number of recipients (which is a good reason for having a get out
 320     ACL for list traffic as described above)</p>
 321
 322     <p>I would suggest setting Mailman to send a maximum of 5 to 50
 323     recipients on a single mail (setting it lower decreases list
 324     latency, but increases the work that Mailman and exim have to do),
 325     and change it to send a maximum of 30 messages per SMTP
 326     connection.  To reflect this you should also change the exim
 327     parameter <tt>smtp_accept_queue_per_connection</tt> to be 30 as
 328     well.</p>
 329
 330     <p>For example, add the following lines to
 331     <tt>~mailman/Mailman/mm_cfg.py</tt>:</p>
 332
 333 <pre>
 334   # Max recipients for each message
 335   SMTP_MAX_RCPTS = 15
 336   # Max messages sent in each SMTP connection
 337   SMTP_MAX_SESSIONS_PER_CONNECTION = 30
 338 </pre>
 339
 340     <p>Tuning a mailing list system is very much a black art, and
 341     depends on the type of lists you host, their throughput, size and
 342     the bandwidth available.  In general, tuning is only a significant
 343     issue if you are pushing your system near its operational
 344     limits.</p>
 345
 346     <h2><a href="#index"><a name="verpin">Doing VERP and personalisation with exim and Mailman</a></a></h2>
 347
 348     <h3><a href="#index"><a name="verpmm">VERP within Mailman</a></a></h3>
 349
 350     <p><a href="http://cr.yp.to/proto/verp.txt">VERP</a> (Variable
 351     Envelope Return Paths) encodes the (original) receipient address
 352     in the sender address.  The reason for doing this is that it means
 353     bounces are sent to an address which has the original recipient
 354     address encoded in it - meaning you know which recipient address
 355     caused the bounce.  This makes automatic bounce handling very
 356     effective - the normal method of parsing the bouncing address out
 357     of the bounce message is very prone to failure, especially in the
 358     case of foreign MTAs which use different addressing standards, or
 359     where mail forwarding is involved.</p>
 360
 361     <p>VERP will send one email, with a separate envelope sender
 362     (return path), for each of your subscribers - this means that it
 363     will generate more traffic since you cannot bundle up deliveries
 364     together.  An <a
 365     href="http://www.python.org/cgi-bin/faqw-mm.py?req=show%26file=faq04.012.htp">analysis
 366     of the costs of VERP</a> can be found in the <a
 367     href="http://www.python.org/cgi-bin/faqw-mm.py">Mailman FAQ
 368     Wizard</a>.</p>
 369
 370     <p>VERP settings within Mailman are done on a per-installation
 371     basis - ie they affect all the lists within the installation. To
 372     configure VERP within Mailman read the information in
 373     <tt>~mailman/Mailman/Default.py</tt> for the options that start
 374     with <tt>VERP</tt>.  In a nutshell, all you need to do to enable
 375     VERP with Exim is to add these lines to
 376     <tt>~mailman/Mailman/mm_cfg.py</tt>:</p>
 377
 378 <pre>
 379   VERP_PASSWORD_REMINDERS = 1
 380   VERP_PERSONALIZED_DELIVERIES = 1
 381   VERP_CONFIRMATIONS = 1
 382   VERP_DELIVERY_INTERVAL = 1
 383 </pre>
 384
 385     <p>(The router and ACLs above are smart enough to deal with VERP
 386     bounces.)</p>
 387
 388     <p>This configuration on its own will make the monthly password
 389     reminders, confirmations and all list postings be sent out using
 390     VERP</p>
 391
 392     <p>If you wish to have the advantages of VERP with a lower
 393     bandwidth cost, you can enable VERP on occasional list postings
 394     rather than on every posting.  Mailman will still VERP on all
 395     password reminders and confirmations (these are already inherently
 396     single recipient mailings), but only on occasional list postings.
 397     To make Mailman use VERP on every twentieth list posting (using
 398     bulk delivery for the other 19), change:-</p>
 399
 400 <pre>
 401   VERP_DELIVERY_INTERVAL = 20
 402 </pre>
 403
 404     <p>The downside to doing this is that Mailman may fail to notice a
 405     bouncing address if it does not receive at least one bounce per
 406     day, so ideally this approach should only be taken if the lists
 407     have more than 20 message per day throughput.</p>
 408
 409     <h3><a href="#index"><a name="persmm">Mailing list personalisation by Mailman</a></a></h3>
 410
 411     <p>Mailman can also personalise each message it sends out on a
 412     list.  This allows, for example, the recipient's own address to
 413     appear as the To: header, or information specific to them to be
 414     placed in the mail footer (although at present personalisation can
 415     only be done for normal mail delivery - not for digest
 416     subscribers).  This personalisation comes at a cost of an
 417     individual message per recipient (ie same bandwidth requirements
 418     as full VERP) and some processing costs for Mailman.</p>
 419
 420     <p>To enable personalisation, add the following configuration item
 421     to <tt>~mailman/Mailman/mm_cfg.py</tt> (you should also set the
 422     VERP settings from above since you have already incurred the costs
 423     of VERP):-</p>
 424
 425 <pre>
 426   OWNERS_CAN_ENABLE_PERSONALIZATION = 1
 427 </pre>
 428
 429     <p>You will then find that in the list administration web
 430     interface a new set of options has appeared in the <i>Non-digest
 431     options</i> section.</p>
 432
 433     <h3><a href="#index"><a name="verpex">VERP expansion by exim rather than Mailman</a></a></h3>
 434
 435     <p>One drawback of VERP is that as well as increasing the
 436     bandwidth outgoing mail requires, it also causes Mailman to send
 437     one separate message per recipient from Mailman to exim - causing
 438     exim to have many many more queue entries and consequently more
 439     queue disk space.  For example a 20,000 recipient list would
 440     require 400MB minimum temporary queue storage for each 20KB
 441     message sent to the list.  There are also issues of increasing
 442     disk traffic/throughput and losing some disk caching
 443     advantages.</p>
 444
 445     <p>These local load problems can be overcome by doing the VERP
 446     expansion as the message is sent out from the MTA over network
 447     SMTP rather than as the message is injected into the MTA.  It will
 448     come as no surprise that exim can be configured to do just
 449     this.</p>
 450
 451     <p>Firstly we need to pick up outgoing Mailman mail and send it to
 452     a specialised VERP transport.  This is done using a router which
 453     should be placed just before your normal <tt>dnslookup</tt> router
 454     for remote addresses:-</p>
 455
 456 <pre>
 457   # Pick up on messages from our local mailman and route them via our
 458   # special VERP-enabled transport
 459   #
 460   mailman_verp_router:
 461     driver = dnslookup
 462     # we only consider messages sent in through loopback
 463     condition = ${if or{{eq{$sender_host_address}{127.0.0.1}}
 464                         {eq{$sender_host_address}{::1}}}{yes}{no}}
 465     # we do not do this for traffic going to the local machine
 466     domains = !+local_domains:!+mm_domains
 467     ignore_target_hosts = <; 0.0.0.0; \
 468                              64.94.110.11; \
 469                              127.0.0.0/8; \
 470                              ::1/128;fe80::/10;fe \
 471                              c0::/10;ff00::/8
 472     # only the un-VERPed bounce addresses are handled
 473     senders = "*-bounces@*"
 474     transport = mailman_verp_smtp
 475 </pre>
 476
 477     <p>Addresses selected by this router should then be passed on to
 478     an SMTP transport that does VERP expansion.  This should be placed
 479     anywhere within the transport section:-</p>
 480
 481 <pre>
 482   # Mailman VERP envelope sender address formatting.  This seems not to use
 483   # quoted-printable encoding of the address, but instead just replaces the
 484   # '@' in the recipient address with '='.
 485   #
 486   mailman_verp_smtp:
 487     driver = smtp
 488     # put recipient address into return_path
 489     return_path = \
 490       ${local_part:$return_path}+$local_part=$domain@${domain:$return_path}
 491     # must restrict to one recipient at a time
 492     max_rcpt = 1
 493     # Errors-To: may carry old return_path
 494     headers_remove = Errors-To
 495     headers_add = Errors-To: ${return_path}
 496 </pre>
 497
 498     <p>Once this has been configured, Mailman can be set to not do
 499       VERP expansion on normal list deliveries - the VERP
 500       configuration should now look like:-</p>
 501 <pre>
 502   VERP_PASSWORD_REMINDERS = 1
 503   VERP_PERSONALIZED_DELIVERIES = 1
 504   VERP_CONFIRMATIONS = 1
 505   VERP_DELIVERY_INTERVAL = 0
 506 </pre>
 507
 508     <p>If you have set personalisation on any list, this will still be
 509     handled, and VERPed, by Mailman.</p>
 510
 511     <h2><a href="#index"><a name="virdom">Virtual domains</a></a></h2>
 512
 513     <p>One approach to handling virtual domains is to use a separate
 514     Mailman installation for each virtual domain.  (Currently, this is
 515     the only way to have lists with the same name in different virtual
 516     domains handled by the same machine.)</p>
 517
 518     <p>In this case, you must change the <tt>MM_HOME</tt> macro to
 519     something like this:-</p>
 520
 521 <pre>
 522   MM_HOME=/virtual/${lc::$domain}/mailman
 523 </pre>
 524
 525     <p>and modify the <tt>mm_domains</tt> domain list appropriately.</p>
 526
 527     <h2><a href="#index"><a name="lispol">List policy management</a></a></h2>
 528
 529     <p>Most list policy handling is done within Mailman using the Web
 530     GUI.  However some issues may be better handled by the MTA,
 531     especially matters of overall site policy (not just mailing list
 532     policy).  For example you may wish to do virus or spam scanning on
 533     incoming messages.</p>
 534
 535     <p>In general you exclude outgoing list mail from any policy
 536     controls.  This is because outgoing list mail has already been
 537     through the policy controls on the way into the system.
 538     Additionally spam scanning (for example) is a machine intensive
 539     operation, and scanning a message that has already been scanned,
 540     and then replicated to many recipients, is going to be very
 541     expensive as well as ineffective.  For this reason you will
 542     normally have an <tt>accept</tt> clause early on in your ACLs that
 543     causes Mailman generated traffic to bypass the machine intensive
 544     checks.</p>
 545
 546     <h3><a href="#index"><a name="conpol">Content scanning</a></a></h3>
 547
 548     <p>I would recommend that mailing lists now scan for both spam and
 549     viruses on incoming mail - this is due to the potential for a
 550     compromised windows machine belonging to a subscriber managing to
 551     distribute unwanted content via the list.  This causes problems
 552     not only to the list reputation, but also to the list manager who
 553     will get many many bounces from subscribers who do content
 554     scanning on their own incoming mail.</p>
 555
 556     <p>The best way to do this is using the <a
 557     href="http://duncanthrax.net/exiscan-acl/">exiscan</a> extension
 558     along with a virus scanner such as <a
 559     href="http://duncanthrax.net/exiscan-acl/">clam-av</a> and a spam
 560     content scanner such as <a
 561     href="http://www.spamassassin.org/">SpamAssassin</a>. Configuring
 562     these is beyond the scope of this document, however Tim Jackson
 563     has a very good set of <a
 564     href="http://www.timj.co.uk/linux/Exim-SpamAndVirusScanning.pdf">PDF
 565     documentation</a> on integrating these.</p>
 566
 567     <p>One thing to note is that if you add full SpamAssassin headers
 568     onto list messages this bulks up the messages significantly.
 569     These headers are also available to list subscribers, which might
 570     make it easier for someone malicious to work out how to evade your
 571     spam scanning strategy.  I would suggest that Spam headers are not
 572     added for Mailman incoming mail, or minimal (short) headers added,
 573     or that they are stripped somewhere.  However having minimal
 574     headers on means that you can, for example, moderate all messages
 575     which have a given spam rating (as well as bouncing messages with
 576     a very high rating).</p>
 577
 578     <h3><a href="#index"><a name="incpol">Incoming message checks</a></a></h3>
 579
 580     <p>You may wish to apply various checks to incoming messages to
 581     ensure that they are sane.  These may include:-</p>
 582
 583     <ul>
 584       <li>DNSBL checks</li>
 585       <li>Header checks</li>
 586       <li>Sender callback verification</li>
 587     </ul>
 588
 589     <p>However all of these do have some degree of false positive
 590     ratings.  You need to be aware of how much of your user base you
 591     may alienate by imposing too strict a set of controls, and balance
 592     that against the reduced amount of unwanted bulk mail.</p>
 593
 594     <h3><a href="#index"><a name="mmapol">Mailman specific ACL checks</a></a></h3>
 595
 596     <p>Lists should never receive bounce messages to the posting
 597     address unless the bounced message is either a forgery using the
 598     list address as the sender address, or the bouncing MTA is
 599     terminally broken.  In either of these cases we really are not
 600     interested in receiving the messages and can reject them at SMTP
 601     time with a clear conscience.  The ACL to do this (as part of the
 602     RCPT ACL) is:-</p>
 603
 604 <pre>
 605   # Reject bounce (null sender) messages to the list
 606   deny     message = "Recipient never sends mail so cannot cause bounces"
 607            senders = :
 608            domains = +mm_domains
 609            condition = ${if exists{MM_LISTCHK} {yes}{no}}
 610 </pre>
 611
 612     <p>Additionally other mailman addresses do not generate mail (as
 613     the envelope sender, although they may be mentioned in the header
 614     addresses.  The ACL is split into 2 so that it can be written
 615     without the local_part condition wrapping.</p>
 616
 617 <pre>
 618   # Reject bounce (null sender) messages to the list
 619   deny     message = "Recipient never sends mail so cannot cause bounces"
 620            senders = :
 621            domains = +mm_domains
 622            local_parts = \N^.*-(admin|join|leave|owner|request)$\N
 623   deny     message = "Recipient never sends mail so cannot cause bounces"
 624            senders = :
 625            domains = +mm_domains
 626            local_parts = \N^.*-(subscribe|unsubscribe)$\N
 627 </pre>
 628
 629     <h3><a href="#index"><a name="smtune">SMTP callbacks</a></a></h3>
 630
 631     <p>Exim's SMTP callback feature is an even more powerful way to
 632     detect bogus sender addresses than normal sender verification.
 633     They are specially useful for checking envelope sender addresses
 634     at RCPT time within SMTP, and have been to date the most effective
 635     single anti-SPAM measure (however it should be noted that CBV is
 636     hated vehemently by some mail admins, and does increase both
 637     latency and traffic, as well as theoretically being a means to set
 638     up a DDOS situation).</p>
 639
 640     <p>It is recommended that SMTP Sender CBV is not carried out on
 641     messages to the Mailman bounce handlers, so that broken remote
 642     MTAs (specifcally ones which send bounces with something other
 643     than a null sender address) do not get excluded from being taken
 644     off mailing lists</p>
 645
 646 <pre>
 647   # Do callback verification unless Mailman incoming bounce
 648   deny     !local_parts = *-bounces : *-bounces+*
 649            !verify = sender/callout=30s,defer_ok
 650
 651 </pre>
 652
 653     <p>Callback verification can also be done on header addresses, but
 654     care should be taken not to reject messages unnecessarily,
 655     especially when the message is going to Mailman's bounce
 656     processor</p>
 657
 658     <h2><a href="#index"><a name="lisver">List verification</a></a></h2>
 659
 660     <p>This is how a set of address tests for the Exim lists look on a
 661     working system.  The list in question is
 662     <tt>testlist@list.example.com</tt>, and these commands were
 663     run on the <tt>list.example.com</tt> mail server (<tt>"% "</tt>
 664     indicates the Unix shell prompt):</p>
 665
 666 <pre>
 667   % exim -bt testlist@list.example.com
 668   testlist@list.example.com
 669     router = mailman_router, transport = mailman_transport
 670
 671   % exim -bt testlist-request@list.example.com
 672   testlist-request@list.example.com
 673     router = mailman_router, transport = mailman_transport
 674
 675   % exim -bt testlist-bounces@list.example.com
 676   testlist-bounces@list.example.com
 677     router = mailman_router, transport = mailman_transport
 678
 679   % exim -bt testlist-bounces+luser=example.com@list.example.com
 680   testlist-bounces+luser=example.com@list.example.com
 681     router = mailman_router, transport = mailman_transport
 682 </pre>
 683
 684     <p>If your <tt>"exim -bt"</tt> output looks something like this,
 685     that's a start: at least it means Exim will pass the right
 686     messages to the right Mailman commands.  It by no means guarantees
 687     that your Exim/Mailman installation is functioning perfectly,
 688     though!</p>
 689
 690     <h2><a href="#index"><a name="problem">Possible Problems</a></a></h2>
 691
 692     <ul>
 693
 694       <li> Mailman will send as many <tt>MAIL FROM/RCPT TO</tt> as it
 695       needs. It may result in more than 10 or 100 messages sent in one
 696       connection, which will exceed the default value of Exim's
 697       smtp_accept_queue_per_connection This is bad because it will
 698       cause Exim to switch into queue mode and severely delay delivery
 699       of your list messages.  The way to fix this is to set mailman's
 700       <tt>SMTP_MAX_SESSIONS_PER_CONNECTION</tt> (in
 701       <tt>~mailman/Mailman/mm_cfg.py</tt>) to a smaller value than
 702       Exim's <tt>smtp_accept_queue_per_connection</tt></li>
 703
 704       <li>Mailman should ignore Exim delay warning messages, even
 705       though Exim should never send this to list messages.  Mailman
 706       2.1's general bounce detection and VERP support should greatly
 707       improve the bounce detector's hit rates.</li>
 708
 709       <li>List existence is determined by the existence of a
 710       <tt>config.pck</tt> file for a list.  If you delete lists by
 711       foul means, be aware of this.</li>
 712
 713       <li>If you are getting Exim or Mailman complaining about user
 714       ids when you send mail to a list, check that the
 715       <tt>MM_UID</tt> and <tt>MM_GID</tt> match those of
 716       Mailman itself (i.e. what were used in the configure script).
 717       Also make sure you do not have aliases in the main alias file
 718       for the list.</li>
 719
 720     </ul>
 721
 722     <h2><a href="#index"><a name="dochis">Document History</a></a></h2>
 723
 724     <ul>
 725       <li>Originally written by Nigel Metheringham.</li>
 726       <li>Updated by Marc Merlin for Mailman 2.1, Exim 4</li>
 727       <li>Overhauled/reformatted/clarified/simplified by Greg
 728  Ward.</li>
 729       <li>Rehashed again by Nigel Metheringham</li>
 730     </ul>
 731
 732     <h2><a href="#index"><a name="doccha">Document Changes</a></a></h2>
 733
 734     <ul>
 735       <li><b>14 June 2004</b> Originally written by Nigel Metheringham.</li>
 736       <li><b>28 June 2004</b> Fixed a problem with the Exim VERP
 737  transport which caused locally aliased recipient addresses to
 738  have incorrect VERP extensions added.  Followed posting to
 739  exim-users list by Arkadiusz Miskiewicz -- <i>Nigel Metheringham</i>.</li>
 740       <li><b>19 November 2004</b> Fixed previously unnoticed brainstorm
 741  where <tt>reject</tt> had been used as a ACL verb rather than
 742  <tt>deny</tt>.  Fixes to the VERP router/transport pair.
 743  -- <i>Nigel Metheringham</i></li>
 744     </ul>
 745
 746
 747     <h2><a href="#index"><a name="docfin">Final Word</a></a></h2>
 748
 749     <p>Like many documents of this type, it has evolved and taken on
 750     contributions by many many helpful folks, mainly those on the
 751     Mailman and exim mailing lists.  To all of you, who have made
 752     contributions yet had their names shamefully lost by me, <i>Thank
 753     You</i>.</p>
 754
 755     <hr>
 756     <h4>$Cambridge$</h4>
 757   </body>
 758 </html>