diff options
Diffstat (limited to '')
| -rw-r--r-- | README | 247 | ||||
| -rw-r--r-- | README-I18N.en | 166 | ||||
| -rw-r--r-- | README.BSD | 27 | ||||
| -rw-r--r-- | README.CONTRIB | 17 | ||||
| -rw-r--r-- | README.EXIM | 353 | ||||
| -rw-r--r-- | README.LINUX | 49 | ||||
| -rw-r--r-- | README.MACOSX | 31 | ||||
| -rw-r--r-- | README.NETSCAPE | 57 | ||||
| -rw-r--r-- | README.POSTFIX | 198 | ||||
| -rw-r--r-- | README.QMAIL | 133 | ||||
| -rw-r--r-- | README.SENDMAIL | 73 | ||||
| -rw-r--r-- | README.USERAGENT | 49 |
12 files changed, 1400 insertions, 0 deletions
@@ -0,0 +1,247 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +INTRODUCTION + + This is GNU Mailman, a mailing list management system distributed + under the terms of the GNU General Public License (GPL). The name + of this software is spelled "Mailman" with a leading capital `M' + but with a lower case second `m'. Any other spelling is + incorrect. + + Mailman is written primarily in Python, a free object-oriented + scripting language. There is some ANSI C code for security + purposes. + + Mailman was originally developed by John Viega. Subsequent + development (through version 1.0b3) was by Ken Manheimer. Further + work towards the 1.0 final release was a group effort, with the + core contributors being: Barry Warsaw, Ken Manheimer, Scott + Cotton, Harald Meland, and John Viega. Version 1.0 and beyond + have been primarily maintained by Barry Warsaw with contributions + from many; see the ACKNOWLEDGMENTS file for details. Jeremy + Hylton helped considerably with the Pipermail code in Mailman 2.0. + + The Mailman home page is + + http://www.gnu.org/software/mailman + + with mirrors at + + http://www.list.org + http://mailman.sf.net + + Mailman 2.1 requires Python 2.1.3 or greater, which can be + downloaded from + + http://www.python.org + + It is recommended that you use Python 2.1.3 or Python 2.2.1, the + latest releases as of this writing. Mailman 2.1 is not compatible + with Python 2.0 or any earlier version. + + You will also need an ANSI C compiler to build both Python and + Mailman; gcc (the GNU C compiler) works just fine. Mailman + currently works only on GNU/Linux and other Unix-like operating + systems (e.g. Solaris, *BSD, MacOSX, etc.). It does not run on + Windows, although web and mail clients on any platform should be + able to interact with Mailman just fine. + + See the INSTALL file for installation instructions. If you are + upgrading from a previous version of Mailman, you need to read the + UPGRADING file for important information. + + +FEATURES + + Read the NEWS file for a list of changes since version 0.9. Read + the TODO file for our (extensive) wish list. You can see Mailman + 2.1 in action at + + http://mail.python.org/mailman-21/listinfo + + Mailman has most of the standard features you'd expect in a + mailing list manager, and more: + + - Web based list administration for nearly all tasks. Web based + subscriptions and user configuration management. A customizable + "home page" for each mailing list. + + - Privacy features such as moderation, open and closed list + subscription policies, private membership rosters, and + sender-based filters. + + - Automatic web based archiving built-in with support for private + and public archives, and hooks for external archivers. + + - Per-user configuration optional digest delivery for either + MIME-compliant or RFC 1153 style "plain text" digests. + + - Integrated mail/Usenet gateways. + + - Integrated auto-replies. + + - Majordomo-style email based commands. + + - Integrated bounce detection within an extensible framework. + + - Integrated spam detection, and MIME-based content filtering. + + - An extensible mail delivery pipeline. + + - Support for virtual domains. + + +REQUIREMENTS + + The default mail delivery mechanism uses a direct SMTP connection + to whatever mail transport agent you have running on port 25. You + can thus use Mailman with any such MTA, however with certain MTAs + (e.g. Exim and Postfix), Mailman will support thru-the-web + creation and removal of mailing lists. + + Mailman works with any web server that supports CGI/1.1. The HTML + it generates is quite pedestrian and stingy on the graphics so it + should be friendly to most web browsers and network connections. + It is regularly tested with IE 5.5, Netscape 4.7x, and Mozilla on + Windows and Netscape 4.7x and Mozilla on Linux (and occasionally + Lynx on Linux and Netscape and Mozilla on MacOS too!). + + You will need root access on the machine hosting your Mailman + installation in order to complete some of the configuration + steps. See the INSTALL file for details. + + Mailman's web and email user interface should be compatible with + just about any mail reader or web browser, although a mail reader + that is MIME aware will be a big help. You do not need Java, + JavaScript, or any other fancy plugins. + + +CREATE YOUR FIRST LIST + + These instructions assume that you've installed and configured + Mailman according to the instructions in the INSTALL file. To + create and test your first list, try the following: + + - First, initialize the site administrator's password by cd'ing to + the install directory (by default /usr/local/mailman) and typing + + % bin/mmsitepass + New site password: [yourpassword] + Again to confirm password: [yourpassword] + Password changed. + + - Visit 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 above. Type your own email address for the "Initial + list owner address", and select "Yes" to notify the list + administrator. + + - Hit "Create List" + + - Check your email for a message from Mailman informing you that + your new mailing list was created. + + - NOTE: If you are using an MTA other than Exim or Postfix + (e.g. Sendmail or qmail), then you'll need to do the extra step + of installing the mailing list aliases manually. Follow the + instructions in an email message that you should have received + (you'll need to know how to do this for your particular MTA, see + the README for your MTA for more information). + + - Now visit the list's admin page (either by following the link on + the web page or entering the link from the email Mailman just + sent you). Typically the url will be something like + + http://my.dom.ain/mailman/admin/mysitelist + + 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 yourlist@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 section below on FOR MORE INFORMATION. + + +FOR MORE INFORMATION + + The online documentation can be found in + + file:admin/www/index.html + + in the directory in which you unpacked Mailman. + + Chris Kolar has made a list owner-oriented manual available from + the following URL + + http://www.imsa.edu/~ckolar/mailman/ + + There are also several mailing lists that can be used as resources + to help you get going with Mailman. + + Mailman-Users + An list for users of Mailman, for posting questions or + problems related to installation, use, etc. We'll try to keep + the deep technical discussions off this list. + + http://mail.python.org/mailman/listinfo/mailman-users + + Listowners + This mailing list with a non-technical focus, specifically for + discussions from the perspective of listowners and moderators + who do not have "shell access" to the mailing list server + where the Mailman software runs. + + http://listowner.org + + Mailman-Announce + A read-only list for release announcements an other important + news. + + http://mail.python.org/mailman/listinfo/mailman-announce + + Mailman-Developers + A list for those of you interested in helping develop + Mailman's future direction. This list will contain in-depth + technical discussions. + + http://mail.python.org/mailman/listinfo/mailman-developers + + Mailman-I18N + A list for the discussion of the Mailman internationalization + effort. Mailman 2.1 will be fully multi-lingual. + + http://mail.python.org/mailman/listinfo/mailman-i18n + + Mailman-Checkins + A read-only list which is an adjunct to the public anonymous + CVS repository. You can stay on the bleeding edge of Mailman + development by subscribing to this list. + + http://mail.python.org/mailman/listinfo/mailman-checkins + + The Mailman project is coordinated on SourceForge at + + http://sf.net/projects/mailman + + You should use SourceForge to report bugs and to upload patches. + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +End: diff --git a/README-I18N.en b/README-I18N.en new file mode 100644 index 00000000..59b20965 --- /dev/null +++ b/README-I18N.en @@ -0,0 +1,166 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +INTERNATIONALIZATION + + Mailman 2.1 is multilingual. By default it supports English, but + additional languages may also be available. If the language you + want to add is already supported by Mailman, then getting all your + lists to also support that language is fairly easy. You just need + to go to the administrative web pages, click on the "Languages" + category, and select the languages you want your list to support. + + If the language you want to use has not been previously + translated, or you don't know where to find the language pack for + your language, read the section below or contact the Mailman + internationalization mailing list mailman-i18n@python.org. + + +ADDING NEW TRANSLATIONS + + Suppose you want to add new translations for a previously + unsupported language, what steps would you need to take? + + First, you should send a message to mailman-i18n@python.org to + make sure nobody has already created the translations for your + language. In the example below, we're going to create a + translation for the mythical language "Fredonia" which has the + official language code of "xx". + + You should also see + + http://www.list.org/MM21/i18n.html + + for more information on internationalizing Mailman. + + In general you need to do two things to add translations for a + language in Mailman. You need to translate the message catalog + and you need to translate the templates. + + To translate the message catalog, grab the file + messages/mailman.pot and make a copy called mailman.po in the + subdirectory messages/xx/LC_MESSAGES. Then you edit the file and + add the translations for each message identified in the catalog. + It will be very helpful to have a good tool, such as KDE's KBabel + tool, or po-mode for Emacs, for this part of the job. + + Once you've added your translations, you can then run msgfmt over + your .po file to generate messages/xx/LC_MESSAGE/mailman.mo. + + Next, create the subdirectory templates/xx and translate each of + the files in templates/en/*.{html,txt}. These you should also + donate back to the Mailman project. + + To make Mailman and your lists aware of the new language, follow + the directions in the section above. + + +TRANSLATION HINTS + + Q: If your language uses non-ASCII characters, such as the cedilla in + French, how should you add these to the catalogs and templates? + + A: For any message that is destined for the web interface, use an + HTML entity reference where appropriate. For messages destined + for email, you should use the non-ASCII characters explicitly. + This includes both for the message catalog and the templates. + + +RESYNCHRONIZING THE CATALOG + + As Mailman development continues, new updated catalogs + (i.e. mailman.pot files) will be made available. As mailman.pot + changes, the individual language catalogs + (i.e. xx/LC_MESSAGES/mailman.po files) need to be updated as well. + + In general, I as the Mailman maintainer will merge the new + catalogs with the individual language catalogs, and commit the + updates to CVS. Translators should grab the new mailman.po files + from CVS and update the translated messages. They should also + update the template translations. + + For best results, you will probably want to keep current on + changes to Mailman 2.1 in the CVS. As Mailman 2.1 moves towards + final release, the catalogs and templates should start to + stabilize. Alternatively, occasionally I will make new English + language packs available on SourceForge, and you can use these to + create your translations. + + +DONATING YOUR TRANSLATION BACK TO MAILMAN + + We'd really appreciate it if you donate your translations back to + the Mailman project, so that others can benefit from your effort. + You'll get credit of course, in the Mailman documentation. Here + are the steps to donate your translations, either the first time + or subsequent updates. + + The best thing to do is to send me <barry@python.org> a "tarball", + i.e. a gzip'd tarfile, that can be unpacked in the top level + directory of the Mailman CVS tree. This would be the directory + containing this README-I18N.en file. + + Your tarball should contain two directories, where your donated + language is `xx': + + templates/xx + messages/xx + + In templates/xx there should be the translated templates, all the + .txt and .html files, for your language, mirroring those in the + English template directory (always the master copy). + + In messages/xx you should have a single directory LC_MESSAGES, and + in that directory a file called mailman.po, which is the human + readable catalog for your language. Do not send me the mailman.mo + file, since I'll recreate it on my end, and that'll save on the + size of the tarball. + + That's basically it. If you need to include a README, please call + it README.xx and put it in the messages/xx directory. README.xx + can be in your native language. + + You can email the tarball to me, and if this is the first + installation of the language, please tell me what the + add_language() call in Defaults.py.in should be for your + language. + + +CURRENT LIST OF LANGUAGE SUPPORTED OUT-OF-THE BOX + + As of this writing (23-Dec-2002), Mailman 2.1 supports the + following languages out of the box: + + - Czech + - Chinese (Simplified and Traditional) + - Dutch + - English + - Estonian + - Finnish + - French + - German + - Hungarian + - Italian + - Japanese + - Korean + - Lithuanian + - Spanish + - Swedish + - Norwegian + - Portuguese (Brazil) + - Russian + + We've also had volunteers for these languages, although they + aren't yet integrated into the code base: + + - Catalan + - Polish + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.BSD b/README.BSD new file mode 100644 index 00000000..f5b6a0eb --- /dev/null +++ b/README.BSD @@ -0,0 +1,27 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +BSD ISSUES + +1. Vivek Khera writes that BSD does nightly security scans for setuid + file changes. Setgid directories also come up on the scan when + they change. He says that setgid bit is not necessary on BSD + systems because group ownership is automatically inherited on files + created in directories. On other Un*xes, 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, like so: + + % make DIRSETGID=: install + + This turns off the chmod g+s on each directory as they are + installed. + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.CONTRIB b/README.CONTRIB new file mode 100644 index 00000000..b15d57cb --- /dev/null +++ b/README.CONTRIB @@ -0,0 +1,17 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +Encrypted mailing lists + + Raphinou <rb@raphinou.com> has documented a setup for encrypted + mailing lists at + + http://www.raphinou.com/smailman + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +End: diff --git a/README.EXIM b/README.EXIM new file mode 100644 index 00000000..c1e93827 --- /dev/null +++ b/README.EXIM @@ -0,0 +1,353 @@ +Using Exim and Mailman Together +=============================== + +[This 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] + + +Mailman configuration +--------------------- + +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. + + +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. + + +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 + + +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 + +(XXX this is untested by me under Exim 3! Can someone using Exim 3 +please let me know if it works?) + + +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 + + +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 + + +Transports for Exim 4 +~~~~~~~~~~~~~~~~~~~~~ + +The transport for Exim 4 is the same as for Exim 3; just copy the +transport given above to somewhere under the "begin transports" line of +your Exim config file. + + +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. + + +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 + 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 ~mailman/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. + + +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.) + + +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 + +[XXX all this stuff is completely untested by me! -Greg] + + +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 +~mailman/Mailman/Default.py for the options that start with VERP. In a +nutshell, all you need to do to enable VERP with Exim is to add these +lines to ~mailman/Mailman/mm_cfg.py: + + VERP_PASSWORD_REMINDERS = 1 + VERP_PERSONALIZED_DELIVERIES = 1 + VERP_DELIVERY_INTERVAL = 1 + VERP_CONFIRMATIONS = 1 + +(The director (router) above is smart enough to deal with VERP bounces.) + + +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 + + +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! + + +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>. diff --git a/README.LINUX b/README.LINUX new file mode 100644 index 00000000..77fa7e67 --- /dev/null +++ b/README.LINUX @@ -0,0 +1,49 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +GNU/LINUX ISSUES + + GNU/Linux seems to be the most popular platform on which to run + 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 + contrib/README.check_perms_grsecurity. + + Note that if you are using Linux Mandrake in secure mode, you are probably + concerned by this. + + +PYTHON PACKAGES + + Note that 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 ; make install" again. + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.MACOSX b/README.MACOSX new file mode 100644 index 00000000..272d15ff --- /dev/null +++ b/README.MACOSX @@ -0,0 +1,31 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +MacOSX ISSUES + + Mailman should run on MacOSX, although I have not personally had + time to try it yet. Here are some pointers we've 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/022947.html + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.NETSCAPE b/README.NETSCAPE new file mode 100644 index 00000000..0f879b74 --- /dev/null +++ b/README.NETSCAPE @@ -0,0 +1,57 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +NETSCAPE ISSUES + + Some of your users may experience problems sending mail to a + members-only list, if they are using Netscape Communicator as + their MUA. Communicator 4.x on Linux has been observed to insert + bogus unqualified Sender: headers -- i.e. Sender: headers with + only the username part of the email address. Other version of + Netscape may also have the same bug. + + By default, members-only lists use the From: header as the first + field to authenticate against, falling back to Sender:. The site + administrator can also configure Mailman to always use Sender: + first. If Sender: is used, and it exists in the email message, + but it is unqualified, it will never match a mailing list member's + address, and their post will always be held for approval. + + In the future, Mailman will improve its algorithm for finding a + matching address, but in the meantime, M. A. Lemburg <mal@lemburg.com> + provides the following advice. You can send this snippet to any user + whose posts are being held for seemingly no reason. + + Edit the two .js files in your .netscape directory (liprefs.js and + preferences.js) to include the function call: + + user_pref("mail.suppress_sender_header", true); + + BTW, the binary includes a comment which says that this is only + necessary on Unix. + + Since Communicator regenerates this file upon exit, the change + must be done when Communicator is not currently running. With the + next start, it will stop adding the Sender: header and things + start to work like a charm again. + + The reason things start to work again, is that Mailman falls back to + authenticating the From: header if the Sender: header is missing, + even if the site administrator has configured things to look at + Sender: first. + + +MOZILLA + + There are no known problems with Mozilla 0.9.x at this time. I + don't know whether the above Netscape problem also affects + Mozilla. + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +End: diff --git a/README.POSTFIX b/README.POSTFIX new file mode 100644 index 00000000..204fd26c --- /dev/null +++ b/README.POSTFIX @@ -0,0 +1,198 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +GENERAL SETUP INFORMATION + + Mailman should work pretty much out of the box with a standard + Postfix installation. As of this writing I've tested it with + Postfix 19991231 up to pl13, and with 200010228 up to pl08. + + It is recommended that you set "owner_request_special = no" in + your main.cf config file so that Postfix won't treat -owner and + -request addresses specially (we want Postfix to simply deliver + such messages to the Mailman wrapper). The default is "yes" I + believe. + + 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. Here, my + recommendations are to comment out any luser_relay value in your + main.cf and just go with the defaults. Also, set + "recipient_delimiter = +" so that the symbol used to separate an + address from its extended semantics is a + sign. This will work + well with the default values for VERP_FORMAT and VERP_REGEXP in + Defaults.py. + + Finally, if you are using Postfix-style virtual domains, read the + section on virtual domain support below. + + +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. + + - If you are using Postfix-style virtual domains and you want + Mailman to honor your virtual domains, read the 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 Mailman/MTA which contains the + MTA-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. + + - Run the 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' and that the group owner for those files is + `mailman'. E.g.: + + % su + % chown mailman:mailman data/aliases* + + - Hack your Postfix's main.cf file to include the following path + in your alias_maps variable: + + /usr/local/mailman/data/aliases + + (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 (actually, 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. I consider this a + minor inconvenience. + + +VIRTUAL DOMAINS + + Postfix supports two styles of virtual domains, called + "Postfix-style" and "Sendmail-style". With the latter, all + aliases are visible in all domains, and nothing special need be + done with Mailman. + + With Postfix-style virtual domains, things are a little trickier, + although Mailman should work well with it. First, you'll need to + add a path to Postfix's virtual_maps variable: + + virtual_maps = <your normal virtual files>, + hash:/usr/local/mailman/data/virtual-mailman + + assuming you've installed Mailman in the default location. Note + that you must follow Postfix's instructions for setting up the + virtual domains; get your virtual domains working in Postfix + first before integrating Mailman. + + 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 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: + + Let's say I've set up Postfix to handle the virtual domains + dom1.ain, dom2.ain, and dom3.ain. Let's say further that in + main.cf you've got the following settings: + + myhostname = mail.dom1.ain + mydomain = dom1.ain + mydestination = $myhostname, localhost.$mydomain + virtual_maps = hash:/some/path/to/virtual-dom1, + hash:/some/path/to/virtual-dom2, + hash:/some/path/to/virtual-dom2 + + Let's say further that in virtual-dom1, 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, it's 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 and 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 the `mailman' user/group. So to get things + started, set up your virtual domains, run bin/genaliases, and + check the ownerships of the files. From here on out, you should + be good to go. + + +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. + + I have not extensively tested this approach however. + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.QMAIL b/README.QMAIL new file mode 100644 index 00000000..3ae5717f --- /dev/null +++ b/README.QMAIL @@ -0,0 +1,133 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +MORE INFORMATION + +You might be interested in some information that Norbert Bollow has +written about Mailman and Qmail integration, available here: + + http://mailman.cis.to/qmail-verh/ + + +QMAIL ISSUES + +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 distribution. + Modify the "~mailman/.qmail-default" to include: + + |/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"): + +#!/bin/sh +if [ $# = 1 ]; then + i=$1 + echo Making links to $i... + 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 + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.SENDMAIL b/README.SENDMAIL new file mode 100644 index 00000000..8b24e38d --- /dev/null +++ b/README.SENDMAIL @@ -0,0 +1,73 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +SECURITY NOTE + + You may be tempted to set the DELIVERY_MODULE configuration + variable in mm_cfg.py to `Sendmail' when using the Sendmail MTA. + 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 (the default). Sendmail.py has known + security holes and is provided as a proof-of-concept only. If you + are having problems using SMTPDirect.py please fix those instead + of using Sendmail.py, or you may open your system up to security + exploits. + + +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 filter programs. You need to + explicitly allow Mailman's wrapper program to be used with smrsh + before it will 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 doing this is to: + + - cd into /etc/smrsh (or where ever it happens to reside on + your system, such as /var/smrsh or /usr/local/smrsh). + + - create a symbolic link to Mailman's wrapper program + + For example, if you've installed Mailman in the standard location, + you can just execute these commands (you might have to do these as + root): + + % cd /etc/smrsh + % ln -s /usr/local/mailman/mail/mailman mailman + + +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, 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 + + +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 /not/ to do DNS + verification synchronously for localhost connections. + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: diff --git a/README.USERAGENT b/README.USERAGENT new file mode 100644 index 00000000..497e66df --- /dev/null +++ b/README.USERAGENT @@ -0,0 +1,49 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +INTRODUCTION + + Mailman is compliant with RFC 2369, which specifies a number of + List-* headers that mailing list management software should add to + every outbound email message. These headers are designed to make + it easy for mail user agents (MUAs) to assist users in common + mailing list tasks, such as getting help or unsubscribing. + + At this time, not all MUAs understand the RFC 2369 headers, and + instead of suppressing those List-* headers, they show them to the + user. Many list managers report that this can generate a large + amount of support requests from their user base. + + In Mailman 2.0, you cannot turn off the List-* headers without + hacking the Mailman source. Because these headers are in the + long-term benefit of end-users, it is strongly encouraged to leave + these headers in and lobby the MUA vendors to support them. In + the meantime, you can provide your users with the following + information to help them suppress these headers. + + +EUDORA USERS + + Mike Noyes provides the following suggestion: + + You can hide the new list headers. Edit your Eudora.ini file, and + add this line under [settings]. + + TabooHeaders=List,X-UID,Received,Status,X-UIDL,Message,In-Reply, \ + X-Priority,Mime-Version,Content,X-Persona,Resent-Message,References, \ + Return,X400,X-400,Mail-System,Errors-To,X-List,Delivery,Disposition, \ + X-Juno,Precedence,X-Attachments,X-MSMail,X-MimeOLE,X-Nav + + note: everything other than "List" is the default + + ref. Eudora .ini Settings TabooHeaders + http://www.eudora.com/techsupport/ini.html + + + +Local Variables: +mode: text +indent-tabs-mode: nil +End: |