-
-
-
-
- |
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
This document was generated using the - LaTeX2HTML translator. -
- -- LaTeX2HTML is Copyright © - 1993, 1994, 1995, 1996, 1997, Nikos - Drakos, Computer Based Learning Unit, University of - Leeds, and Copyright © 1997, 1998, Ross - Moore, Mathematics Department, Macquarie University, - Sydney. -
- -The application of - LaTeX2HTML to the Python - documentation has been heavily tailored by Fred L. Drake, - Jr. Original navigation icons were contributed by Christopher - Petrilli. -
- - |
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Vivek Khera writes that some BSDs do nightly security scans for setuid file -changes. setgid directories also come up on the scan when they change. Also, -the setgid bit is not necessary on BSD systems because group ownership is -automatically inherited on files created in directories. On other Unixes, -this only happens when the directory has the setgid bit turned on. - -
-To install without turning on the setgid bit on directories, simply pass in -the DIRSETGID variable to make, after you've run -configure: - -
-
- % make DIRSETGID=: install -
-This disables the chmod g+s command on installed directories. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-The default is to install all of Mailman to -/usr/local/mailman2. You can change this base installation directory (referred to here -as $prefix) by specifying the directory with the ---prefix configure option. If you're upgrading from -a previous version of Mailman, you may want to use the --prefix -option unless you move your mailing lists. - -
-
nosuid option. This will break Mailman, which relies on setgid
-programs for its security. If this describes your environment, simply install
-Mailman in a location that allows setgid programs.
-
-Make sure the installation directory is set to group mailman (or
-whatever you're going to specify with --with-groupname) and has
-the setgid bit set3. You probably also want to guarantee that this
-directory is readable and executable by everyone. For example, these shell
-commands will accomplish this:
-
-
-
- % cd $prefix - % chgrp mailman . - % chmod a+rx,g+ws . -
-You are now ready to configure and install the Mailman software. - -
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Mailman has a large number of site-wide configuration options which you should -now review and change according to your needs. Some of the options control -how Mailman interacts with your environment, and other options select defaults -for newly created lists5. -There are system tuning parameters and integration options. - -
-The full set of site-wide defaults lives in the -$prefix/Mailman/Defaults.py file, however you should -never modify this file! Instead, change the mm_cfg.py file in -that same directory. You only need to add values to mm_cfg.py that are -different than the defaults in Defaults.py, and future Mailman upgrades -are guaranteed never to touch your mm_cfg.py file. - -
-The Defaults.py file is documented extensively, so the options are not -described here. The Defaults.py and mm_cfg.py are both -Python files so valid Python syntax must be -maintained or your Mailman installation will break. - -
-
-You should make any changes to mm_cfg.py using the account you -installed Mailman under in the 14 section. - -
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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_USER
- group = MAILMAN_GROUP
-- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
- -
-The GNU Mailman website is at http://www.list.org
- -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
- -
Barry Warsaw
-barry(at)python.org
-Release 2.1
-December 13, 2005
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-This section describes some of the things you need to do to connect Mailman's -email interface to your mail server. The instructions here are different for -each mail server; if your mail server is not described in the following -subsections, try to generalize from the existing documentation, and consider -contributing documentation updates to the Mailman developers. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
- -
Barry Warsaw
-barry(at)python.org
-Release 2.1
-December 13, 2005
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Congratulations! You've installed the Mailman software. To get everything -running you need to hook Mailman up to both your web server and your mail -system. - -
-If you plan on running your mail and web servers on different machines, -sharing Mailman installations via NFS, be sure that the clocks on those two -machines are synchronized closely. You might take a look at the file -Mailman/LockFile.py; the constant CLOCK_SLOP helps the locking -mechanism compensate for clock skew in this type of environment. - -
-This section describes some of the things you need to do to connect Mailman's -web interface to your web server. The instructions here are somewhat geared -toward the Apache web server, so you should consult your web server -documentation for details. - -
-You must configure your web server to enable CGI script permission in the -$prefix/cgi-bin to run CGI scripts. The line you should add -might look something like the following, with the real absolute directory -substituted for $prefix, of course: - -
-
- Exec /mailman/* $prefix/cgi-bin/* -
-or: - -
-
- ScriptAlias /mailman/ $prefix/cgi-bin/ -
-
mailman group you created above, otherwise private
-archives will be accessible to anyone.
--Copy the Mailman, Python, and GNU logos to a location accessible to your web -server. E.g. with Apache, you've usually got an icons directory that -you can drop the images into. For example: - -
-
- % cp $prefix/icons/*.{jpg,png} /path/to/apache/icons
--You then want to add a line to your $prefix/Mailman/mm_cfg.py -file which sets the base URL for the logos. For example: - -
-
- IMAGE_LOGOS = '/images/' -
-The default value for IMAGE_LOGOS is /icons/. Read the comment -in Defaults.py.in for details. - -
-Configure your web server to point to the Pipermail public mailing list -archives. For example, in Apache: - -
-
- Alias /pipermail/ $varprefix/archives/public/ -
-where $varprefix is usually $prefix unless you've used the ---with-var-prefix option to configure. Also be -sure to configure your web server to follow symbolic links in this directory, -otherwise public Pipermail archives won't be accessible. For Apache users, -consult the FollowSymLinks option. - -
-If you're going to be supporting internationalized public archives, you will -probably want to turn off any default charset directive for the Pipermail -directory, otherwise your multilingual archive pages won't show up correctly. -Here's an example for Apache, based on the standard installation directories: - -
-
- <Directory "/usr/local/mailman/archives/public/"> - AddDefaultCharset Off - </Directory> -
-Now restart your web server. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Mailman should work pretty much out of the box with a standard Postfix -installation. It has been tested with various Postfix versions up to and -including Postfix 2.1.5. - -
-In order to support Mailman's optional VERP delivery, you will want to disable
-luser_relay (the default) and you will want to set
-recipient_delimiter for extended address semantics. You should comment
-out any luser_relay value in your main.cf and just go with the
-defaults. Also, add this to your main.cf file:
-
-
-
- recipient_delimiter = + -
-Using "+" as the delimiter works well with the default values for -VERP_FORMAT and VERP_REGEXP in Defaults.py. - -
-When attempting to deliver a message to a non-existent local address, Postfix -may return a 450 error code. Since this is a transient error code, Mailman -will continue to attempt to deliver the message for -DELIVERY_RETRY_PERIOD - 5 days by default. You might want to set -Postfix up so that it returns permanent error codes for non-existent local -users by adding the following to your main.cf file: - -
-
- unknown_local_recipient_reject_code = 550 -
-Finally, if you are using Postfix-style virtual domains, read the section on -virtual domain support below. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-You can integrate Postfix and Mailman such that when new lists are created, or -lists are removed, Postfix's alias database will be automatically updated. -The following are the steps you need to take to make this work. - -
-In the description below, we assume that you've installed Mailman in the -default location, i.e. /usr/local/mailman. If that's not the case, -adjust the instructions according to your use of configure's ---prefix and --with-var-prefix options. - -
-
- -
-
- MTA = 'Postfix' -
-The MTA variable names a module in the Mailman/MTA directory - which contains the mail server-specific functions to be executed when a - list is created or removed. - -
-
-
-
- % cd /usr/local/mailman - % bin/genaliases -
-Make sure that the owner of the data/aliases and
- data/aliases.db file is mailman, that the group owner
- for those files is mailman, or whatever user and group you used
- in the configure command, and that both files are group writable:
-
-
-
- % su - % chown mailman:mailman data/aliases* - % chmod g+w data/aliases* -
-
-
- /usr/local/mailman/data/aliases -
-Note that there should be no trailing .db. Do not include this
- in your alias_database variable. This is because you do not want
- Postfix's newaliases command to modify Mailman's
- aliases.db file, but you do want Postfix to consult
- aliases.db when looking for local addresses.
-
-
-You probably want to use a hash: style database for this entry.
- Here's an example:
-
-
-
- alias_maps = hash:/etc/postfix/aliases, - hash:/usr/local/mailman/data/aliases -
-
mailman owner.
- Because the owner of the aliases.db file is mailman,
- Postfix will execute Mailman's wrapper program as uid and gid
- mailman.
-
--
-That's it! One caveat: when you add or remove a list, the aliases.db -file will updated, but it will not automatically run postfix reload. -This is because you need to be root to run this and suid-root scripts are not -secure. The only effect of this is that it will take about a minute for -Postfix to notice the change to the aliases.db file and update its -tables. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Fil fil@rezo.net has an alternative approach based on virtual maps and -regular expressions, as described at: - -
- -
-This is a good (and simpler) alternative if you don't mind exposing an
-additional hostname in the domain part of the addresses people will use to
-contact your list. I.e. if people should use mylist@lists.dom.ain
-instead of mylist@dom.ain.
-
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-
-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 and group settings for Mailman must match -those in the config fragments given below. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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 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: - -
- -
-
-
-
-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.
-
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-First, you need to add some macros to the top of your Exim config file. These -just make the director (router) 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_USER=mailman - MAILMAN_GROUP=mailman -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-GNU Mailman works on most POSIX-based systems such as Unix, MacOSX, or -GNU/Linux. It does not currently work on Windows. You must have a mail -server that you can send messages to, and a web server that supports the -CGI/1.1 API. Apache makes a fine choice for -web server, and mail servers such as -Postfix, -Exim, -Sendmail, and -qmail should -work just fine. - -
-To install Mailman from source, you will need an ANSI C compiler to build -Mailman's security wrappers. The -GNU C compiler gcc 2.8.1 or later is known -to work well. - -
-You must have the Python interpreter installed -somewhere on your system. Mailman 2.1 requires Python 2.1 or newer, although -Python 2.3 or newer is recommended. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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 - e.g. you can make Mailman lists take -precedence over system aliases by putting this director 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 -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-In Exim 4, there's no such thing as directors - you need to add a new router -instead. Also, the canonical order of the configuration file was changed so -routers come before transports, so the router for Exim 4 comes first here. -Put this router 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 -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-The transport for Exim 4 is the same as for Exim 3 (see 6.2; -just copy the transport given above to somewhere under the ``begin -transports'' line of your Exim config file. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
- -
MAIL FROM/RCPT TO as it needs.
- It may result in more than 10 or 100 messages sent in one connection,
- which will exceed the default value of Exim's
- smtp_accept_queue_per_connection value. This is bad because it
- will cause Exim to switch into queue mode and severely delay delivery of
- your list messages. The way to fix this is to set Mailman's
- SMTP_MAX_SESSIONS_PER_CONNECTION (in
- $prefix/Mailman/mm_cfg.py) to a smaller value than Exim's
- smtp_accept_queue_per_connection.
-
--
-
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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 addressed 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.) - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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 send 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 bounceable. Thus, you might want to disable SMTP callback on -bounce messages. - -
-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
-
-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 -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-VERP will send one email, with a separate envelope sender (return path), for -each of your subscribers - read the information in -$prefix/Mailman/Defaults.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 $prefix/Mailman/mm_cfg.py: - -
-
- VERP_PASSWORD_REMINDERS = Yes - VERP_PERSONALIZED_DELIVERIES = Yes - VERP_DELIVERY_INTERVAL = Yes - VERP_CONFIRMATIONS = Yes -
-(The director (router) above is smart enough to deal with VERP bounces.) - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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
-- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-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! - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Before installing Mailman, you need to prepare your system by adding certain -users and groups. You will need to have root privileges to perform the steps -in this section. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Originally written by Nigel Metheringham postmaster@exim.org. Updated -by Marc Merlin marc_soft@merlins.org for Mailman 2.1, Exim 4. -Overhauled/reformatted/clarified/simplified by Greg Ward -gward@python.net. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-
'Sendmail' when using the Sendmail mail server.
-Don't. The Sendmail.py module is misnamed - it's really a
-command line based message handoff scheme as opposed to the SMTP scheme used
-in SMTPDirect.py (the default). Sendmail.py has known security
-holes and is provided as a proof-of-concept only4. If you are having problems
-using SMTPDirect.py fix those instead of using Sendmail.py, or
-you may open your system up to security exploits.
-
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Many newer versions of Sendmail come with a restricted execution utility -called ``smrsh'', which limits the executables that Sendmail will allow to be -used as mail programs. You need to explicitly allow Mailman's wrapper program -to be used with smrsh or Mailman will not work. If mail is not getting -delivered to Mailman's wrapper program and you're getting an ``operating -system error'' in your mail syslog, this could be your problem. - -
-One good way of enabling this is: - -
- -
-
- % grep smrsh /etc/mail/sendmail.cf -
-
-
- % strings $path_to_smrsh | less -
-
-
- % cd /var/adm/sm.bin -
-
-
- % ln -s /usr/local/mailman/mail/mailman mailman -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-David Champion has contributed a recipe for more closely integrating Sendmail -and Mailman, such that Sendmail will automatically recognize and deliver to -new mailing lists as they are created, without having to manually edit alias -tables. - -
-In the contrib directory of Mailman's source distribution, you will -find four files: - -
- -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-One of the surest performance killers for Sendmail users is when Sendmail is
-configured to synchronously verify the recipient's host via DNS. If it does
-this for messages posted to it from Mailman, you will get horrible
-performance. Since Mailman usually connects via localhost
-(i.e. 127.0.0.1) to the SMTP port of Sendmail, you should be sure to configure
-Sendmail to not do DNS verification synchronously for localhost
-connections.
-
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-You will note in the alias generating script for 2.1 above, there is a line -for VERP that has been commented out. If you are interested in VERP there are -two options. The first option is to allow Mailman to do the VERP formatting. -To activate this, uncomment that line and add the following lines to your -mm_cfg.py file: - -
-
- VERP_FORMAT = '%(bounces)s-+%(mailbox)s=%(host)s' - VERP_REGEXP = r'^(?P<bounces>.*?)-\+(?P<mailbox>[^=]+)=(?P<host>[^@]+)@.*$' -
-The second option is a patch on SourceForge located at: - -
-http://sourceforge.net/tracker/?func=detail&atid=300103&aid=645513&group_id=103 -
-This patch currently needs more testing and might best be suitable for -developers or people well familiar with qmail. Having said that, this patch -is the more qmail-friendly approach resulting in large performance gains. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-As mentioned in the 6.4 section for a virtual mail server, a -patch under testing is located at: - -
-http://sf.net/tracker/index.php?func=detail&aid=621257&group_id=103&atid=300103 -
-Again, this patch is for people familiar with their qmail installation. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-You might be interested in some information on modifying footers that Norbert -Bollow has written about Mailman and qmail, available here: - -
-http://mailman.cis.to/qmail-verh/ -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Mailman requires a unique user and group name which will own its files, and
-under which its processes will run. Mailman's basic security is based on
-group ownership permissions, so it's important to get this step
-right1. Typically, you will add a new user and a new
-group, both called mailman. The mailman user must be a member
-of the mailman group. Mailman will be installed under the
-mailman user and group, with the set-group-id (setgid) bit enabled.
-
-
-If these names are already in use, you can choose different user and group -names, as long as you remember these when you run configure. If you -choose a different unique user name, you will have to specify this with -configure's --with-username option, and if you choose -a different group name, you will have to specify this with -configure's --with-groupname option. - -
-On Linux systems, you can use the following commands to create these -accounts. Check your system's manual pages for details: - -
-
- % groupadd mailman - % useradd -c''GNU Mailman'' -s /no/shell -d /no/home -g mailman mailman -
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-After you have completed the integration of Mailman and your mail server, you
-need to create a ``site-wide'' mailing list. This is the one that password
-reminders will appear to come from, and it is required for proper Mailman
-operation. Usually this should be a list called mailman, but if you
-need to change this, be sure to change the MAILMAN_SITE_LIST variable in
-mm_cfg.py. You can create the site list with this command, following
-the prompts:
-
-
-
- % bin/newlist mailman -
-Now configure your site list. There is a convenient template for a generic -site list in the installation directory, under data/sitelist.cfg which -can help you with this. You should review the configuration options in the -template, but note that any options not named in the sitelist.cfg file -won't be changed. - -
-The template can be applied to your site list by -running: - -
-
- % bin/config_list -i data/sitelist.cfg mailman -
-After applying the sitelist.cfg options, be sure you review the -site list's configuration via the admin pages. - -
-You should also subscribe yourself to the site list. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Several Mailman features occur on a regular schedule, so you must set up -cron to run the right programs at the right time6. - -
-If your version of crontab supports the -u option, you must be -root to do this next step. Add $prefix/cron/crontab.in as a -crontab entry by executing these commands: - -
-
- % cd $prefix/cron - % crontab -u mailman crontab.in -
-If you used the --with-username option, use that user name
-instead of mailman for the -u argument value. If your
-crontab does not support the -u option, try these commands:
-
-
-
- % cd $prefix/cron - % su - mailman - % crontab crontab.in -
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Mailman depends on a process called the ``qrunner'' to delivery all -email messages it sees. You must start the qrunner by executing the following -command from the $prefix directory: - -
-
- % bin/mailmanctl start -
-You probably want to start Mailman every time you reboot your system. Exactly -how to do this depends on your operating system. If your OS supports the -chkconfig command (e.g. RedHat and Mandrake Linuxes) you can -do the following (as root, from the Mailman install directory): - -
-
- % cp scripts/mailman /etc/init.d/mailman - % chkconfig --add mailman -
-Note that /etc/init.d may be /etc/rc.d/init.d on some systems. - -
-On Gentoo Linux, you can do the following: - -
-
- % cp scripts/mailman /etc/init.d/mailman - % rc-update add mailman default -
-On Debian, you probably want to use: - -
-
- % update-rc.d mailman defaults -
-For Unixes that don't support chkconfig, you might try the -following set of commands: - -
-
- % cp scripts/mailman /etc/init.d/mailman - % cp misc/mailman /etc/init.d - % cd /etc/rc.d/rc0.d - % ln -s ../init.d/mailman K12mailman - % cd ../rc1.d - % ln -s ../init.d/mailman K12mailman - % cd ../rc2.d - % ln -s ../init.d/mailman S98mailman - % cd ../rc3.d - % ln -s ../init.d/mailman S98mailman - % cd ../rc4.d - % ln -s ../init.d/mailman S98mailman - % cd ../rc5.d - % ln -s ../init.d/mailman S98mailman - % cd ../rc6.d - % ln -s ../init.d/mailman K12mailman -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-You should check the values for DEFAULT_EMAIL_HOST and -DEFAULT_URL_HOST in Defaults.py. Make any necessary changes in -the mm_cfg.py file, not in the Defaults.py file. If you -change either of these two values, you'll want to add the following afterwards -in the mm_cfg.py file: - -
-
- add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) -
-You will want to run the bin/fix_url.py to change the domain of any -existing lists. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-There are two site-wide passwords that you can create from the command line,
-using the bin/mmsitepass script. The first is the ``site password''
-which can be used anywhere a password is required in the system. The site
-password will get you into the administration page for any list, and it can be
-used to log in as any user. Think root for a Unix system, so pick this
-password wisely!
-
-
-The second password is a site-wide ``list creator'' password. You can use -this to delegate the ability to create new mailing lists without providing all -the privileges of the site password. Of course, the owner of the site -password can also create new mailing lists, but the list creator password is -limited to just that special role. - -
-To set the site password, use this command: - -
-
- % $prefix/bin/mmsitepass <your-site-password> -
-To set the list creator password, use this command: - -
-
- % $prefix/bin/mmsitepass -c <list-creator-password> -
-It is okay not to set a list creator password, but you probably do want a site -password. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-For more detailed information about using Mailman, including creating and -configuring mailing lists, see the Mailman List Adminstration Manual. These -instructions provide a quick guide to creating your first mailing list via the -web interface: - -
- -
http://my.dom.ain/mailman/create.
-
--
-
-
-
http://my.dom.ain/mailman/admin/mylist.
-
--
-
-
-
mylist@my.dom.ain.
- Within a minute or two you should see your message reflected back to you
- via Mailman.
--Congratulations! You've just set up and tested your first Mailman mailing -list. If you had any problems along the way, please see the -14 section. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Generally, Mailman runs on any POSIX-based system, such as Solaris, the -various BSD variants, Linux systems, MacOSX, and other generic Unix -systems. It doesn't run on Windows. For the most part, the generic -instructions given in this document should be sufficient to get Mailman -working on any supported platform. Some operating systems have additional -recommended installation or configuration instructions. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Linux seems to be the most popular platform for running Mailman. Here are -some hints on getting Mailman to run on Linux: - -
- -
-Note that if you are using Linux Mandrake in secure mode, you are - probably concerned by this. - -
-
mailman user, you need to be sure mailman is in the
- cctools group.
-
--
-For example, using Python 2.2 on Debian, you will need to install the
- python2.2-dev package. On Redhat, you probably need the
- python2-devel package.
-
-
-If you install Python from source, you should be fine. - -
-One symptom of this problem, although for unknown reasons, is that you - might get an error such as this during your install: - -
-
- Traceback (most recent call last): - File "bin/update", line 44, in ? - import paths - ImportError: No module named paths - make: *** [update] Error 1 -
-If this happens, install the Python development package and try - configure and make install again. Or install the - latest version of Python from source, available from - http://www.python.org. - -
-This problem can manifest itself in other Linux distributions in
- different ways, although usually it appears as ImportErrors.
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Many people run Mailman on MacOSX. Here are some pointers that have been -collected on getting Mailman to run on MacOSX. - -
- -
-
-http://www.afp548.com/Articles/mail/python-mailman.html -
-
-http://mail.python.org/pipermail/mailman-users/2002-October/022944.html -
-
-Terry Allen provides the following detailed instructions on running Mailman on -the 'client' version of OSX, or in earlier versions of OSX: - -
-Mac OSX 10.3 and onwards has the basics for a successful Mailman installation. -Users of earlier versions of Mac OSX contains Sendmail and those users should -look at the Sendmail installation section for tips. You should follow the -basic installation steps as described earlier in this manual, substituting as -appropriate, the steps outlined in this section. - -
-By default, Mac OSX 10.3 'client' version does not have a fully functional -version of Postfix. Setting up a working MTA such as Postfix is beyond the -scope of this guide and you should refer to http://www.postfix.org for -tips on getting Postfix running. An easy way to set Postfix up is to install -and run Postfix Enabler, a stand-alone tool for configuring Postfix on Mac -OSX, available from -http://www.roadstead.com/weblog/Tutorials/PostfixEnabler.html. - -
-Likewise, Mac OSX 'client' version from 10.1 onwards includes a working Apache -webserver. This is switched on using the System Preferences control panel -under the 'Sharing tab'. A useful tool for configuring the Apache on Mac OSX -is Webmin, which can be obtained from -http://www.webmin.com. - -
-Webmin can also perform configuration for other system tasks, including -Postfix, adding jobs to your crontab, adding user and groups, plus adding -startup and shutdown jobs. - -
-In a stock installation of OSX, the requirement for Mailman is to have Python -installed. Python is not installed by default, so it is advised that you -install the developer's tools package, which may have been provided with your -system. It can also be downloaded from the Apple developer site at -http://connect.apple.com. Not only is the developer tools package an -essential requirement for installing Mailman, but it will come in handy at a -later date should you need other tools. The developer's tools are also know -by the name XCode tools. - -
-As a minimum, the Python version should be 2.2, but 2.3 is recommended. - -
-If you wish to add a user and group using the command line in OSX instead of -via Webmin or another GUI interface, open your terminal application and follow -the commands as indicated below - do not type the comments following the -"#" since they are just notes: - -
-
-sudo tcsh -niutil -create / /users/mailman -niutil -createprop / /users/mailman name mailman -# Note that xxx is a free user ID number on your system -niutil -createprop / /users/mailman uid xxx -niutil -createprop / /users/mailman home /usr/local/mailman -mkdir -p /usr/local/mailman -niutil -createprop / /users/mailman shell /bin/tcsh -passwd mailman -# To prevent malicious hacking, supply a secure password here -niutil -create / /groups/mailman -niutil -createprop / /groups/mailman name mailman -# Note that xxx is a free group ID number on your system -niutil -createprop / /groups/mailman gid xxx -niutil -createprop / /groups/mailman passwd '*' -niutil -createprop / /groups/mailman users 'mailman' -chown mailman:mailman /usr/local/mailman -cd /usr/local/mailman -chmod a+rx,g+ws . -exit -su mailman -
-For setting up Apache on OSX to handle Mailman, the steps are almost identical -and the configuration file on a stock Mac OSX Client version is stored in the -nearly standard location of /etc/httpd/httpd.conf. - -
-The AFP548.com site has a time-saving automated startup item creator for -Mailman, which can be found at -http://www.afp548.com/Software/MailmanStartup.tar.gz -
-To install it, copy it into your /Library/StartupItems directory. As -the root or superuser, from the terminal, enter the following: - -
-
-gunzip MailmanStartup.tar.gz -tar xvf MailmanStartup.tar -
-It will create the startup item for you so that when you reboot, Mailman will -start up. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Before you can install Mailman, you must run configure to set -various installation options your system might need. - -
-
-You should not be root while performing the steps in this section.
-Do them under your own login, or whatever account you typically use to install
-software. You do not need to do these steps as user mailman, but you
-could. However, make sure that the login used is a member of the
-mailman group as that that group has write permissions to the
-$prefix directory made in the previous step. You must also have
-permission to create a setgid file in the file system where it resides (NFS
-and other mounts can be configured to inhibit setgid settings).
-
-
-If you've installed other GNU software, you should be familiar with the -configure script. Usually you can just cd to the -directory you unpacked the Mailman source tarball into, and run -configure with no arguments: - -
-
- % cd mailman-<version> - % ./configure - % make install -
-The following options allow you to customize your Mailman -installation. - -
-
-
-
-
-
mailman. The value of this
- option can be an integer user id or a user name. Be sure your
- $prefix directory is owned by this user.
-
--
mailman. The value of this
- option can be an integer group id or a group name. Be sure your
- $prefix directory is group-owned by this group.
-
--
mailman,
- other, mail, and daemon.
-
--
-Check your mail server's documentation and configuration files to find the - right value for this switch. - -
-
www, www-data, and nobody.
-
--
-If you're using Apache, check the values for the Group option in - your httpd.conf file. - -
-
-
-
-
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Once you've run configure, you can simply run make, then -make install to build and install Mailman. - -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-After you've run make install, you should check that your -installation has all the correct permissions and group ownerships by running -the check_perms script. First change to the installation -(i.e. $prefix) directory, then run the bin/check_perms -program. Don't try to run bin/check_perms from the source directory; it will -only run from the installation directory. - -
-If this reports no problems, then it's very likely <wink> that your -installation is set up correctly. If it reports problems, then you can either -fix them manually, re-run the installation, or use bin/check_perms -to fix the problems (probably the easiest solution): - -
- -
-
-
-
-
-# cd <prefix>/archives -# chown <web-server-user> private -# chmod o-x private -
-You need to know what user your web server runs as. It may be www,
-apache, httpd or nobody, depending on your server's
-configuration.
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-Postfix 2.0 supports ``virtual alias domains'', essentially what used to be -called ``Postfix-style virtual domains'' in earlier Postfix versions. To make -virtual alias domains work with Mailman, you need to do some setup in both -Postfix and Mailman. Mailman will write all virtual alias mappings to a file -called, by default, /usr/local/mailman/data/virtual-mailman. It will -also use postmap to create the virtual-mailman.db file -that Postfix will actually use. - -
-First, you need to set up the Postfix virtual alias domains as described in
-the Postfix documentation (see Postfix's virtual(5) manpage). Note
-that it's your responsibility to include the virtual-alias.domain
-anything line as described manpage; Mailman will not include this line in
-virtual-mailman. You are highly encouraged to make sure your virtual
-alias domains are working properly before integrating with Mailman.
-
-
-Next, add a path to Postfix's virtual_alias_maps variable, pointing to -the virtual-mailman file, e.g.: - -
-
- virtual_alias_maps = <your normal virtual alias files>, - hash:/usr/local/mailman/data/virtual-mailman -
-assuming you've installed Mailman in the default location. If you're using an -older version of Postfix which doesn't have the virtual_alias_maps -variable, use the virtual_maps variable instead. - -
-Next, in your mm_cfg.py file, you will want to set the variable -POSTFIX_STYLE_VIRTUAL_DOMAINS to the list of virtual domains that Mailman -should update. This may not be all of the virtual alias domains that your -Postfix installation supports! The values in this list will be matched -against the host_name attribute of mailing lists objects, and must be an -exact match. - -
-Here's an example. Say that Postfix is configured to handle the virtual
-domains dom1.ain, dom2.ain, and dom3.ain, and further
-that in your main.cf file you've got the following settings:
-
-
-
- myhostname = mail.dom1.ain - mydomain = dom1.ain - mydestination = $myhostname, localhost.$mydomain - virtual_alias_maps = - hash:/some/path/to/virtual-dom1, - hash:/some/path/to/virtual-dom2, - hash:/some/path/to/virtual-dom2 -
-If in your virtual-dom1 file, you've got the following lines: - -
-
- dom1.ain IGNORE - @dom1.ain @mail.dom1.ain -
-this tells Postfix to deliver anything addressed to dom1.ain to the
-same mailbox at mail.dom1.com, its default destination.
-
-
-In this case you would not include dom1.ain in
-POSTFIX_STYLE_VIRTUAL_DOMAINS because otherwise Mailman will write
-entries for mailing lists in the dom1.ain domain as
-
-
-
- mylist@dom1.ain mylist - mylist-request@dom1.ain mylist-request - # and so on... -
-The more specific entries trump your more general entries, thus breaking the
-delivery of any dom1.ain mailing list.
-
-
-However, you would include dom2.ain and dom3.ain in
-mm_cfg.py:
-
-
-
- POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain'] -
-Now, any list that Mailman creates in either of those two domains, will have -the correct entries written to /usr/local/mailman/data/virtual-mailman. - -
-As above with the data/aliases* files, you want to make sure that both
-data/virtual-mailman and data/virtual-mailman.db are user and
-group owned by mailman.
-
-
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-There are some issues that users of the qmail mail transport agent have -encountered. None of the core maintainers use qmail, so all of this -information has been contributed by the Mailman user community, especially -Martin Preishuber and Christian Tismer, with notes by Balazs Nagy (BN) and -Norbert Bollow (NB). - -
- -
qmail,
- mailman, or nofiles by using the
- --with-mail-gid configure option.
-
--BN: it highly depends on your mail storing policy. For example - if you use the simple ~alias/.qmail-* files, you can use - `id -g alias`. But if you use /var/qmail/users, the - specified mail gid can be used. - -
-If you are going to be directing virtual domains directly to the
- mailman user (using ``virtualdomains'' on a list-only domain, for
- example), you will have to use --with-mail-gid=gid
- of mailman user's group. This is incompatible with having list aliases
- in ~alias, unless that alias simply forwards to
- mailman-listname*.
-
-
-
mailman on your system, the alias
- mailman-owner will work only in ~mailman. You have to do
- a touch .qmail-owner in ~mailman directory to create
- this alias.
-
-
-NB: An alternative, IMHO better solution is to chown
- root ~mailman, that will stop qmail from considering mailman to
- be a user to whom mail can be delivered. (See ``man 8 qmail-getpw''.)
-
-
-
-
- +zope-:alias:112:11:/var/qmail/alias:-:zope-: - . -
-where in this case the listname is e.g. zope-users.
-
-
-NB: Alternatively, you could host the lists on a virtual domain,
- and use the /var/qmail/control/virtualdomains file to put the
- mailman user in charge of this virtual domain.
-
-
-
mailman, it's necessary to allow it to access ~mailman.
- Be sure that ~mailman has group writing access and setgid bit is
- set. Then put the delivering user to mailman group, and you can
- deny access to ~mailman to others. Be sure that you can do the
- same with the WWW service.
-
-
-By the way the best thing is to make a virtual mail server to handle all
- of the mail. NB: E.g. make an additional "A" DNS record for the
- virtual mailserver pointing to your IP address, add the line
- lists.kva.hu:mailman to /var/qmail/control/virtualdomains
- and a lists.kva.hu line to /var/qmail/control/rcpthosts
- file. Don't forget to HUP the qmail-send after modifying
- ``virtualdomains''. Then every mail to lists.kva.hu will arrive to
- mail.kva.hu's mailman user.
-
-
-Then make your aliases: - -
-
- .qmail => mailman@...'s letters - .qmail-owner => mailman-owner's letters -
-For list aliases, you can either create them manually: - -
-
- .qmail-list => posts to the 'list' list - .qmail-list-admin => posts to the 'list's owner - .qmail-list-request => requests to 'list' - etc -
-or for automatic list alias handling (when using the lists.kva.hu - virtual as above), see contrib/qmail-to-mailman.py in the Mailman - source distribution. Modify the ~mailman/.qmail-default to - include: - -
-
- |preline /path/to/python /path/to/qmail-to-mailman.py -
-and new lists will automatically be picked up. - -
-
-
- tcp-env: 127. 10.205.200. : setenv RELAYCLIENT -
-where 10.205.200. is your IP address block. If you use tcpserver, then - you need something like the following in your /etc/tcp.smtp file: - -
-
- 10.205.200.:allow,RELAYCLIENT="" - 127.:allow,RELAYCLIENT="" -
-
-
-BN: Last but not least, here's a little script to generate aliases to -your lists (if for some reason you can/will not have them automatically picked -up using contrib/qmail-to-mailman.py): - -
-This script is for the Mailman 2.0 series: - -
-
-#!/bin/sh -if [ $# = 1 ]; then - i=$1 - echo Making links to $i in the current directory... - echo "|preline /home/mailman/mail/mailman post $i" > .qmail-$i - echo "|preline /home/mailman/mail/mailman mailowner $i" > .qmail-$i-admin - echo "|preline /home/mailman/mail/mailman mailowner $i" > .qmail-$i-owner - echo "|preline /home/mailman/mail/mailman mailowner $i" > .qmail-owner-$i - echo "|preline /home/mailman/mail/mailman mailcmd $i" > .qmail-$i-request -fi -
-
-
-#!/bin/sh -if [ $# = 1 ]; then - i=$1 - echo Making links to $i in the current directory... - echo "|preline /usr/local/mailman/mail/mailman post $i" > .qmail-$i - echo "|preline /usr/local/mailman/mail/mailman admin $i" > .qmail-$i-admin - echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bounces - # The following line is for VERP - # echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bounces-default - echo "|preline /usr/local/mailman/mail/mailman confirm $i" > .qmail-$i-confirm - echo "|preline /usr/local/mailman/mail/mailman join $i" > .qmail-$i-join - echo "|preline /usr/local/mailman/mail/mailman leave $i" > .qmail-$i-leave - echo "|preline /usr/local/mailman/mail/mailman owner $i" > .qmail-$i-owner - echo "|preline /usr/local/mailman/mail/mailman request $i" > .qmail-$i-request - echo "|preline /usr/local/mailman/mail/mailman subscribe $i" > .qmail-$i-subscribe - echo "|preline /usr/local/mailman/mail/mailman unsubscribe $i" > .qmail-$i-unsubscribe -fi -
- -
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-
-If you encounter problems with running Mailman, first check the question and -answer section below. If your problem is not covered there, check the -online help, including the -FAQ and the -interactive FAQ wizard. - -
-Also check for errors in your syslog files, your mail and web server log files -and in Mailman's $prefix/logs/error file. If you're still -having problems, you should send a message to the -mailman-users@python.org mailing list7; see -http://mail.python.org/mailman/listinfo/mailman-users for more -information. - -
-Be sure to including information on your operating system, which version of -Python you're using, and which version of Mailman you're installing. - -
-Here is a list of some common questions and answers: - -
- -
-Solution: Your web server has not been set up properly for - handling Mailman's CGI programs. Make sure you have: - -
- -
-
-Consult your web server's documentation for instructions on how to do - check these issues. - -
-
-Solution: The likely problem is that you are using the wrong - user or group for the CGI scripts. Check your web server's log files. - If you see a line like - -
-
- Attempt to exec script with invalid gid 51, expected 99 -
-you will need to reinstall Mailman, specifying the proper CGI group id, - as described in the section. - -
-
-Solution: You probably didn't add the necessary aliases to the - system alias database, or you didn't properly integrate Mailman with - your mail server. Perhaps you didn't update the alias database, or your - system requires you to run newaliases explicitly. Refer to - your server specific instructions in the 6 section. - -
-
-Solution: The likely problem is that you are using the wrong - user or group id for the mail wrappers. Check your mail server's log - files; if you see a line like - -
-
- Attempt to exec script with invalid gid 51, expected 99 -
-you will need to reinstall Mailman, specifying the proper mail group id - as described in the section. - -
-
-Solution: Make sure the $prefix/data/aliases.db
- file is user owned by mailman (or whatever user name you used
- in the configure command). If this file is not user owned by
- mailman, Postfix will not run the mail programs as the correct
- user.
-
-
-
-Solution: Your system uses the Sendmail restricted shell - (smrsh). You need to configure smrsh by creating a symbolic link from - the mail wrapper ($prefix/mail/mailman) to the directory - identifying executables allowed to run under smrsh. - -
-Some common names for this directory are /var/admin/sm.bin, - /usr/admin/sm.bin or /etc/smrsh. - -
-Note that on Debian Linux, the system makes /usr/lib/sm.bin, - which is wrong, you will need to create the directory - /usr/admin/sm.bin and add the link there. Note further any - aliases newaliases spits out will need to be adjusted to point - to the secure link to the wrapper. - -
-
-Solution: - -
-
- % make clean - % ./configure --with-the-right-options - % make install -
-
-
|
- |
- |
-GNU Mailman - Installation Manual | - |
- |
- |
-