From c22e79070947faaabf3fd6cfb01acfb00c4c47db Mon Sep 17 00:00:00 2001
From: nigel Mailman is a list manager with web front end and built in
- archiving functions. Details can be found at http://www.list.org/ Mailman is a Mailing List
+ Manager (MLM). There are 2 sets of documents on integration of
+ Mailman with exim:- There is no Mailman configuration needed other than the
- standard options detailed in the Mailman install documentation.
- The exim configuration is transparent to Mailman. The uid/gid
- settings for Mailman must match those in the config fragments
- given below. The exim configuration is built so that a list created within
- Mailman automagically appears to exim without the need for
- additional alias files etc to be changed. The drawback of this configuration is that it will work poorly
- on systems supporting lists in several different mail domains -
- for that matter Mailman itself has poor support for this right
- now. This may change in the future The configuration file segments included are to be built on top
- of an already functional exim configuration, which accepts mail
- for the domain which the list resides in (ie that domain is
- already in local_domains - should this domain be separate
- from the others handled by this exim, then add the list domain to
- local_domains, add a domains=my.list.domain
- option to each of the directors and you may wish to exclude that
- domain from the other directors. Your exim configuration also needs a working alias
- configuration, with entries (within the list domain) for
- mailman, mailman-request and
- mailman-admin (plus any other global contact addresses
- for the list master). These addresses point to a (or some - not
- necessarily the same for all of these aliases) human rather than
- being piped into Mailman. You do not need to put per-list
- entries into the system alias file, and doing so will most likely
- break things since the user id used for delivery is likely to be
- incorrect or not set (which causes an exim delivery time config
- error). There are 3 config file sections below which need pasting into
- the appropriate parts of the main exim config file. The first one
- may also need tailoring to your Mailman configuration Exim should be configured to allow reasonable volume - ie no
-setting max_recipients down to a silly value, and with normal
-degrees of security - ie allowing relaying from 127.0.0.1
-(thats vital), but pretty much nothing else. Parallel deliveries and
-other tweaks can also be used. Delay warning messages should be
-switched off or configured to only happen for non-list mail - unless
-you like receiving tons of mail when a host is down. One solution passed to me for handling virtual domains was -
- Since I use Mailman in a virtual domain configuration with a
- separate installation for each virtual domain, I did a slight
- modification like this: This is a set of configuration directives I used on the list
- boxes I admin. Some of these are necessary, others are cosmetic,
- a few are probably superfluous - they work for me! This is how a set of address tests for the exim lists look on a
-working system. (command lines start with ">") Mailman is a list manager with web front end and built in
+ archiving functions. Details can be found at http://www.list.org/ There is no Mailman configuration needed other than the
+ standard options detailed in the Mailman install documentation.
+ The exim configuration is transparent to Mailman. The uid/gid
+ settings for Mailman must match those in the config fragments
+ given below. The exim configuration is built so that a list created within
+ Mailman automagically appears to exim without the need for
+ additional alias files etc to be changed. The drawback of this configuration is that it will work poorly
+ on systems supporting lists in several different mail domains -
+ for that matter Mailman itself has poor support for this right
+ now. This may change in the future The configuration file segments included are to be built on top
+ of an already functional exim configuration, which accepts mail
+ for the domain which the list resides in (ie that domain is
+ already in local_domains - should this domain be separate
+ from the others handled by this exim, then add the list domain to
+ local_domains, add a domains=my.list.domain
+ option to each of the directors and you may wish to exclude that
+ domain from the other directors. Your exim configuration also needs a working alias
+ configuration, with entries (within the list domain) for
+ mailman, mailman-request and
+ mailman-admin (plus any other global contact addresses
+ for the list master). These addresses point to a (or some - not
+ necessarily the same for all of these aliases) human rather than
+ being piped into Mailman. You do not need to put per-list
+ entries into the system alias file, and doing so will most likely
+ break things since the user id used for delivery is likely to be
+ incorrect or not set (which causes an exim delivery time config
+ error). There are 3 config file sections below which need pasting into
+ the appropriate parts of the main exim config file. The first one
+ may also need tailoring to your Mailman configuration Exim should be configured to allow reasonable volume - ie no
+setting max_recipients down to a silly value, and with normal
+degrees of security - ie allowing relaying from 127.0.0.1
+(thats vital), but pretty much nothing else. Parallel deliveries and
+other tweaks can also be used. Delay warning messages should be
+switched off or configured to only happen for non-list mail - unless
+you like receiving tons of mail when a host is down. One solution passed to me for handling virtual domains was -
+ Since I use Mailman in a virtual domain configuration with a
+ separate installation for each virtual domain, I did a slight
+ modification like this: This is a set of configuration directives I used on the list
+ boxes I admin. Some of these are necessary, others are cosmetic,
+ a few are probably superfluous - they work for me! This is how a set of address tests for the exim lists look on a
+working system. (command lines start with ">") Mailman is a list manager with web front end and built in
- archiving functions. Details can be found at
- http://www.list.org/. This documentation describes the
- configuration of Exim (version 3 or 4) to work with Mailman
- version 2.1HOWTO - Using exim and Mailman together
+
+ Exim and Mailman HOWTO
- Mailman configuration
+
-
Exim configuration
+ Main config file section
-
-## Top section of config file - macro definitions
-## Tailor these to fit your installation
-## pretty much everything else should just fit...
-##
-# home dir for Mailman
-MAILMAN_HOME=/home/mailman
-# wrapper script for mailman
-MAILMAN_WRAP=MAILMAN_HOME/mail/wrapper
-# user and group for Mailman
-MAILMAN_UID=exim
-MAILMAN_GID=exim
-
- Transports config file section
-
-## Transports section
-##
-## Three transports for list mail, request mail and admin mail
-## respectively
-## Mailman is installed in MAILMAN_HOME
-## Mailman is configured to be invoked as user exim
-list_transport:
- driver = pipe
- command = MAILMAN_WRAP post ${lc:$local_part}
- current_directory = MAILMAN_HOME
- home_directory = MAILMAN_HOME
- user = MAILMAN_UID
- group = MAILMAN_GID
-
-list_request_transport:
- driver = pipe
- command = MAILMAN_WRAP mailcmd ${lc:$local_part}
- current_directory = MAILMAN_HOME
- home_directory = MAILMAN_HOME
- user = MAILMAN_UID
- group = MAILMAN_GID
-
-list_admin_transport:
- driver = pipe
- command = MAILMAN_WRAP mailowner ${lc:$local_part}
- current_directory = MAILMAN_HOME
- home_directory = MAILMAN_HOME
- user = MAILMAN_UID
- group = MAILMAN_GID
-
-### end of transports section fragment
-
- Directors config file section
-
-## Directors section [this deals with local addresses]
-##
-## First 2 directors rewrite list-owner or owner-list to list-admin
-## This is only done if the list exists.
-## List existence checks are done by seeing if the file
-## MAILMAN_HOME/lists/
-
-/config.db
-## exists.
-
-list_owner_director:
- driver = smartuser
- require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
- suffix = "-owner"
- new_address = "${lc:$local_part}-admin@${domain}"
-
-owner_list_director:
- driver = smartuser
- require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
- prefix = "owner-"
- new_address = "${lc:$local_part}-admin@${domain}"
-
-##
-## Next 3 directors direct admin, request and list mail to the appropriate
-## transport. List existence is checked as above.
-
-list_admin_director:
- driver = smartuser
- suffix = -admin
- require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
- transport = list_admin_transport
-
-list_request_director:
- driver = smartuser
- suffix = -request
- require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
- transport = list_request_transport
-
-list_director:
- driver = smartuser
- require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
- transport = list_transport
-
-## End of directors fragment
-## End of config files bits
-
Problems
-
-
-
-
- Other Tweaks
-
-
-## transport configurations
-
-command = "/virtual/${domain}/mailman/mail/wrapper post ${lc:$local_part}"
-current_directory = /virtual/${domain}/mailman
-home_directory = /virtual/${domain}/mailman
-
-## and in the director part:
-
-require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.db
-
-
-
- Exim List Efficiency Tweaks
-
-
-# definition of injecting IP addresses
-LOCAL_NETS=127.0.0.1/32
-#
-# Extra logging data - not necessary but makes the logs more
-# useful, but bigger
-# lookup all hostnames - puts hostnames into log as well as ips
-host_lookup = 0.0.0.0/0
-# tweak logging
-log_all_parents
-log_file_path = /var/log/exim/%s.log
-log_received_recipients
-log_refused_recipients
-log_received_sender
-log_smtp_confirmation
-#
-# RBL settings - these are more severe than I use
-rbl_domains = rbl.maps.vix.com/reject:relays.mail-abuse.org/reject:dul.maps.vix.com/reject:relays.orbs.org=127.0.0.2,127.0.0.3/reject
-rbl_hosts = !LOCAL_NETS:0.0.0.0/0
-rbl_log_rcpt_count
-recipients_reject_except=postmaster@*:*-admin@*
-#
-# relay control - from our local network only
-host_accept_relay = LOCAL_NETS
-#
-# delay warnings - second line is now default, but earlier versions of
-# exim need it setting
-delay_warning = 26h
-##delay_warning_condition = "${if match{$h_precedence:}{(?i)bulk|list|junk}{no}{yes}}"
-#
-# Verify receipient addresses on everything except local injects
-# DO NOT verify addresses from Mailman - this would slow down
-# the acceptance of messages dramatically
-receiver_verify_hosts = !127.0.0.1/8:0.0.0.0/0
-sender_verify
-#
-# performance tweaks - 1st is good for linux, maybe less so for others
-split_spool_directory
-remote_max_parallel = 15
-
-
-List verification
-
-
-> /usr/sbin/exim -v -bt exim-users
-exim-users@www.exim.org
- deliver to exim-users in domain www.exim.org
- director = list_director, transport = list_transport
-
-> /usr/sbin/exim -bt exim-users-request
-exim-users-request@www.exim.org
- deliver to exim-users in domain www.exim.org
- director = list_request_director, transport = list_request_transport
-
-> /usr/sbin/exim -bt exim-users-admin
-exim-users-admin@www.exim.org
- deliver to exim-users in domain www.exim.org
- director = list_admin_director, transport = list_admin_transport
+
- Nigel Metheringham
-
- $Id: mailman.html,v 1.2 2000/05/30 19:59:57 nigel Exp $
+ $Id$
+
+
+Last modified: Wed Jun 9 12:36:34 BST 2004
+
diff --git a/howto/mailman20.html b/howto/mailman20.html
new file mode 100644
index 0000000..0fa8f2d
--- /dev/null
+++ b/howto/mailman20.html
@@ -0,0 +1,270 @@
+
+
+
+ HOWTO - Using exim and Mailman together
+
+ Mailman configuration
+
+ Exim configuration
+
+ Main config file section
+
+## Top section of config file - macro definitions
+## Tailor these to fit your installation
+## pretty much everything else should just fit...
+##
+# home dir for Mailman
+MAILMAN_HOME=/home/mailman
+# wrapper script for mailman
+MAILMAN_WRAP=MAILMAN_HOME/mail/wrapper
+# user and group for Mailman
+MAILMAN_UID=exim
+MAILMAN_GID=exim
+
+ Transports config file section
+
+## Transports section
+##
+## Three transports for list mail, request mail and admin mail
+## respectively
+## Mailman is installed in MAILMAN_HOME
+## Mailman is configured to be invoked as user exim
+list_transport:
+ driver = pipe
+ command = MAILMAN_WRAP post ${lc:$local_part}
+ current_directory = MAILMAN_HOME
+ home_directory = MAILMAN_HOME
+ user = MAILMAN_UID
+ group = MAILMAN_GID
+
+list_request_transport:
+ driver = pipe
+ command = MAILMAN_WRAP mailcmd ${lc:$local_part}
+ current_directory = MAILMAN_HOME
+ home_directory = MAILMAN_HOME
+ user = MAILMAN_UID
+ group = MAILMAN_GID
+
+list_admin_transport:
+ driver = pipe
+ command = MAILMAN_WRAP mailowner ${lc:$local_part}
+ current_directory = MAILMAN_HOME
+ home_directory = MAILMAN_HOME
+ user = MAILMAN_UID
+ group = MAILMAN_GID
+
+### end of transports section fragment
+
+ Directors config file section
+
+## Directors section [this deals with local addresses]
+##
+## First 2 directors rewrite list-owner or owner-list to list-admin
+## This is only done if the list exists.
+## List existence checks are done by seeing if the file
+## MAILMAN_HOME/lists/
+
+/config.db
+## exists.
+
+list_owner_director:
+ driver = smartuser
+ require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
+ suffix = "-owner"
+ new_address = "${lc:$local_part}-admin@${domain}"
+
+owner_list_director:
+ driver = smartuser
+ require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
+ prefix = "owner-"
+ new_address = "${lc:$local_part}-admin@${domain}"
+
+##
+## Next 3 directors direct admin, request and list mail to the appropriate
+## transport. List existence is checked as above.
+
+list_admin_director:
+ driver = smartuser
+ suffix = -admin
+ require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
+ transport = list_admin_transport
+
+list_request_director:
+ driver = smartuser
+ suffix = -request
+ require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
+ transport = list_request_transport
+
+list_director:
+ driver = smartuser
+ require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db
+ transport = list_transport
+
+## End of directors fragment
+## End of config files bits
+
Problems
+
+
+
+
+ Other Tweaks
+
+
+## transport configurations
+
+command = "/virtual/${domain}/mailman/mail/wrapper post ${lc:$local_part}"
+current_directory = /virtual/${domain}/mailman
+home_directory = /virtual/${domain}/mailman
+
+## and in the director part:
+
+require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.db
+
+
+
+ Exim List Efficiency Tweaks
+
+
+# definition of injecting IP addresses
+LOCAL_NETS=127.0.0.1/32
+#
+# Extra logging data - not necessary but makes the logs more
+# useful, but bigger
+# lookup all hostnames - puts hostnames into log as well as ips
+host_lookup = 0.0.0.0/0
+# tweak logging
+log_all_parents
+log_file_path = /var/log/exim/%s.log
+log_received_recipients
+log_refused_recipients
+log_received_sender
+log_smtp_confirmation
+#
+# RBL settings - these are more severe than I use
+rbl_domains = rbl.maps.vix.com/reject:relays.mail-abuse.org/reject:dul.maps.vix.com/reject:relays.orbs.org=127.0.0.2,127.0.0.3/reject
+rbl_hosts = !LOCAL_NETS:0.0.0.0/0
+rbl_log_rcpt_count
+recipients_reject_except=postmaster@*:*-admin@*
+#
+# relay control - from our local network only
+host_accept_relay = LOCAL_NETS
+#
+# delay warnings - second line is now default, but earlier versions of
+# exim need it setting
+delay_warning = 26h
+##delay_warning_condition = "${if match{$h_precedence:}{(?i)bulk|list|junk}{no}{yes}}"
+#
+# Verify receipient addresses on everything except local injects
+# DO NOT verify addresses from Mailman - this would slow down
+# the acceptance of messages dramatically
+receiver_verify_hosts = !127.0.0.1/8:0.0.0.0/0
+sender_verify
+#
+# performance tweaks - 1st is good for linux, maybe less so for others
+split_spool_directory
+remote_max_parallel = 15
+
+
+List verification
+
+
+> /usr/sbin/exim -v -bt exim-users
+exim-users@www.exim.org
+ deliver to exim-users in domain www.exim.org
+ director = list_director, transport = list_transport
+
+> /usr/sbin/exim -bt exim-users-request
+exim-users-request@www.exim.org
+ deliver to exim-users in domain www.exim.org
+ director = list_request_director, transport = list_request_transport
+
+> /usr/sbin/exim -bt exim-users-admin
+exim-users-admin@www.exim.org
+ deliver to exim-users in domain www.exim.org
+ director = list_admin_director, transport = list_admin_transport
+
+
+ Nigel Metheringham
+
+ $Id: mailman.html,v 1.3 2002/06/14 10:42:18 nigel Exp $
+
+
diff --git a/howto/mailman21.html b/howto/mailman21.html
index 1e5ce6a..7d4d6e6 100644
--- a/howto/mailman21.html
+++ b/howto/mailman21.html
@@ -1,34 +1,128 @@
- HOWTO - Using exim and Mailman 2.1 together
+
+ HOWTO - Using Exim 4 and Mailman 2.1 together
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
+ +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.
+ +Tuning and setting appropriate mailing list protection policies + is also covered in passing.
+ +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.
+ + +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):-
+ ++ # The host part of the URL used for your mailman install + DEFAULT_URL_HOST = 'www.example.com' + # + # The email domain of your lists + DEFAULT_EMAIL_HOST = 'list.example.com' + # + # Let Mailman know that the MTA needs no aliases setting + MTA = None ++
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.
+After making a change to the Mailman configuration file you + need to restart the Mailman queue runners.
-+ ~mailman/bin/mailmanctl restart +-
There is no Mailman configuration needed other than the - standard options detailed in the Mailman install documentation. - The Exim configuration is transparent to Mailman. The user/group - settings for Mailman must match those in the config fragments - given below.
+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)
-The Exim configuration is built so that a list created within Mailman automatically appears to Exim without the need for - defining any additional aliases.
+ 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).The drawback of this configuration is that it will work poorly on systems supporting lists in several different mail domains. @@ -36,189 +130,141 @@ 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 accomodate virtual domains better.)
+ that should accommodate virtual domains better.)The configuration file excerpts below are for use in an already - functional Exim configuration, which accepts mail for the domain - in which the list resides. If this domain is separate from the - others handled by your Exim configuration, then you'll need to:
- -[Note: the instructions in this document should work with - either Exim 3 or Exim 4. In Exim 3, you must have a - 'local_domains' configuration setting; in Exim 4, you - most likely have a 'local_domains' domainlist. If you - don't, you probably know what you're doing and can adjust - accordingly. Similarly, in Exim 4 the concept of "directors" has - disappeared -- there are only routers now. So if you're using - Exim 4, whenever this document says "director", read - "router".]
- -Whether you are using Exim 3 or Exim 4, 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. With Exim 3, you'll - need to add a new director; with Exim 4, a new router plays - the same role.
- -Finally, the configuration supplied here should allow - co-habiting Mailman 2.0 and 2.1 installations, with the proviso - that you'll probably want to use "mm21" in place of - "mailman" -- e.g., MM21_HOME, - mm21_transport, etc.
- - -[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]
+ +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.
+ + +First, you need to add some macros to the top of your Exim - config file. These just make the directors (routers) and - transport below a bit cleaner. Obviously, you'll need to edit - these based on how you configured and installed Mailman.
+ 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.# Home dir for your Mailman installation -- aka Mailman's prefix # directory. - MAILMAN_HOME=/usr/local/mailman - MAILMAN_WRAP=MAILMAN_HOME/mail/mailman - + # By default this is set to "/usr/local/mailman" + # On a Red Hat/Fedora system using the RPM use "/var/mailman" + # On Debian using the deb package use "/var/lib/mailman" + # This is normally the same as ~mailman + MM_HOME=/var/mailman + # # User and group for Mailman, should match your --with-mail-gid # switch to Mailman's configure script. - MAILMAN_UID=mailman - MAILMAN_GID=mailman -- -
Add this to the transports section of your Exim config file, - i.e. somewhere between the first and second "end" line:
- -- mailman_transport: - driver = pipe - command = MAILMAN_WRAP \ - '${if def:local_part_suffix \ - {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \ - {post}}' \ - $local_part - current_directory = MAILMAN_HOME - home_directory = MAILMAN_HOME - user = MAILMAN_UID - group = MAILMAN_GID + # Value is normally "mailman" + MM_UID=mailman + MM_GID=mailman + # + # Domains that your lists are in - colon separated list + # you may wish to add these into local_domains as well + domainlist mm_domains=list.example.com + # + # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + # + # These values are derived from the ones above and should not need + # editing unless you have munged your mailman installation + # + # The path of the Mailman mail wrapper script + 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-
(XXX this is untested by me under Exim 3! Can someone using - Exim 3 please let me know if it works?)
- - -If you're using Exim 3, you'll need to add the following - director to your config file (directors go between the second and - third "end" lines). Also, don't forget that order matters -- - eg. you can make Mailman lists take precedence over system aliases - by putting this directors in front of your aliasfile director, or - vice-versa.
+ +- # Handle all addresses related to a list 'foo': the posting address. - # Automatically detects list existence by looking - # for lists/$local_part/config.pck under MAILMAN_HOME. - mailman_director: - driver = smartuser - require_files = MAILMAN_HOME/lists/$local_part/config.pck - suffix_optional - suffix = -bounces : -bounces+* : \ - -confirm+* : -join : -leave : \ - -owner : -request : -admin - transport = mailman_transport -+
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
-
In Exim 4, there are no such things as directors -- you instead - need to add a router. Also, the canonical order of the - configuration file was changed so routers come before transports, - so the routers for Exim 4 come first here. Put these two routers - somewhere after the "begin routers" line of your config - file, and remember that order matters.
+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).
mailman_router: driver = accept - require_files = MAILMAN_HOME/lists/$local_part/config.pck + domains = +mm_domains + require_files = MM_LISTCHK local_part_suffix_optional - local_part_suffix = -bounces : -bounces+* : \ - -confirm+* : -join : -leave : \ - -owner : -request : -admin + local_part_suffix = -admin : \ + -bounces : -bounces+* : \ + -confirm : -confirm+* : \ + -join : -leave : \ + -owner : -request : \ + -subscribe : -unsubscribe transport = mailman_transport-
The transport for Exim 4 is the same as for Exim 3; just copy - the transport given above to somewhere under the "begin - transports" line of your Exim config file.
- + +Exim should be configured to allow reasonable volume -- - e.g. don't set max_recipients down to a silly value -- and with - normal degrees of security -- specifically, be sure to allow - relaying from 127.0.0.1, but pretty much nothing else. Parallel - deliveries and other tweaks can also be used if you like; - experiment with your setup to see what works. Delay warning - messages should be switched off or configured to only happen for - non-list mail, unless you like receiving tons of mail when some - random host is down.
- - -The transport for Exim 4 can be placed anywhere where under the + begin transports line of your Exim config file.
-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.
-The sg phrase strips the VERP information (if any) + from the suffix,
-+ mailman_transport: + driver = pipe + command = MM_WRAP \ + '${if def:local_part_suffix \ + {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \ + {post}}' \ + $local_part + current_directory = MM_HOME + home_directory = MM_HOME + user = MM_UID + group = MM_GID +-
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 +
-Exim's receiver verification feature is very useful -- it lets +
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 @@ -232,13 +278,10 @@ 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. Therefore, - you should disable recipient verification for Mailman traffic.
- -Under Exim 3, put this in your main configuration section:
-- receiver_verify_hosts = !127.0.0.1 -+ 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.
Under Exim 4, this is probably already taken care of for you by the default recipient verification ACL statement (in the "RCPT TO" @@ -254,134 +297,399 @@
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.)
+ 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. - -Exim's SMTP callback feature is an even more powerful way to - detect bogus sender addresses than normal sender verification. - Unfortunately, lots of servers send bounce messages with a bogus - address in the header, and there are plenty that sound bounces - with bogus envelope senders (even though they're supposed to just - use an empty envelope sender for bounces).
- -In order to ensure that Mailman can disable/remove bouncing - addresses, you generally want to receive bounces for Mailman - lists, even if those bounces are themselves not bouncable. Thus, - you might want to disable SMTP callback on bounce messages.
- -If you do header and envelope callbacks, you can disable them - for bounces to mailman lists (it is quite common for internal - hosts to bounce with a non reachable internal address). The idea - is that you typically don't want non bounceable Email, but you'd - better accept bounces to mailman lists so that you can unsubscribe - the people who are bouncing.
- -With Exim 4, you can accomplish this using something like the - following in your "RCPT TO" ACL:
+Alternatively you can add an early get-out in the "RCPT TO" + ACL), which trusts all traffic coming from the loopback IP + address:
- # Accept bounces to lists even if callbacks or other checks would fail - warn message = X-WhitelistedRCPT-nohdrfromcallback: Yes - condition = \ - ${if and {{match{$local_part}{(.*)-bounces\+.*}} \ - {exists {MAILMAN_HOME/lists/$1/config.pck}}} \ - {yes}{no}} - {yes}{no}} - - accept condition = \ - ${if and {{match{$local_part}{(.*)-bounces\+.*}} \ - {exists {MAILMAN_HOME/lists/$1/config.pck}}} \ - {yes}{no}} - {yes}{no}} - - # Now, check sender address with SMTP callback. - deny !verify = sender/callout=90s/check_postmaster + accept hosts = 127.0.0.1-
If you also do SMTP callbacks on header addresses, you'll want - something like this in your "DATA" ACL:
+ +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)
+ +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.
+ +For example, add the following lines to + ~mailman/Mailman/mm_cfg.py:
- deny !condition = $header_X-WhitelistedRCPT-nohdrfromcallback: - !verify = header_sender/callout=90s/check_postmaster + # Max recipients for each message + SMTP_MAX_RCPTS = 15 + # Max messages sent in each SMTP connection + SMTP_MAX_SESSIONS_PER_CONNECTION = 30-
[XXX all this stuff is completely untested by me! - -Greg]
- - -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.
+ + +VERP (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.
VERP will send one email, with a separate envelope sender - (return path), for each of your subscribers -- 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 + (return path), for each of your subscribers - this means that it + will generate more traffic since you cannot bundle up deliveries + together. An analysis + of the costs of VERP can be found in the Mailman FAQ + Wizard.
+ +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:
VERP_PASSWORD_REMINDERS = 1 VERP_PERSONALIZED_DELIVERIES = 1 - VERP_DELIVERY_INTERVAL = 1 VERP_CONFIRMATIONS = 1 + VERP_DELIVERY_INTERVAL = 1-
(The directors/routers above are smart enough to deal with VERP +
(The router and ACLs above are smart enough to deal with VERP bounces.)
+This configuration on its own will make the monthly password + reminders, confirmations and all list postings be sent out using + VERP
+ +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:-
+ ++ VERP_DELIVERY_INTERVAL = 20 ++ +
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.
+ + +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.
+ +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):-
+ ++ OWNERS_CAN_ENABLE_PERSONALIZATION = 1 ++ +
You will then find that in the list administration web + interface a new set of options has appeared in the Non-digest + options section.
+ + +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.
+ +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.
+ +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:-
+ ++ # Pick up on messages from our local mailman and route them via our + # special VERP-enabled transport + # + mailman_verp_router: + driver = dnslookup + # we only consider messages sent in through loopback + condition = ${if eq{$sender_host_address}{127.0.0.1}{yes}{no}} + # we do not do this for traffic going to the local machine + domains = !+local_domains:!+mm_domains + ignore_target_hosts = <; 0.0.0.0; \ + 127.0.0.0/8; \ + ::1/128; \ + fe80::/10; \ + ff00::/8 + # only the un-VERPed bounce addresses are handled + senders = "*-bounces@*" + transport = mailman_verp_smtp ++ +
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:-
+ ++ # Mailman VERP envelope sender address formatting. This seems not to use + # quoted-printable encoding of the address, but instead just replaces the + # '@' in the recipient address with '='. + # + mailman_verp_smtp: + driver = smtp + # put recipient address into return_path + return_path = \ + ${local_part:$return_path}+$local_part=$domain@${domain:$return_path} + # must restrict to one recipient at a time + max_rcpt = 1 + # Errors-To: may carry old return_path + headers_remove = Errors-To + headers_add = Errors-To: \ + ${local_part:$return_path}+$local_part=$domain@${domain:$return_path} ++ +
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:-
++ VERP_PASSWORD_REMINDERS = 1 + VERP_PERSONALIZED_DELIVERIES = 1 + VERP_CONFIRMATIONS = 1 + VERP_DELIVERY_INTERVAL = 0 ++ +
If you have set personalisation on any list, this will still be + handled, and VERPed, by Mailman.
-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.)
-In this case, the MAILMAN_HOME and - MAILMAN_WRAP macros are useless -- you can remove them. - Change your director (router) to something like this:
+In this case, you must change the MM_HOME macro to + something like this:-
- require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.pck + MM_HOME=/virtual/${lc::$domain}/mailman-
and change your transport like this:
+and modify the mm_domains domain list appropriately.
+ + +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.
+ +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.
+ + +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.
+ +The best way to do this is using the exiscan extension + along with a virus scanner such as clam-av and a spam + content scanner such as SpamAssassin. Configuring + these is beyond the scope of this document, however Tim Jackson + has a very good set of PDF + documentation on integrating these.
+ +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).
+ + +You may wish to apply various checks to incoming messages to + ensure that they are sane. These may include:-
+ +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.
+ + +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:-
- command = /virtual/${domain}/mailman/mail/mailman \ - ${if def:local_part_suffix \ - {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} - {post}} \ - $local_part - current_directory = /virtual/${domain}/mailman - home_directory = /virtual/${domain}/mailman + # Reject bounce (null sender) messages to the list + reject message = "Recipient never sends mail so cannot cause bounces" + senders = : + domains = +mm_domains + condition = ${if exists{MM_LISTCHK} {yes}{no}} ++ +
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.
+ ++ # Reject bounce (null sender) messages to the list + reject message = "Recipient never sends mail so cannot cause bounces" + senders = : + domains = +mm_domains + local_parts = \N^.*-(admin|join|leave|owner|request)$\N + reject message = "Recipient never sends mail so cannot cause bounces" + senders = : + domains = +mm_domains + local_parts = \N^.*-(subscribe|unsubscribe)$\N-
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).
+ +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
+ ++ # Do callback verification unless Mailman incoming bounce + reject !local_parts = *-bounces : *-bounces+* + !verify = sender/callout=30s,defer_ok + ++ +
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
+ + +This is how a set of address tests for the Exim lists look on a working system. The list in question is - quixote-users@mems-exchange.org, and these commands were - run on the mems-exchange.org mail server ("% " + testlist@list.example.com, and these commands were + run on the list.example.com mail server ("% " indicates the Unix shell prompt):
- % exim -bt quixote-users - quixote-users@mems-exchange.org - router = mailman_main_router, transport = mailman_transport - - % exim -bt quixote-users-request - quixote-users-request@mems-exchange.org + % exim -bt testlist@list.example.com + testlist@list.example.com router = mailman_router, transport = mailman_transport - - % exim -bt quixote-users-bounces - quixote-users-bounces@mems-exchange.org + + % exim -bt testlist-request@list.example.com + testlist-request@list.example.com router = mailman_router, transport = mailman_transport - - % exim -bt quixote-users-bounces+luser=example.com - quixote-users-bounces+luser=example.com@mems-exchange.org + + % exim -bt testlist-bounces@list.example.com + testlist-bounces@list.example.com + router = mailman_router, transport = mailman_transport + + % exim -bt testlist-bounces+luser=example.com@list.example.com + testlist-bounces+luser=example.com@list.example.com router = mailman_router, transport = mailman_transport@@ -391,14 +699,57 @@ that your Exim/Mailman installation is functioning perfectly, though! + +
Originally written by Nigel Metheringham. Updated by Marc - Merlin for Mailman 2.1, Exim 4. - Overhauled/reformatted/clarified/simplified by Greg Ward.
+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, Thank + You.