diff options
Diffstat (limited to 'admin/www/mailman-install.txt')
| -rw-r--r-- | admin/www/mailman-install.txt | 1559 |
1 files changed, 0 insertions, 1559 deletions
diff --git a/admin/www/mailman-install.txt b/admin/www/mailman-install.txt deleted file mode 100644 index 58ad401a..00000000 --- a/admin/www/mailman-install.txt +++ /dev/null @@ -1,1559 +0,0 @@ - - #GNU Mailman - Installation Manual About this document... About this - document... - - Previous Page Up One Level Next Page GNU Mailman - Installation Manual - _________________________________________________________________ - -GNU Mailman - Installation Manual - - Barry Warsaw - - barry(at)python.org - - Release 2.1 - December 13, 2005 - - Front Matter - - Abstract: - - This document describes how to install GNU Mailman on a POSIX-based - system such as Unix, MacOSX, or GNU/Linux. It will cover basic - installation instructions, as well as guidelines for integrating - Mailman with your web and mail servers. - - The GNU Mailman website is at http://www.list.org - - 1 Installation Requirements - - 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. - - 2 Set up your system - - 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. - -2.1 Add the group and user - - 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 - -2.2 Create the installation directory - - Typically, Mailman is installed into a single directory, which - includes both the Mailman source code and the run-time list and - archive data. It is possible to split the static program files from - the variable data files and install them in separate directories. This - section will describe the available options. - - 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. - - Warning: You cannot install Mailman on a filesystem that is mounted - with the 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. - - 3 Build and install Mailman - -3.1 Run configure - - Before you can install Mailman, you must run configure to set various - installation options your system might need. - - Note: Take special note of the --with-mail-gid and --with-cgi-gid - options below. You will probably need to use these. - - 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. - - --prefix=dir - Standard GNU configure option which changes the base directory - that Mailman is installed into. By default $prefix is - /usr/local/mailman. This directory must already exist, and be - set up as described in 2.2. - - --exec-prefix=dir - Standard GNU configure option which lets you specify a - different installation directory for architecture dependent - binaries. - - --with-var-prefix=dir - Store mutable data under dir instead of under the $prefix or - $exec_prefix. Examples of such data include the list archives - and list settings database. - - --with-python=/path/to/python - Specify an alternative Python interpreter to use for the - wrapper programs. The default is to use the interpreter found - first on your shell's $PATH. - - --with-username=username-or-uid - Specify a different username than 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. - - --with-groupname=groupname-or-gid - Specify a different groupname than 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. - - --with-mail-gid=group-or-groups - Specify an alternative group for running scripts via the mail - wrapper. group-or-groups can be a list of one or more integer - group ids or symbolic group names. The first value in the list - that resolves to an existing group is used. By default, the - value is the list mailman, other, mail, and daemon. - - Note: This is highly system dependent and you must get this - right, because the group id is compiled into the mail wrapper - program for added security. On systems using sendmail, the - sendmail.cf configuration file designates the group id of - sendmail processes using the DefaultUser option. (If commented - out, it still may be indicating the default...) - - Check your mail server's documentation and configuration files - to find the right value for this switch. - - --with-cgi-gid=group-or-groups - Specify an alternative group for running scripts via the CGI - wrapper. group-or-groups can be a list of one or more integer - group ids or symbolic group names. The first value in the list - that resolves to an existing group is used. By default, the - value is the the list www, www-data, and nobody. - - Note: The proper value for this is dependent on your web server - configuration. You must get this right, because the group id is - compiled into the CGI wrapper program for added security, and - no Mailman CGI scripts will run if this is incorrect. - - If you're using Apache, check the values for the Group option - in your httpd.conf file. - - --with-cgi-ext=extension - Specify an extension for cgi-bin programs. The CGI wrappers - placed in $prefix/cgi-bin will have this extension (some web - servers require an extension). extension must include the - leading dot. - - --with-mailhost=hostname - Specify the fully qualified host name part for outgoing email. - After the installation is complete, this value can be overriden - in $prefix/Mailman/mm_cfg.py. - - --with-urlhost=hostname - Specify the fully qualified host name part of urls. After the - installation is complete, this value can be overriden in - $prefix/Mailman/mm_cfg.py. - - --with-gcc=no - Don't use gcc, even if it is found. In this case, cc must be - found on your $PATH. - -3.2 Make and install - - Once you've run configure, you can simply run make, then make install - to build and install Mailman. - - 4 Check your installation - - 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): - - * You need to become the user that did the installation, and that - owns all the files in $prefix, or root. - * Run bin/check_perms -f - * Repeat previous step until no more errors are reported! - - Warning: If you're running Mailman on a shared multiuser system, and - you have mailing lists with private archives, you may want to hide the - private archive directory from other users on your system. In that - case, you should drop the other execute permission (o-x) from the - archives/private directory. However, the web server process must be - able to follow the symbolic link in public directory, otherwise your - public Pipermail archives will not work. To set this up, become root - and run the following commands: - -# 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. - - 5 Set up your web server - - 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/ - - Warning: You want to be very sure that the user id under which your - CGI scripts run is not in the 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. - - 6 Set up your mail server - - 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. - -6.1 Using the Postfix mail server - - 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. - - 6.1.1 Integrating Postfix and Mailman - - 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. - - Note: If you are using virtual domains and you want Mailman to honor - your virtual domains, read the 6.1 section below first! - - * Add this to the bottom of the $prefix/Mailman/mm_cfg.py file: - 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. - * Look at the Defaults.py file for the variables POSTFIX_ALIAS_CMD - and POSTFIX_MAP_CMD command. Make sure these point to your - postalias and postmap programs respectively. Remember that if you - need to make changes, do it in mm_cfg.py. - * Run the bin/genaliases script to initialize your aliases file. - % 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* - - * Hack your Postfix's main.cf file to include the following path in - your alias_maps variable: - /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 - * When you configure Mailman, use the --with-mail-gid=mailman - switch; this will be the default if you configured Mailman after - adding the 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. - - 6.1.2 Virtual domains - - 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. - - 6.1.3 An alternative approach - - Fil fil@rezo.net has an alternative approach based on virtual maps and - regular expressions, as described at: - - * (French) http://listes.rezo.net/comment.php - * (English) http://listes.rezo.net/how.php - - 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. - -6.2 Using the Exim mail server - - Note: This section is derived from Nigel Metheringham's ``HOWTO - - Using Exim and Mailman together'', which covers Mailman 2.0.x and Exim - 3. It has been updated to cover Mailman 2.1 and Exim 4. The original - document is here: http://www.exim.org/howto/mailman.html. - - 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. - - 6.2.1 Exim configuration - - 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: - - * add the list domain, ``my.list.domain'' to local_domains - * add a ``domains=my.list.domain'' option to the director (router) - for the list - * (optional) exclude that domain from your other directors (routers) - - 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. - - 6.2.2 Main configuration settings - - 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 - - 6.2.3 Transport for Exim 3 - - 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 - - 6.2.4 Director for Exim 3 - - 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 - - 6.2.5 Router for Exim 4 - - 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 - - 6.2.6 Transports for Exim 4 - - 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. - - 6.2.7 Additional notes - - 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. - - 6.2.8 Problems - - * Mailman will send as many 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. - * Mailman should ignore Exim delay warning messages, even though - Exim should never send this to list messages. Mailman 2.1's - general bounce detection and VERP support should greatly improve - the bounce detector's hit rates. - * List existence is determined by the existence of a config.pck file - for a list. If you delete lists by foul means, be aware of this. - * If you are getting Exim or Mailman complaining about user ids when - you send mail to a list, check that the MAILMAN_USER and - MAILMAN_GROUP match those of Mailman itself (i.e. what were used - in the configure script). Also make sure you do not have aliases - in the main alias file for the list. - - 6.2.9 Receiver Verification - - 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.) - - 6.2.10 SMTP Callback - - 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 - - 6.2.11 Doing VERP with Exim and Mailman - - 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.) - - 6.2.12 Virtual Domains - - 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 - - 6.2.13 List Verification - - 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! - - 6.2.14 Document History - - 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. - -6.3 Using the Sendmail mail server - - Warning: You may be tempted to set the DELIVERY_MODULE configuration - variable in mm_cfg.py to '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. - - 6.3.1 Sendmail ``smrsh'' compatibility - - 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: - - * Find out where your Sendmail executes its smrsh wrapper - % grep smrsh /etc/mail/sendmail.cf - - * Figure out where smrsh expects symlinks for allowable mail - programs. At the very beginning of the following output you will - see a full path to some directory, e.g. /var/adm/sm.bin or - similar: - % strings $path_to_smrsh | less - - * cd into /var/adm/sm.bin, or where ever it happens to reside on - your system - alternatives include /etc/smrsh, /var/smrsh and - /usr/local/smrsh. - % cd /var/adm/sm.bin - - * Create a symbolic link to Mailman's wrapper program: - % ln -s /usr/local/mailman/mail/mailman mailman - - 6.3.2 Integrating Sendmail and Mailman - - 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: - - * mm-handler.readme - an explanation of how to set everything up - * mm-handler - the mail delivery agent (MDA) - * mailman.mc - a toy configuration file sample - * virtusertable - a sample for RFC 2142 address exceptions - - 6.3.3 Performance notes - - 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. - -6.4 Using the Qmail mail server - - 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). - - * You might need to set the mail-gid user to either 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*. - * If there is a user 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''.) - * In a related issue, if you have any users with the same name as - one of your mailing lists, you will have problems if list names - contain "-" in them. Putting .qmail redirections into the user's - home directory doesn't work because the Mailman wrappers will not - get spawned with the proper GID. The solution is to put the - following lines in the /var/qmail/users/assign file: - +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. - * BN:If inbound messages are delivered by another user than 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. - * You have to make sure that the localhost can relay. If you start - qmail via inetd and tcpenv, you need some line the following in - your /etc/hosts.allow file: - 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: Bigger /var/qmail/control/concurrencyremote values work better - sending outbound messages, within reason. Unless you know your - system can handle it (many if not most cannot) this should not be - set to a value greater than 120. - * More information about setting up qmail and relaying can be found - in the qmail documentation. - - 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 - - Note: This is for a new Mailman 2.1 installation. Users upgrading from - Mailman 2.0 would most likely change /usr/local/mailman to - /home/mailman. If in doubt, refer to the --prefix option passed to - configure during compile time. - -#!/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-boun -ces - # The following line is for VERP - # echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bo -unces-default - echo "|preline /usr/local/mailman/mail/mailman confirm $i" > .qmail-$i-conf -irm - 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-requ -est - echo "|preline /usr/local/mailman/mail/mailman subscribe $i" > .qmail-$i-su -bscribe - echo "|preline /usr/local/mailman/mail/mailman unsubscribe $i" > .qmail-$i- -unsubscribe -fi - - 6.4.1 Information on VERP - - 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&gro - up_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. - - 6.4.2 Virtual mail server - - 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&at - id=300103 - - Again, this patch is for people familiar with their qmail - installation. - - 6.4.3 More information - - 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/ - - 7 Review your site defaults - - 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. - - Note: Do not change the HOME_DIR or MAILMAN_DIR variables. These are - set automatically by the configure script, and you will break your - Mailman installation by if you change these. - - You should make any changes to mm_cfg.py using the account you - installed Mailman under in the 14 section. - - 8 Create a site-wide mailing list - - 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. - - 9 Set up cron - - Several Mailman features occur on a regular schedule, so you must set - up cron to run the right programs at the right time^6. - - 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 - - 10 Start the Mailman qrunner - - 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 - - 11 Check the hostname settings - - 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. - - 12 Create the site password - - 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. - - 13 Create your first mailing list - - 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: - - * Start by visiting the url http://my.dom.ain/mailman/create. - * Fill out the form as described in the on-screen instructions, and - in the ``List creator's password'' field, type the password you - entered in section 7. Type your own email address for the - ``Initial list owner address'', and select ``Yes'' to notify the - list administrator. - * Click on the ``Create List'' button. - * Check your email for a message from Mailman informing you that - your new mailing list was created. - * Now visit the list's administration page, either by following the - link on the confirmation web page or clicking on the link from the - email Mailman just sent you. Typically the url will be something - like http://my.dom.ain/mailman/admin/mylist. - * Type in the list's password and click on ``Let me in...'' - * Click on ``Membership Management'' and then on ``Mass - Subscription''. - * Enter your email address in the big text field, and click on - ``Submit Your Changes''. - * Now go to your email and send a message to 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. - - 14 Troubleshooting - - 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: - - * Problem: All Mailman web pages give a 404 File not found error. - Solution: Your web server has not been set up properly for - handling Mailman's CGI programs. Make sure you have: - 1. configured the web server to give permissions to - $prefix/cgi-bin - 2. restarted the web server properly. - Consult your web server's documentation for instructions on how to - do check these issues. - * Problem: All Mailman web pages give an "Internal Server Error". - 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. - * Problem: I send mail to the list, and get back mail saying the - list is not found! - 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. - * Problem: I send mail to the list, and get back mail saying, - ``unknown mailer error''. - 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. - * Problem: I use Postfix as my mail server and the mail wrapper - programs are logging complaints about the wrong GID. - 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. - * Problem: I use Sendmail as my mail server, and when I send mail to - the list, I get back mail saying, ``sh: mailman not available for - sendmail programs''. - 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. - * Problem: I messed up when I called configure. How do I clean - things up and re-install? - Solution: - % make clean - % ./configure --with-the-right-options - % make install - - 15 Platform and operating system notes - - 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. - -15.1 GNU/Linux issues - - Linux seems to be the most popular platform for running Mailman. Here - are some hints on getting Mailman to run on Linux: - - * If you are getting errors with hard link creations and/or you are - using a special secure kernel (securelinux/openwall/grsecurity), - see the file contrib/README.check_perms_grsecurity in the Mailman - source distribution. - Note that if you are using Linux Mandrake in secure mode, you are - probably concerned by this. - * Apparently Mandrake 9.0 changed the permissions on gcc, so if you - build as the mailman user, you need to be sure mailman is in the - cctools group. - * If you installed Python from your Linux distribution's package - manager (e.g. .rpms for Redhat-derived systems or .deb for - Debian), you must install the ``development'' package of Python, - or you may not get everything you need. - 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. - -15.2 BSD issues - - 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. - -15.3 MacOSX issues - - Many people run Mailman on MacOSX. Here are some pointers that have - been collected on getting Mailman to run on MacOSX. - - * Jaguar (MacOSX 10.2) comes with Python 2.2. While this isn't the - very latest stable version of Python, it ought to be sufficient to - run Mailman 2.1. - * David B. O'Donnell has a web page describing his configuration of - Mailman 2.0.13 and Postfix on MacOSX Server. - http://www.afp548.com/Articles/mail/python-mailman.html - * Kathleen Webb posted her experiences in getting Mailman running on - Jaguar using Sendmail. - http://mail.python.org/pipermail/mailman-users/2002-October/022944 - .html - * Panther server (MacOSX 10.3) comes with Mailman; Your operating - system should contain documentation that will help you, and Apple - has a tech document about a problem you might encounter running - Mailman on Mac OS X Server 10.3: - http://docs.info.apple.com/article.html?artnum=107889 - - 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. - - About this document ... - - GNU Mailman - Installation Manual, December 13, 2005, Release 2.1 - - 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. - _________________________________________________________________ - - Footnotes - - ... right1 - You will be able to check and repair your permissions after - installation is complete. - - .../usr/local/mailman2 - This is the default for Mailman 2.1. Earlier versions of - Mailman installed everything under /home/mailman by default. - - ... set3 - BSD users should see the 15.2 section for additional - information. - - ... only4 - In fact, in later versions of Mailman, this module is - explicitly sabotaged. You have to know what you're doing in - order to re-enable it. - - ... lists5 - In general, changing the list defaults described in this - section will not affect any already created lists. To make - changes after a list has been created, use the web interface or - the command line scripts, such as bin/withlist and - bin/config_list. - - ... time^6 - Note that if you're upgrading from a previous version of - Mailman, you'll want to install the new crontab, but be careful - if you're running multiple Mailman installations on your site! - Changing the crontab could mess with other parallel Mailman - installations. - - ... list7 - You must subscribe to this mailing list in order to post to it, - but the mailing list's archives are publicly visible. - _________________________________________________________________ - - Previous Page Up One Level Next Page GNU Mailman - Installation Manual - _________________________________________________________________ - - Release 2.1, documentation updated on December 13, 2005. |