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.1
+ + + +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.
+ + +The Exim configuration is built so that a list created within + Mailman automatically appears to Exim without the need for + defining any additional aliases.
+ +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 accomodate 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.
+ + +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.
+ ++ # Home dir for your Mailman installation -- aka Mailman's prefix + # directory. + MAILMAN_HOME=/usr/local/mailman + MAILMAN_WRAP=MAILMAN_HOME/mail/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
+
+
+ (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 ++ +
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.
+ ++ mailman_router: + driver = accept + require_files = MAILMAN_HOME/lists/$local_part/config.pck + local_part_suffix_optional + local_part_suffix = -bounces : -bounces+* : \ + -confirm+* : -join : -leave : \ + -owner : -request : -admin + 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.
+ + +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.
+ +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. 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 ++ +
Under Exim 4, this is probably already taken care of for you by + the default recipient verification ACL statement (in the "RCPT TO" + ACL):
+ ++ accept domains = +local_domains + endpass + message = unknown user + verify = recipient ++ +
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.)
+ + +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 epmty 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:
+ +
+ # 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
+
+
+ If you also do SMTP callbacks on header addresses, you'll want + something like this in your "DATA" ACL:
+ ++ deny !condition = $header_X-WhitelistedRCPT-nohdrfromcallback: + !verify = header_sender/callout=90s/check_postmaster ++ +
[XXX all this stuff is completely untested by me! + -Greg]
+ + +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 + ~mailman/Mailman/mm_cfg.py:
+ ++ VERP_PASSWORD_REMINDERS = 1 + VERP_PERSONALIZED_DELIVERIES = 1 + VERP_DELIVERY_INTERVAL = 1 + VERP_CONFIRMATIONS = 1 ++ +
(The directors/routers above are smart enough to deal with VERP + bounces.)
+ + +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:
+ +
+ require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.pck
+
+
+ and change your transport like this:
+ +
+ 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
+
+
+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 ("% " + 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 + router = mailman_router, transport = mailman_transport + + % exim -bt quixote-users-bounces + quixote-users-bounces@mems-exchange.org + router = mailman_router, transport = mailman_transport + + % exim -bt quixote-users-bounces+luser=example.com + quixote-users-bounces+luser=example.com@mems-exchange.org + router = mailman_router, transport = mailman_transport ++ +
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!
+ + +Originally written by Nigel Metheringham. Updated by Marc + Merlin for Mailman 2.1, Exim 4. + Overhauled/reformatted/clarified/simplified by Greg Ward.
+ +