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
+ archiving functions. Details can be found at http://www.list.org/. This + documentation describes the configuration of Exim (version 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.
+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.
-The Exim configuration is built so that a list created within - Mailman automatically appears to Exim without the need for - defining any additional aliases.
+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.
-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:
+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 ++ +
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)
-[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.
+The Exim configuration is built so that a list created within + Mailman automatically appears to Exim without the need for + defining any additional aliases (however Mailman may helpfully + show or email you a list of required aliases when you create a + list - you can just ignore those - if you have set the + MTA parameter it will stop doing this).
+The drawback of this configuration is that it will work poorly + on systems supporting lists in several different mail domains. + While Mailman handles virtual domains, it does not yet support + having two distinct lists with the same name in different virtual + domains, using the same Mailman installation. This will + eventually change. (But see below for a variation on this scheme + that should accommodate virtual domains better.)
-The configuration file excerpts below are for use in an already + functional Exim configuration. You also need to have an alias for + mailman within the mm_domains, this picks up + mail sent to the site list (or basically just sent in error), and + should forward to the Mailman Administrator. It appears that a + couple of Mailman messages mention the mailman-admin + address (this appears to be an error in Mailman or maybe a + packaging error), so I would suggest that mailman-admin + is aliased also to the Mailman Administrator.
+ +[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
+ # 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
- 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?)
+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
- -
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.
+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,386 @@
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:
+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 WIKI.
+ +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 or{{eq{$sender_host_address}{127.0.0.1}} \
+ {eq{$sender_host_address}{::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; \
+ 64.94.110.11; \
+ 127.0.0.0/8; \
+ ::1/128;fe80::/10;fe \
+ c0::/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: ${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
+ deny 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 + deny message = "Recipient never sends mail so cannot cause bounces" + senders = : + domains = +mm_domains + local_parts = \N^.*-(admin|join|leave|owner|request)$\N + deny 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 + deny !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 testlist@list.example.com
+ testlist@list.example.com
+ router = mailman_router, transport = mailman_transport
- % exim -bt quixote-users-request
- quixote-users-request@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
- quixote-users-bounces@mems-exchange.org
+ % exim -bt testlist-bounces@list.example.com
+ testlist-bounces@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+luser=example.com@list.example.com
+ testlist-bounces+luser=example.com@list.example.com
router = mailman_router, transport = mailman_transport
@@ -391,14 +686,72 @@
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.