-'''
- first = 1
- question = []
- answer = []
- faq = []
- while 1:
- line = lines[lineno][:-1]
-
- if line.startswith('Q.'):
- inquestion = 1
- if not first:
- faq.append((question, answer))
- question = []
- answer = []
- else:
- first = 0
- elif line.startswith('A.'):
- inquestion = 0
- elif line.startswith('\f'):
- break
-
- if inquestion:
- question.append(line)
- else:
- # watch for lists
- if line.lstrip().startswith('*'):
- answer.append('
')
- line = line.replace('*', '', 1)
- # substitute <...>
- line = re.sub(r'<(?P[^>]+)>',
- '\g',
- line)
- # make links active
- line = re.sub(r'(?Phttp://\S+)',
- '\g',
- line)
- answer.append(line)
-
- lineno += 1
- faq.append((question, answer))
-
- for question, answer in faq:
- print >> out, '',
- for line in question:
- print >> out, line
- print >> out, ' ',
- for line in answer:
- if not line:
- print >> out, '
',
- else:
- print >> out, line
-
- if closep:
- out.close()
-
-
-
-if __name__ == '__main__':
- main()
diff --git a/admin/bin/mm2do b/admin/bin/mm2do
deleted file mode 100755
index e6b7a534..00000000
--- a/admin/bin/mm2do
+++ /dev/null
@@ -1,76 +0,0 @@
-#! /usr/bin/env python
-#
-# Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-"""Generate the todo.ht file from the plain-text TODO file."""
-
-import sys
-
-infp = open(sys.argv[1])
-outfp = open(sys.argv[2], 'w')
-
-SPACE = ' '
-
-print >> outfp, 'Title: The Mailman Wishlist\n'
-
-def dumpsection(header, items, hasitems):
- # We're looking at a header
- if header:
- # output the previous section
- print >> outfp, '
', header, '
'
- if hasitems:
- print >> outfp, '
'
- for item in items:
- if item:
- print >> outfp, '
', SPACE.join(item)
- print >> outfp, '
'
- else:
- for item in items:
- print >> outfp, SPACE.join(item), '
''' \
- % self.__d
-
- def get_corner_bgcolor(self):
- return 'white'
-
- def get_banner(self):
- return Banner.get_banner(self)
-
- def get_title(self):
- return self.__parser.get('title')
-
- def get_sidebar(self):
- return Sidebar.get_sidebar(self)
-
- def get_banner_attributes(self):
- return 'CELLSPACING=0 CELLPADDING=0'
-
- def get_body(self):
- if self.__body is None:
- self.__body = self.__parser.fp.read()
- return self.__body
-
- def get_lightshade(self):
- """Return lightest of 3 color scheme shade."""
- # The Mailman logo's foreground is approximately #da7074
- #return '#99997c'
- #return '#a39c82'
- #return '#caa08f'
- return '#eecfa1'
-
- def get_darkshade(self):
- """Return darkest of 3 color scheme shade."""
- #return '#545454'
- return '#36648b'
diff --git a/admin/www/Makefile b/admin/www/Makefile
deleted file mode 100644
index 12d16cde..00000000
--- a/admin/www/Makefile
+++ /dev/null
@@ -1,37 +0,0 @@
-HT2HTML = $(HOME)/projects/ht2html/ht2html.py
-
-HTSTYLE = MMGenerator
-HTALLFLAGS = -f -s $(HTSTYLE)
-HTROOT = .
-HTFLAGS = $(HTALLFLAGS) -r $(HTROOT)
-HTRELDIR = .
-# Use args for rsync like -a without the permission setting flag. I want to
-# keep the permissions set the way they are on the destination files, not on
-# my source files. Also add verbosity, compression, and ignoring CVS.
-RSYNC_ARGS = -rltgoDCvz
-
-SOURCES = $(shell echo *.ht)
-EXTRA_TARGETS = faq.html todo.html
-TARGETS = $(filter-out *.html,$(SOURCES:%.ht=%.html)) $(EXTRA_TARGETS)
-GENERATED_HTML= $(SOURCES:.ht=.html)
-
-.SUFFIXES: .ht .html
-.ht.html:
- $(HT2HTML) $(HTFLAGS) $(HTRELDIR)/$<
-
-all: $(TARGETS)
-
-faq.ht: ../../FAQ
- ../bin/faq2ht.py $< $@
-
-todo.ht: ../../TODO
- ../bin/mm2do $< $@
-
-install:
- -rsync $(RSYNC_ARGS) . www.list.org:mailman.list.org
- -rsync $(RSYNC_ARGS) . mailman.sf.net:mailman/htdocs
- -rsync $(RSYNC_ARGS) . $(HOME)/projects/mailman-gnu
-
-clean:
- -rm $(GENERATED_HTML)
- -rm faq.ht todo.ht
diff --git a/admin/www/admins.ht b/admin/www/admins.ht
deleted file mode 100644
index 6af1103e..00000000
--- a/admin/www/admins.ht
+++ /dev/null
@@ -1,17 +0,0 @@
-Title: List Manager Documentation
-Links: links.h doco-links.h
-
-
List Manager Documentation
-
-
Chris Kolar has made
-available list
-manager documentation for Mailman. This documentation has not been updated
-for 2.1 and thus is missing some of the admin options available in Mailman 2.1.
-
-
The GNU Mailman - List administrator's
-Manual by Terri Oda is available, but
-not yet complete. This is also available in
-PDF format (approx. 84k),
-PS format (approx. 121k),
-and
-plain text format (approx. 65k).
diff --git a/admin/www/admins.html b/admin/www/admins.html
deleted file mode 100644
index 2e342e2f..00000000
--- a/admin/www/admins.html
+++ /dev/null
@@ -1,198 +0,0 @@
-
-
-
-
-
-
-
-
-
Chris Kolar has made
-available list
-manager documentation for Mailman. This documentation has not been updated
-for 2.1 and thus is missing some of the admin options available in Mailman 2.1.
-
-
Although we are currently transitioning to
-Atlassian's the fine bug tracker called
-Jira, we are still accepting bugs via the Please use the SourceForge
-bug tracker.
-For now, if you have patches you'd like to submit, the best
-place to do that is on the SourceForge patch manager.
-
-
Be sure to select the right group for your bug or patch,
-e.g. Mailman 2.1. Failing to do so may cause your submission
-to get overlooked. It is also recommended that you email a note about
-your submission to the
-mailman-developers mailing list, but don't rely on just the email
-to get the attention of the Mailman developers.
-
-
Please see the Mailman security page for
-instructions on reporting security related issues.
diff --git a/admin/www/bugs.html b/admin/www/bugs.html
deleted file mode 100644
index ea32dbab..00000000
--- a/admin/www/bugs.html
+++ /dev/null
@@ -1,185 +0,0 @@
-
-
-
-
-
-
-
-
-
Although we are currently transitioning to
-Atlassian's the fine bug tracker called
-Jira, we are still accepting bugs via the Please use the SourceForge
-bug tracker.
-For now, if you have patches you'd like to submit, the best
-place to do that is on the SourceForge patch manager.
-
-
Be sure to select the right group for your bug or patch,
-e.g. Mailman 2.1. Failing to do so may cause your submission
-to get overlooked. It is also recommended that you email a note about
-your submission to the
-mailman-developers mailing list, but don't rely on just the email
-to get the attention of the Mailman developers.
-
-
Please see the Mailman security page for
-instructions on reporting security related issues.
-
-
-
-If you're the kind of person who loves to get elbow deep in code,
-there are lots of opportunities to dig into Mailman. You may want to
-find a project on our Mailman
-TODO list or on the
-Mailman
-design notes wiki. Because Wikis are intended to be
-collaborative, you're free to contribute to this page in true Wiki
-fashion. You will also definitely want to subscribe
-to the mailman-developers mailing list.
-
-
SourceForge Project Page
-
-Developers should start with the
-Mailman project at
-SourceForge. All patches and bugs should be submitted here so
-they won't get lost, although it is also requested that you inform the
-mailman-developers list about your submissions.
-
-
IRC
-
-Some of the Mailman developers also occasionally hang out on the
-mailman IRC channel at freenode.net, though attendance
-has been spotty lately.
-
-
-
-
Future plans
-
-Now that Mailman 2.1 has been released, I want to start thinking about
-what will be in Mailman
-3.0. I intend to use the wiki for most design artifacts, and the
-mailman-developers mailing list for most discussions. The items that
-are high on my list (which is by no means complete or definitive)
-include:
-
-
-
Consolidated user database -- A user should have just one
-account for every mailing list they are members of at a site, and they
-should be able to manage all their options through this account.
-It should be possible to integrate these databases with a site's
-existing user management system to reduce duplication of data and
-effort.
-
-
Unified template system -- Mailman has a somewhat fractured
-and inconvenient templating system, using both a homegrown HTML object
-model in Python and coarse templates filled in with data at rendering
-time. It can be near impossible to change the look and feel of the
-administration pages, and a small change to the u/i of other pages
-requires updates in all supported languages. I want to use a
-templating system like
-ZPT or
-Quixote.
-Actually, I plan to generalize the web interface so that many different
-templating systems could be used, although we'll pick one to ship by
-default.
-
-
A Real Database -- Mailman uses an inefficient persistency
-system based on Python pickles, and every mailing list has its own
-pickled state. This has several disadvantages, including poor
-scalability, difficulty in doing cross-mailing list operations, and
-the virtual host limitation on list names. Mailman 3.0 will use a
-real database, perhaps based on
-ZODB or
-BerkeleyDB. Again, the goal is
-to generalize the interface to the backend database so that others can
-be used, but choose one and ship it by default.
-
-
Component Architecture -- Zope3's
-component architecture provides some very nice organizational
-tools and software development methodologies. We'll be adopting many
-of these for Mailman 3.0, which will allow us to do the kinds of
-templating and database generalization described above.
-
-
-Stephan Richter has let an effort called
-ZMailman for integrating Zope and Mailman. I consider this a
-proof of concept of some of the ideas outlined above.
diff --git a/admin/www/devs.html b/admin/www/devs.html
deleted file mode 100644
index fb16c8b9..00000000
--- a/admin/www/devs.html
+++ /dev/null
@@ -1,219 +0,0 @@
-
-
-
-
-
-
-
-
-
-Mailman Developer Resources
-
-
-
-
-
-
-
-
-If you're the kind of person who loves to get elbow deep in code,
-there are lots of opportunities to dig into Mailman. You may want to
-find a project on our Mailman
-TODO list or on the
-Mailman
-design notes wiki. Because Wikis are intended to be
-collaborative, you're free to contribute to this page in true Wiki
-fashion. You will also definitely want to subscribe
-to the mailman-developers mailing list.
-
-
SourceForge Project Page
-
-Developers should start with the
-Mailman project at
-SourceForge. All patches and bugs should be submitted here so
-they won't get lost, although it is also requested that you inform the
-mailman-developers list about your submissions.
-
-
IRC
-
-Some of the Mailman developers also occasionally hang out on the
-mailman IRC channel at freenode.net, though attendance
-has been spotty lately.
-
-
-
-
Future plans
-
-Now that Mailman 2.1 has been released, I want to start thinking about
-what will be in Mailman
-3.0. I intend to use the wiki for most design artifacts, and the
-mailman-developers mailing list for most discussions. The items that
-are high on my list (which is by no means complete or definitive)
-include:
-
-
-
Consolidated user database -- A user should have just one
-account for every mailing list they are members of at a site, and they
-should be able to manage all their options through this account.
-It should be possible to integrate these databases with a site's
-existing user management system to reduce duplication of data and
-effort.
-
-
Unified template system -- Mailman has a somewhat fractured
-and inconvenient templating system, using both a homegrown HTML object
-model in Python and coarse templates filled in with data at rendering
-time. It can be near impossible to change the look and feel of the
-administration pages, and a small change to the u/i of other pages
-requires updates in all supported languages. I want to use a
-templating system like
-ZPT or
-Quixote.
-Actually, I plan to generalize the web interface so that many different
-templating systems could be used, although we'll pick one to ship by
-default.
-
-
A Real Database -- Mailman uses an inefficient persistency
-system based on Python pickles, and every mailing list has its own
-pickled state. This has several disadvantages, including poor
-scalability, difficulty in doing cross-mailing list operations, and
-the virtual host limitation on list names. Mailman 3.0 will use a
-real database, perhaps based on
-ZODB or
-BerkeleyDB. Again, the goal is
-to generalize the interface to the backend database so that others can
-be used, but choose one and ship it by default.
-
-
Component Architecture -- Zope3's
-component architecture provides some very nice organizational
-tools and software development methodologies. We'll be adopting many
-of these for Mailman 3.0, which will allow us to do the kinds of
-templating and database generalization described above.
-
-
-Stephan Richter has let an effort called
-ZMailman for integrating Zope and Mailman. I consider this a
-proof of concept of some of the ideas outlined above.
-
-
-
-On-line documentation for Mailman 2.1 is still under construction, but
-is organized among the following audiences:
-
-
-
Users -- anybody who is a member
- of a mailing list managed by Mailman. This documentation explains
- how you can subscribe and unsubscribe from mailing lists, how to
- change your personal options, and how to interact with other parts
- of the Mailman system.
-
-
List Managers -- anybody who
- is a list administrator or moderator for a mailing list. This
- documentation goes into all the gory details about how to set up
- your lists, what the various options mean and control, and how to
- manage the membership of your mailing list.
-
-
Site Administrators -- anybody
- who is installing and setting up a Mailman site. This documentation
- contains all the information about installing Mailman, integrating it with
- your mail and web servers, setting list defaults, configuring virtual
- domains, and enabling various options for your list administrators. This
- documentation also gives some hints on how to tune Mailman for optimal
- performance.
-
-
Translators -- anybody who is
- contributing to internationalization support for Mailman. This
- describes contact addresses for the current language champions and
- tells you what you need to do if you want to contribute a new
- language translation to the project (more are always welcome!).
-
-
-
Other Resources
-
-
The University of
-Washington has some very nice documentation on their installation of
-Mailman. It may be specific to UW's set up at times, but you might find it
-useful as a general help guide too.
-
-
The Frequently Asked Questions (FAQ) is
-available to answer the most common questions. See also the community
-driven Mailman
-FAQ Wizard. Feel free to add or correct entries in the FAQ Wizard
--- this is your resource for helping your colleagues. The password is
-Mailman (yes, we use the honor system here).
-
-
For issues not covered in the FAQ or documentation pages above,
-please check the
-archives
-of the Mailman-Users
-mailing list. If your question is not covered in the documentation,
-FAQ, or list archives, then you can send your questions to the
-mailman-users list. We suggest you
-subscribe to the
-list first - then submit your question - so that your question will be
-distributed quickly to the list subscribers and replies also will be
-distributed quickly back to you.
-
-
Chris Kolar has made
-available Mailman
-documentation, primarily for list owners who are not necessarily
-technical, but who own Mailman mailing lists.
-
-
The Mailman source distribution itself
-contains many README files for discussion of issues specific to
-operating system, mail transport agent, or web server.
diff --git a/admin/www/docs.html b/admin/www/docs.html
deleted file mode 100644
index 2daa73f2..00000000
--- a/admin/www/docs.html
+++ /dev/null
@@ -1,257 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-On-line documentation for Mailman 2.1 is still under construction, but
-is organized among the following audiences:
-
-
-
Users -- anybody who is a member
- of a mailing list managed by Mailman. This documentation explains
- how you can subscribe and unsubscribe from mailing lists, how to
- change your personal options, and how to interact with other parts
- of the Mailman system.
-
-
List Managers -- anybody who
- is a list administrator or moderator for a mailing list. This
- documentation goes into all the gory details about how to set up
- your lists, what the various options mean and control, and how to
- manage the membership of your mailing list.
-
-
Site Administrators -- anybody
- who is installing and setting up a Mailman site. This documentation
- contains all the information about installing Mailman, integrating it with
- your mail and web servers, setting list defaults, configuring virtual
- domains, and enabling various options for your list administrators. This
- documentation also gives some hints on how to tune Mailman for optimal
- performance.
-
-
Translators -- anybody who is
- contributing to internationalization support for Mailman. This
- describes contact addresses for the current language champions and
- tells you what you need to do if you want to contribute a new
- language translation to the project (more are always welcome!).
-
-
-
Other Resources
-
-
The University of
-Washington has some very nice documentation on their installation of
-Mailman. It may be specific to UW's set up at times, but you might find it
-useful as a general help guide too.
-
-
The Frequently Asked Questions (FAQ) is
-available to answer the most common questions. See also the community
-driven Mailman
-FAQ Wizard. Feel free to add or correct entries in the FAQ Wizard
--- this is your resource for helping your colleagues. The password is
-Mailman (yes, we use the honor system here).
-
-
For issues not covered in the FAQ or documentation pages above,
-please check the
-archives
-of the Mailman-Users
-mailing list. If your question is not covered in the documentation,
-FAQ, or list archives, then you can send your questions to the
-mailman-users list. We suggest you
-subscribe to the
-list first - then submit your question - so that your question will be
-distributed quickly to the list subscribers and replies also will be
-distributed quickly back to you.
-
-
Chris Kolar has made
-available Mailman
-documentation, primarily for list owners who are not necessarily
-technical, but who own Mailman mailing lists.
-
-
The Mailman source distribution itself
-contains many README files for discussion of issues specific to
-operating system, mail transport agent, or web server.
-
-
-
-Note: The tarball used to be available via ftp from www.list.org. With a
-recent (as of 13-Sep-2006) server move and subsequent bandwidth cap, we can no
-longer provide tarball downloads from list.org. Please use the SourceForge or
-GNU sites. Also note that the GNU ftp site may lag behind SourceForge,
-especially just after a release announcement. It often takes a little while
-for the GNU ftp site to catch up.
diff --git a/admin/www/download.html b/admin/www/download.html
deleted file mode 100644
index 5d07c8fa..00000000
--- a/admin/www/download.html
+++ /dev/null
@@ -1,198 +0,0 @@
-
-
-
-
-
-
-
-
-
-Downloading Mailman
-
-
-
-
-
-
-
-
-Note: The tarball used to be available via ftp from www.list.org. With a
-recent (as of 13-Sep-2006) server move and subsequent bandwidth cap, we can no
-longer provide tarball downloads from list.org. Please use the SourceForge or
-GNU sites. Also note that the GNU ftp site may lag behind SourceForge,
-especially just after a release announcement. It often takes a little while
-for the GNU ftp site to catch up.
-
-
-
-
-
diff --git a/admin/www/faq.ht b/admin/www/faq.ht
deleted file mode 100644
index 91f98dfa..00000000
--- a/admin/www/faq.ht
+++ /dev/null
@@ -1,296 +0,0 @@
-Title: Mailman Frequently Asked Questions
-
-See also the Mailman
-FAQ Wizard for more information.
-
-
Mailman Frequently Asked Questions
-
- Q. How do you spell this program?
-
- A. You spell it "Mailman", with a leading capital "M" and a lowercase
- second "m". It is incorrect to spell it "MailMan" (i.e. you should
- not use StudlyCaps).
-
Q. I'm getting really terrible performance for outgoing messages. It
- seems that if the MTA has trouble resolving DNS for any recipients,
- qrunner just gets really slow clearing the queue. Any ideas?
-
- A. What's likely happening is that your MTA is doing DNS resolution on
- recipients for messages delivered locally (i.e. from Mailman to
- your MTA via SMTPDirect.py). This is a Bad Thing. You need to
- turn off synchronous DNS resolution for messages originating from
- the local host.
-
In Exim, the value to edit is receiver_verify_hosts. See
- README.EXIM for details. Other MTAs have (of course) different
- parameters and defaults that control this. First check the README
- file for your MTA and then consult your MTA's own documentation.
-
Q. My list members are complaining about Mailman's List-* headers!
- What can I do about this?
-
- A. These headers are described in RFC 2369 and are added by Mailman
- for the long-term benefit of end-users. While discouraged, the
- list admin can disable these via the General Options page. See
- also README.USERAGENT for more information.
-
Q. Can I put the user's address in the footer that Mailman adds to
- each message?
-
- A. Yes, in Mailman 2.1. The site admin needs to enable personalization by
- setting the following variable in the mm_cfg.py file:
-
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
-
Once this is done, list admins can enable personalization for regular
- delivery members (digest deliveries can't be personalized currently). A
- personalized list can include the user's address in the footer.
-
Q. My users hate HTML in their email and for security reasons, I want
- to strip out all MIME attachments. How can I do this?
-
- A. Mailman 2.1 has this feature built-in. See the Content Filtering
- Options page in the admin interface.
-
Q. What if I get "document contains no data" from the web server, or
- mail isn't getting delivered, or I see "Premature end of script
- headers" or "Mailman CGI error!!!"
-
- A. The most likely cause of this is that the GID that is compiled into
- the C wrappers does not match the GID that your Web server invokes
- CGI scripts with. Note that a similar error could occur if your
- mail system invokes filter programs under a GID that does not match
- the one compiled into the C mail wrapper.
-
To fix this you will need to re-configure Mailman using the
- --with-cgi-gid and --with-mail-gid options. See the INSTALL file
- for details.
-
These errors are logged to syslog and they do not show up in the
- Mailman log files. Problems with the CGI wrapper do get reported
- in the web browser though (unless STEALTH_MODE is enabled), and
- include the expected GID, so that should help a lot.
-
You may want to have syslog running and configured to log the
- mail.error log class somewhere; on Solaris systems, the line
-
mail.debug /var/log/syslog
-
causes the messages to go to them in /var/log/syslog, for example.
- (The distributed syslog.conf forwards the message to the loghost,
- when present. See the syslog man page for more details.)
-
If your system is set like this, and you get a failure trying to
- visit the mailman/listinfo web page, and it's due to a UID or GID
- mismatch, then you should get an entry at the end of
- /var/log/syslog identifying the expected and received values.
-
If you are not getting any log messages in syslog, or in Mailman's
- own log files, but messages are still not being delivered, then it
- is likely that qrunner is not running (qrunner is the process that
- handles all mail in the system). In Mailman 2.0, qrunner was
- invoked from cron so make sure your crontab entries for the
- `mailman' user have been installed. In Mailman 2.1, qrunner is
- started with the bin/mailmanctl script, which can be invoked
- manually, or merged with your OS's init scripts.
-
Q. What should I check periodically?
-
- A. Many of the scripts have their standard error logged to
- $prefix/logs/error, and some of the modules write caught errors
- there, as well, so you should check there at least occasionally to
- look for bugs in the code and problems in your setup.
-
You may want to periodically check the other log files in the logs/
- directory, perhaps occasionally rotating them with something like
- the Linux logrotate script.
-
Q. I can't access the public archives. Why?
-
- A. If you are using Apache, you must make sure that FollowSymLinks is
- enabled for the path to the public archives. Note that the actual
- archives always reside in the private tree, and only when archives
- are public, is the symlink followed. See this archive message for
- more details:
-
Q. Still having problems? Running QMail?
-
- A. Make sure that you are using "preline" before calling the "mailman"
- wrapper:
-
|preline /home/mailman/mail/mailman post listname
-
"preline" adds a Unix-style "From " header which the archiver requires.
- You can fix the archive mbox files by adding:
-
From somebody Mon Oct 9 12:27:34 MDT 2000
-
before every message and re-running the archive command
- "bin/arch listname". The archives should now exist. See README.QMAIL
- for more information.
-
Q. Still having problems? Running on GNU/Linux?
-
- A. See the README.LINUX file.
-
Q. I want to get rid of some messages in my archive. How do I do
- this?
-
- A. David Rocher posts the following recipe:
-
Q. How secure are the authentication mechanisms used in Mailman's web
- interface?
-
- A. If your Mailman installation run on an SSL-enabled web server
- (i.e. you access the Mailman web pages with "https://..." URLs),
- you should be as safe as SSL itself is.
-
However, most Mailman installation run under standard,
- encryption-unaware servers. There's nothing wrong with that for
- most applications, but a sufficiently determined cracker *could*
- get unauthorized access by:
-
- Packet sniffing: The password used to do the initial
- authentication for any non-public Mailman page is sent as clear
- text over the net. If you consider this to be a big problem, you
- really should use an SSL-enabled server.
-
- Stealing a valid cookie: After successful password
- authentication, Mailman sends a "cookie" back to the user's
- browser. This cookie will be used for "automatic" authentication
- when browsing further within the list's protected pages. Mailman
- employs "session cookies" which are set until you quit your
- browser or explicitly log out.
-
Gaining access to the user's cookie (e.g. by being able to read
- the user's browser cookie database, or by means of packet
- sniffing, or maybe even by some broken browser offering all it's
- cookies to any and all sites the user accesses), and at the same
- time being able to fulfill the other criteria for using the
- cookie could result in unauthorized access.
-
Note that this problem is more easily exploited when users browse
- the web via proxies -- in that case, the cookie would be valid
- for any connections made through that proxy, and not just for
- connections made from the particular machine the user happens to
- be accessing the proxy from.
-
- Getting access to the user's terminal: This is really just
- another kind of cookie stealing. The short cookie expiration
- time is supposed to help defeat this problem. It can be
- considered the price to pay for the convenience of not having to
- type the password in every time.
-
Q. How do I rename a list?
-
- A. Renaming a list is currently a bit of a pain to do completely
- correctly, especially if you want to make sure that the old list
- contacts are automatically forwarded to the new list. This ought
- to be easier. :(
-
The biggest problem you have is how to stop mail and web traffic to
- your list during the transition, and what to do about any mail
- undelivered to the old list after the move. I don't think there
- are any foolproof steps, but here's how you can reduce the risk:
-
- Temporarily disable qrunner. To do this, you need to edit the
- user `mailman's crontab entry. Execute the following command,
- commenting out the qrunner line when you're dropped into your
- editor. Then save the file and quit the editor.
-
% crontab -u mailman -e
-
- Turn off your mail server. This is mostly harmless since remote
- MTAs will just keep retrying until you turn it back on, and it's
- not going to be off for very long.
-
- Next turn off your web server if possible. This of course means
- your entire site will be off-line while you make the switch and
- this may not be acceptable to you. The next best suggestion is
- to set up your permanent redirects now for the list you're
- moving. This means that anybody looking for the list under its
- old name will be redirected to the new name, but they'll get
- errors until you've completed the move.
-
Let's say the old name is "oldname" and the new name is
- "newname". Here are some Apache directives that will do the
- trick, though YMMV:
-
Add these to your httpd.conf file and restart Apache.
-
- Now cd to the directory where you've installed Mailman. Let's
- say it's /usr/local/mailman:
-
% cd /usr/local/mailman
-
and cd to the `lists' subdirectory:
-
% cd lists
-
You should now see the directory `oldname'. Move this to
- `newname':
-
% mv oldname newname
-
- Now cd to the private archives directory:
-
% cd ../archives/private
-
You will need to move the oldname's .mbox directory, and the
- .mbox file within that directory. Don't worry about the public
- archives; the next few steps will take care of them without
- requiring you to fiddle around in the file system:
-
- You now need to run the `bin/move_list' script to update some of
- the internal archiver paths. IMPORTANT: Skip this step if you
- are using Mailman 2.1!
-
% cd ../..
- % bin/move_list newname
-
- You should now regenerate the public archives:
-
% bin/arch newname
-
- You'll likely need to change some of your list's configuration
- options, especially if you want to accept postings addressed to
- the old list on the new list. Visit the admin interface for your
- new list:
-
o Go to the General options
-
o Change the "real_name" option to reflect the new list's name,
- e.g. "Newname"
-
o Change the subject prefix to reflect the new list's name,
- e.g. "[Newname] " (yes, that's a trailing space character).
-
o Optionally, update other configuration fields like info,
- description, or welcome_msg. YMMV.
-
o Save your changes
-
o Go to the Privacy options
-
o Add the old list's address to acceptable_aliases.
- E.g. "oldname@dom.ain". This way, (after the /etc/aliases
- changes described below) messages posted to the old list will
- not be held by the new list for "implicit destination"
- approval.
-
o Save your changes
-
- Now you want to update your /etc/aliases file to include the
- aliases for the new list, and forwards for the old list to the
- new list. Note that these instructions are for Sendmail style
- alias files, adjust to the specifics of how your MTA is set up.
-
o Find the lines defining the aliases for your old list's name
-
o Copy and paste them just below the originals.
-
o Change all the references of "oldname" to "newname" in the
- pasted stanza.
-
o Now change the targets of the original aliases to forward to
- the new aliases. When you're done, you will end up with
- /etc/aliases entries like the following (YMMV):
-
XXX This needs updating for MM2.1!
-
# Forward the oldname list to the newname list
- oldname: newname@dom.ain
- oldname-request: newname-request@dom.ain
- oldname-admin: newname-admin@dom.ain
- oldname-owner: newname-owner@dom.ain
-
- Before you restart everything, you want to make one last check.
- You're looking for files in the qfiles/ directory that may have
- been addressed to the old list but weren't delivered before you
- renamed the list. Do something like the following:
-
% cd /usr/local/mailman/qfiles
- % grep oldname *.msg
-
If you get no hits, skip to the next step, you've got nothing to
- worry about.
-
If you did get hits, then things get complicated. I warn you
- that the rest of this step is untested. :(
-
For each of the .msg files that were destined for the old list,
- you need to change the corresponding .db file. Unfortunately
- there's no easy way to do this. Anyway...
-
Save the following Python code in a file called 'hackdb.py':
-
again and this time uncommenting the qrunner line. Save the file
- and quit your editor.
-
- Rejoice, you're done. Send $100,000 in shiny new pennies to the
- Mailman cabal as your downpayment toward making this easier for
- the next list you have to rename. :)
-
\ No newline at end of file
diff --git a/admin/www/faq.html b/admin/www/faq.html
deleted file mode 100644
index 592447c1..00000000
--- a/admin/www/faq.html
+++ /dev/null
@@ -1,458 +0,0 @@
-
-
-
-
-
-
-
-
-
-
- Q. How do you spell this program?
-
- A. You spell it "Mailman", with a leading capital "M" and a lowercase
- second "m". It is incorrect to spell it "MailMan" (i.e. you should
- not use StudlyCaps).
-
Q. I'm getting really terrible performance for outgoing messages. It
- seems that if the MTA has trouble resolving DNS for any recipients,
- qrunner just gets really slow clearing the queue. Any ideas?
-
- A. What's likely happening is that your MTA is doing DNS resolution on
- recipients for messages delivered locally (i.e. from Mailman to
- your MTA via SMTPDirect.py). This is a Bad Thing. You need to
- turn off synchronous DNS resolution for messages originating from
- the local host.
-
In Exim, the value to edit is receiver_verify_hosts. See
- README.EXIM for details. Other MTAs have (of course) different
- parameters and defaults that control this. First check the README
- file for your MTA and then consult your MTA's own documentation.
-
Q. My list members are complaining about Mailman's List-* headers!
- What can I do about this?
-
- A. These headers are described in RFC 2369 and are added by Mailman
- for the long-term benefit of end-users. While discouraged, the
- list admin can disable these via the General Options page. See
- also README.USERAGENT for more information.
-
Q. Can I put the user's address in the footer that Mailman adds to
- each message?
-
- A. Yes, in Mailman 2.1. The site admin needs to enable personalization by
- setting the following variable in the mm_cfg.py file:
-
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
-
Once this is done, list admins can enable personalization for regular
- delivery members (digest deliveries can't be personalized currently). A
- personalized list can include the user's address in the footer.
-
Q. My users hate HTML in their email and for security reasons, I want
- to strip out all MIME attachments. How can I do this?
-
- A. Mailman 2.1 has this feature built-in. See the Content Filtering
- Options page in the admin interface.
-
Q. What if I get "document contains no data" from the web server, or
- mail isn't getting delivered, or I see "Premature end of script
- headers" or "Mailman CGI error!!!"
-
- A. The most likely cause of this is that the GID that is compiled into
- the C wrappers does not match the GID that your Web server invokes
- CGI scripts with. Note that a similar error could occur if your
- mail system invokes filter programs under a GID that does not match
- the one compiled into the C mail wrapper.
-
To fix this you will need to re-configure Mailman using the
- --with-cgi-gid and --with-mail-gid options. See the INSTALL file
- for details.
-
These errors are logged to syslog and they do not show up in the
- Mailman log files. Problems with the CGI wrapper do get reported
- in the web browser though (unless STEALTH_MODE is enabled), and
- include the expected GID, so that should help a lot.
-
You may want to have syslog running and configured to log the
- mail.error log class somewhere; on Solaris systems, the line
-
mail.debug /var/log/syslog
-
causes the messages to go to them in /var/log/syslog, for example.
- (The distributed syslog.conf forwards the message to the loghost,
- when present. See the syslog man page for more details.)
-
If your system is set like this, and you get a failure trying to
- visit the mailman/listinfo web page, and it's due to a UID or GID
- mismatch, then you should get an entry at the end of
- /var/log/syslog identifying the expected and received values.
-
If you are not getting any log messages in syslog, or in Mailman's
- own log files, but messages are still not being delivered, then it
- is likely that qrunner is not running (qrunner is the process that
- handles all mail in the system). In Mailman 2.0, qrunner was
- invoked from cron so make sure your crontab entries for the
- `mailman' user have been installed. In Mailman 2.1, qrunner is
- started with the bin/mailmanctl script, which can be invoked
- manually, or merged with your OS's init scripts.
-
Q. What should I check periodically?
-
- A. Many of the scripts have their standard error logged to
- $prefix/logs/error, and some of the modules write caught errors
- there, as well, so you should check there at least occasionally to
- look for bugs in the code and problems in your setup.
-
You may want to periodically check the other log files in the logs/
- directory, perhaps occasionally rotating them with something like
- the Linux logrotate script.
-
Q. I can't access the public archives. Why?
-
- A. If you are using Apache, you must make sure that FollowSymLinks is
- enabled for the path to the public archives. Note that the actual
- archives always reside in the private tree, and only when archives
- are public, is the symlink followed. See this archive message for
- more details:
-
Q. Still having problems? Running QMail?
-
- A. Make sure that you are using "preline" before calling the "mailman"
- wrapper:
-
|preline /home/mailman/mail/mailman post listname
-
"preline" adds a Unix-style "From " header which the archiver requires.
- You can fix the archive mbox files by adding:
-
From somebody Mon Oct 9 12:27:34 MDT 2000
-
before every message and re-running the archive command
- "bin/arch listname". The archives should now exist. See README.QMAIL
- for more information.
-
Q. Still having problems? Running on GNU/Linux?
-
- A. See the README.LINUX file.
-
Q. I want to get rid of some messages in my archive. How do I do
- this?
-
- A. David Rocher posts the following recipe:
-
Q. How secure are the authentication mechanisms used in Mailman's web
- interface?
-
- A. If your Mailman installation run on an SSL-enabled web server
- (i.e. you access the Mailman web pages with "https://..." URLs),
- you should be as safe as SSL itself is.
-
However, most Mailman installation run under standard,
- encryption-unaware servers. There's nothing wrong with that for
- most applications, but a sufficiently determined cracker *could*
- get unauthorized access by:
-
- Packet sniffing: The password used to do the initial
- authentication for any non-public Mailman page is sent as clear
- text over the net. If you consider this to be a big problem, you
- really should use an SSL-enabled server.
-
- Stealing a valid cookie: After successful password
- authentication, Mailman sends a "cookie" back to the user's
- browser. This cookie will be used for "automatic" authentication
- when browsing further within the list's protected pages. Mailman
- employs "session cookies" which are set until you quit your
- browser or explicitly log out.
-
Gaining access to the user's cookie (e.g. by being able to read
- the user's browser cookie database, or by means of packet
- sniffing, or maybe even by some broken browser offering all it's
- cookies to any and all sites the user accesses), and at the same
- time being able to fulfill the other criteria for using the
- cookie could result in unauthorized access.
-
Note that this problem is more easily exploited when users browse
- the web via proxies -- in that case, the cookie would be valid
- for any connections made through that proxy, and not just for
- connections made from the particular machine the user happens to
- be accessing the proxy from.
-
- Getting access to the user's terminal: This is really just
- another kind of cookie stealing. The short cookie expiration
- time is supposed to help defeat this problem. It can be
- considered the price to pay for the convenience of not having to
- type the password in every time.
-
Q. How do I rename a list?
-
- A. Renaming a list is currently a bit of a pain to do completely
- correctly, especially if you want to make sure that the old list
- contacts are automatically forwarded to the new list. This ought
- to be easier. :(
-
The biggest problem you have is how to stop mail and web traffic to
- your list during the transition, and what to do about any mail
- undelivered to the old list after the move. I don't think there
- are any foolproof steps, but here's how you can reduce the risk:
-
- Temporarily disable qrunner. To do this, you need to edit the
- user `mailman's crontab entry. Execute the following command,
- commenting out the qrunner line when you're dropped into your
- editor. Then save the file and quit the editor.
-
% crontab -u mailman -e
-
- Turn off your mail server. This is mostly harmless since remote
- MTAs will just keep retrying until you turn it back on, and it's
- not going to be off for very long.
-
- Next turn off your web server if possible. This of course means
- your entire site will be off-line while you make the switch and
- this may not be acceptable to you. The next best suggestion is
- to set up your permanent redirects now for the list you're
- moving. This means that anybody looking for the list under its
- old name will be redirected to the new name, but they'll get
- errors until you've completed the move.
-
Let's say the old name is "oldname" and the new name is
- "newname". Here are some Apache directives that will do the
- trick, though YMMV:
-
Add these to your httpd.conf file and restart Apache.
-
- Now cd to the directory where you've installed Mailman. Let's
- say it's /usr/local/mailman:
-
% cd /usr/local/mailman
-
and cd to the `lists' subdirectory:
-
% cd lists
-
You should now see the directory `oldname'. Move this to
- `newname':
-
% mv oldname newname
-
- Now cd to the private archives directory:
-
% cd ../archives/private
-
You will need to move the oldname's .mbox directory, and the
- .mbox file within that directory. Don't worry about the public
- archives; the next few steps will take care of them without
- requiring you to fiddle around in the file system:
-
- You now need to run the `bin/move_list' script to update some of
- the internal archiver paths. IMPORTANT: Skip this step if you
- are using Mailman 2.1!
-
% cd ../..
- % bin/move_list newname
-
- You should now regenerate the public archives:
-
% bin/arch newname
-
- You'll likely need to change some of your list's configuration
- options, especially if you want to accept postings addressed to
- the old list on the new list. Visit the admin interface for your
- new list:
-
o Go to the General options
-
o Change the "real_name" option to reflect the new list's name,
- e.g. "Newname"
-
o Change the subject prefix to reflect the new list's name,
- e.g. "[Newname] " (yes, that's a trailing space character).
-
o Optionally, update other configuration fields like info,
- description, or welcome_msg. YMMV.
-
o Save your changes
-
o Go to the Privacy options
-
o Add the old list's address to acceptable_aliases.
- E.g. "oldname@dom.ain". This way, (after the /etc/aliases
- changes described below) messages posted to the old list will
- not be held by the new list for "implicit destination"
- approval.
-
o Save your changes
-
- Now you want to update your /etc/aliases file to include the
- aliases for the new list, and forwards for the old list to the
- new list. Note that these instructions are for Sendmail style
- alias files, adjust to the specifics of how your MTA is set up.
-
o Find the lines defining the aliases for your old list's name
-
o Copy and paste them just below the originals.
-
o Change all the references of "oldname" to "newname" in the
- pasted stanza.
-
o Now change the targets of the original aliases to forward to
- the new aliases. When you're done, you will end up with
- /etc/aliases entries like the following (YMMV):
-
XXX This needs updating for MM2.1!
-
# Forward the oldname list to the newname list
- oldname: newname@dom.ain
- oldname-request: newname-request@dom.ain
- oldname-admin: newname-admin@dom.ain
- oldname-owner: newname-owner@dom.ain
-
- Before you restart everything, you want to make one last check.
- You're looking for files in the qfiles/ directory that may have
- been addressed to the old list but weren't delivered before you
- renamed the list. Do something like the following:
-
% cd /usr/local/mailman/qfiles
- % grep oldname *.msg
-
If you get no hits, skip to the next step, you've got nothing to
- worry about.
-
If you did get hits, then things get complicated. I warn you
- that the rest of this step is untested. :(
-
For each of the .msg files that were destined for the old list,
- you need to change the corresponding .db file. Unfortunately
- there's no easy way to do this. Anyway...
-
Save the following Python code in a file called 'hackdb.py':
-
again and this time uncommenting the qrunner line. Save the file
- and quit your editor.
-
- Rejoice, you're done. Send $100,000 in shiny new pennies to the
- Mailman cabal as your downpayment toward making this easier for
- the next list you have to rename. :)
-
-
-Here's a brief description of the features in Mailman 2.1
-The
-NEWS
-file contains a detailed summary of all new features.
-
-
-
Through-the-web list creation and removal (with automatic
- support depending on the MTA)
-
Multi-lingual support: list web pages and email notices can be in
- any of nearly two dozen supported language, configurable
- per-site, per-list, and per-user
-
"Real name" support for members
-
Much better password-less operation for simple user tasks.
-
Support for personalized deliveries and
- VERP-like message
- delivery for foolproof bounce detection
-
Emergency moderation
-
MIME-based content filtering, with demime/stripmime like options
-
Regular expression based topic filtering
-
Better membership management, including searching
-
Re-organized administrative requests pages
-
Moderated newsgroup support
-
A new architecture for the mail delivery subsystem, removing
- the dependence on cron, for better responsiveness and
- scalability
-
New moderation and privacy controls
-
Invitations
-
Autoresponse governors
-
Users can now change some of their delivery options globally,
- for all lists at a site, including their password, delivery
- status, real name, etc.
-
Much better MIME and I18n support in the archiver
-
A separate "list moderator" role has been added
-
Urgent: header support (bypasses digests to reach all users
- immediately).
-
-
-Here is a short summary of other features in Mailman. For details,
-please see the on-line documentation.
-
-
-
Web based list administration for nearly all tasks, including list
- configuration, moderation (post approvals), management of user
- accounts.
-
Web based subscribing and unsubscribing, and user configuration
- management. Users can temporarily disable their accounts, select
- digest modes, hide their email addresses from other members, etc.
-
A customizable home page for each mailing list.
-
Per-list privacy features, such as closed-subscriptions, private
- archives, private membership rosters, and sender-based posting
- rules.
-
Configurable (per-list and per-user) delivery mode
-
Integrated bounce detection within an extensible framework.
- Automatic disposition of bouncing addresses (disable,
- unsubscribe).
-
Integrated spam filters
-
Built-in web-based archiving, with hooks for external archivers such as
- MHonArc.
-
Integrated Usenet gatewaying.
-
Integrated auto-replies.
-
Majordomo-style email based commands.
-
Multiple list owners and moderators are possible.
-
Support for virtual domains.
-
Runs on GNU/Linux and most Un*x-like systems, compatible with most
- web servers and browsers, and most SMTP servers. Requires Python
- 2.1.3 or newer.
-
An extensible mail delivery pipeline.
-
High-performance mail delivery, with a scalable architecture.
-
-
-Here's a brief description of the features in Mailman 2.1
-The
-NEWS
-file contains a detailed summary of all new features.
-
-
-
Through-the-web list creation and removal (with automatic
- support depending on the MTA)
-
Multi-lingual support: list web pages and email notices can be in
- any of nearly two dozen supported language, configurable
- per-site, per-list, and per-user
-
"Real name" support for members
-
Much better password-less operation for simple user tasks.
-
Support for personalized deliveries and
- VERP-like message
- delivery for foolproof bounce detection
-
Emergency moderation
-
MIME-based content filtering, with demime/stripmime like options
-
Regular expression based topic filtering
-
Better membership management, including searching
-
Re-organized administrative requests pages
-
Moderated newsgroup support
-
A new architecture for the mail delivery subsystem, removing
- the dependence on cron, for better responsiveness and
- scalability
-
New moderation and privacy controls
-
Invitations
-
Autoresponse governors
-
Users can now change some of their delivery options globally,
- for all lists at a site, including their password, delivery
- status, real name, etc.
-
Much better MIME and I18n support in the archiver
-
A separate "list moderator" role has been added
-
Urgent: header support (bypasses digests to reach all users
- immediately).
-
-
-Here is a short summary of other features in Mailman. For details,
-please see the on-line documentation.
-
-
-
Web based list administration for nearly all tasks, including list
- configuration, moderation (post approvals), management of user
- accounts.
-
Web based subscribing and unsubscribing, and user configuration
- management. Users can temporarily disable their accounts, select
- digest modes, hide their email addresses from other members, etc.
-
A customizable home page for each mailing list.
-
Per-list privacy features, such as closed-subscriptions, private
- archives, private membership rosters, and sender-based posting
- rules.
-
Configurable (per-list and per-user) delivery mode
-
Integrated bounce detection within an extensible framework.
- Automatic disposition of bouncing addresses (disable,
- unsubscribe).
-
Integrated spam filters
-
Built-in web-based archiving, with hooks for external archivers such as
- MHonArc.
-
Integrated Usenet gatewaying.
-
Integrated auto-replies.
-
Majordomo-style email based commands.
-
Multiple list owners and moderators are possible.
-
Support for virtual domains.
-
Runs on GNU/Linux and most Un*x-like systems, compatible with most
- web servers and browsers, and most SMTP servers. Requires Python
- 2.1.3 or newer.
-
An extensible mail delivery pipeline.
-
High-performance mail delivery, with a scalable architecture.
-
-
-There are many resources available for those who need help with
-Mailman, beyond the on-line documentation. If
-you are having problems installing or configuring Mailman, or if you
-have questions about what Mailman can do, you should probably start
-with the FAQ, and the community driven
-FAQ Wizard.
-
-
You should also check out the community driven
-wiki, which hold the most up-to-date
-information about Mailman.
-
-
Beyond those reosurces, please use the discussion
-lists for asking questions. There are lots of very helpful and
-knowledgeable people on the lists who can help. Probably the most
-helpful will be the
-mailman-users mailing list.
diff --git a/admin/www/help.html b/admin/www/help.html
deleted file mode 100644
index 49386308..00000000
--- a/admin/www/help.html
+++ /dev/null
@@ -1,188 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-There are many resources available for those who need help with
-Mailman, beyond the on-line documentation. If
-you are having problems installing or configuring Mailman, or if you
-have questions about what Mailman can do, you should probably start
-with the FAQ, and the community driven
-FAQ Wizard.
-
-
You should also check out the community driven
-wiki, which hold the most up-to-date
-information about Mailman.
-
-
Beyond those reosurces, please use the discussion
-lists for asking questions. There are lots of very helpful and
-knowledgeable people on the lists who can help. Probably the most
-helpful will be the
-mailman-users mailing list.
-
-
-
-Mailman 2.1 is fully internationalized. This means you can add
-translations of all the email and web templates so that your users can
-interact with your mailing lists in their native language.
-Internationalization is handled as follows:
-
-
-
Each Mailman installation has a server default language.
- Mailman ships with US English as the server default.
-
-
Mailman comes with many supported languages, and if your
- language is on that list, it will just work.
-
-
Individual list owners can choose which languages they'd
- like their mailing list to support from the suite of site-enabled
- languages. The list owner can also select the list's default
- language. Mailing lists can thus be monolingual (with English or
- any other installed language as the default), or they can be
- multilingual.
-
-
Individual users can choose what their preferred language
- is, from the set of list-enabled languages. Thus, if a list is
- multilingual, the user can choose which language they'd prefer
- when interacting with Mailman.
-
-
-It must be noted that Mailman never actually translates the messages
-that flow through its mailing lists. It's up to the list members to
-adhere to their community's language conventions.
-
-
Mailman Language Champions
-
-Each language translation has a champion who coordinates updates and
-submits them to the Mailman project. If the language you are
-interested is listed here, please contact the champion for details.
-If your language is not listed here, or if you have general questions
-about I18N Mailman, please contact the
-mailman-i18n@python.org mailing list.
-
-
We are investigating using the
-Translation
-Project for future language support.
-
-
Supported. See also the
- Japanized Mailman Page
- and also the mailing list for Japanese Mailman users, for which
- the archives
- are publically available.
-
-Mailman 2.1 is fully internationalized. This means you can add
-translations of all the email and web templates so that your users can
-interact with your mailing lists in their native language.
-Internationalization is handled as follows:
-
-
-
Each Mailman installation has a server default language.
- Mailman ships with US English as the server default.
-
-
Mailman comes with many supported languages, and if your
- language is on that list, it will just work.
-
-
Individual list owners can choose which languages they'd
- like their mailing list to support from the suite of site-enabled
- languages. The list owner can also select the list's default
- language. Mailing lists can thus be monolingual (with English or
- any other installed language as the default), or they can be
- multilingual.
-
-
Individual users can choose what their preferred language
- is, from the set of list-enabled languages. Thus, if a list is
- multilingual, the user can choose which language they'd prefer
- when interacting with Mailman.
-
-
-It must be noted that Mailman never actually translates the messages
-that flow through its mailing lists. It's up to the list members to
-adhere to their community's language conventions.
-
-
Mailman Language Champions
-
-Each language translation has a champion who coordinates updates and
-submits them to the Mailman project. If the language you are
-interested is listed here, please contact the champion for details.
-If your language is not listed here, or if you have general questions
-about I18N Mailman, please contact the
-mailman-i18n@python.org mailing list.
-
-
We are investigating using the
-Translation
-Project for future language support.
-
-
Supported. See also the
- Japanized Mailman Page
- and also the mailing list for Japanese Mailman users, for which
- the archives
- are publically available.
-
-Mailman is free software for managing electronic mail discussion and
-e-newsletter lists. Mailman is integrated with the web, making it
-easy for users to manage their accounts and for list owners to
-administer their lists. Mailman supports built-in archiving,
-automatic bounce processing, content filtering, digest delivery, spam
-filters, and more. See the features page
-for details.
-
-
Mailman is free software, distributed under the
-GNU General Public
-License. Mailman is written in the
-Python
-programming language, with a little bit of C code for security.
-
-
The name of this software is spelled Mailman
-with a capital leading M and a lowercase second m.
-It is incorrect to spell it "MailMan".
-
-
See the Security page for important security
-related information, including critical patches and contact information for
-reporting suspected security vulnerabilities. Also see the
-Mailman Wiki for the latest information
-about stable and development versions.
-
-
Current Version
-
-The current stable GNU Mailman version is
-2.1.9,
-released on
-12-Sep-2006.
-
-
Acknowledgements
-
-
Mailman's lead developer is
-Barry Warsaw who can be contacted
-barry at python dot org. Mark Sapiro and Tokio Kikuchi are also core
-Mailman developers.
-
-Thanks go out to
-Atlassian for their generous
-hosting of the wiki and
-bug tracker.
Thanks also go to
-Control.com for their
-sponsorship of new Mailman 2.1 features, and
-Zope Corporation for their past support,
- as well as the
-list of contributors, bug hunters, big idea people, and others
-who have helped immensely with Mailman's development.
diff --git a/admin/www/index.html b/admin/www/index.html
deleted file mode 100644
index 111602b8..00000000
--- a/admin/www/index.html
+++ /dev/null
@@ -1,218 +0,0 @@
-
-
-
-
-
-
-
-
-
-Mailman, the GNU Mailing List Manager
-
-
-
-
-
-
-
-
-Mailman is free software for managing electronic mail discussion and
-e-newsletter lists. Mailman is integrated with the web, making it
-easy for users to manage their accounts and for list owners to
-administer their lists. Mailman supports built-in archiving,
-automatic bounce processing, content filtering, digest delivery, spam
-filters, and more. See the features page
-for details.
-
-
Mailman is free software, distributed under the
-GNU General Public
-License. Mailman is written in the
-Python
-programming language, with a little bit of C code for security.
-
-
The name of this software is spelled Mailman
-with a capital leading M and a lowercase second m.
-It is incorrect to spell it "MailMan".
-
-
See the Security page for important security
-related information, including critical patches and contact information for
-reporting suspected security vulnerabilities. Also see the
-Mailman Wiki for the latest information
-about stable and development versions.
-
-
Current Version
-
-The current stable GNU Mailman version is
-2.1.9,
-released on
-12-Sep-2006.
-
-
Acknowledgements
-
-
Mailman's lead developer is
-Barry Warsaw who can be contacted
-barry at python dot org. Mark Sapiro and Tokio Kikuchi are also core
-Mailman developers.
-
-Thanks go out to
-Atlassian for their generous
-hosting of the wiki and
-bug tracker.
Thanks also go to
-Control.com for their
-sponsorship of new Mailman 2.1 features, and
-Zope Corporation for their past support,
- as well as the
-list of contributors, bug hunters, big idea people, and others
-who have helped immensely with Mailman's development.
-
-
-
-Jamie Zawinski posted an article in 2002 titled Mailman Considered
-Harmful. I know Jamie and respect him, but I respectfully
-disagree with his assessment. You'd be worried if I didn't, eh?
-
-
To give Jamie the benefit of the doubt, I believe he was reviewing
-older versions of the Mailman software, where some of his complaints
-may have been appropriate. Here is a rebuttal to his
-article, based on
-the
-latest stable release of Mailman 2.1, unless otherwise specified.
-
-
Mailman is a pain in the ass for the end user.
-
-Jamie must have reviewed a pre-2.0 version, because Mailman releases
-since 2.0 have implemented the "sane" recipe. Indeed it would be
-insane not to. I may be mad, but I'm not insane. In fact, in Mailman
-2.1, there are several ways to get unsubscribed, any one of which will
-work just fine:
-
-
-
Send a message to list-leave or list-unsubscribe and
- reply to the confirmation message. It doesn't matter at all what
- is in your original message.
-
Mail "unsubscribe" to the list-request address and
- reply to the confirmation message.
-
Use a mail reader that understands the standard
- RFC 2369
- List-Unsubscribe header, then just click on that header and
- reply to the confirmation message.
-
Visit your user's options page, click on the
- Unsubscribe button and reply to the confirmation message.
- Note that with Mailman 2.1, mailing lists can be personalized,
- which means the url to your options page can be included in
- the footer of every message you get from the list (digests
- currently excluded).
-
-
-What could be simpler?
-
-
Mailman's password mechanism provides zero security.
-
-I disagree with Jamie about the utility of Mailman's passwords because
-in general they do prevent malicious people from changing your
-subscription options out from under you. But I will also concede that
-he has a point about password management by naive users, so you should
-know that it is trivial to disable monthly password reminders, either
-on a list-wide basis or on a per-user basis.
-
-
Monthly password reminders serve additional purposes though: they
-remind you of lists you are on which you may have forgotten about,
-they remind you about how to get unsubscribed from such lists, and
-they offer an opportunity for lists to cull their membership of
-non-functioning addresses. In Mailman 2.1, the monthly reminders can
-be sent out with VERP-like envelopes, Mailman
-can unambiguously parse any bounces from dead addresses, and can use
-this information to automatically disable or delete disappeared
-members.
-
-
When you subscribe to a mailing list, the password is completely
-optional -- omit it and Mailman generates a random one for you. You
-generally don't need to know your password except if you want to
-change your delivery options, e.g. to temporarily disable delivery
-while you're on vacation, or to switch to digest delivery, subscribe
-to topics, etc. For simple membership management (subscribing and
-unsubscribing), you never need to know it. The user options
-are useful.
-
-
Web-based subscriptions
-
-If all you care about is web-based subscriptions, then yes it's pretty
-easy to set up a simple CGI to do this. It's just as easy to do with
-Mailman as any other mailing list software. Note though, that
-Mailman's web interface is much more sophisticated because you can do
-nearly all the list configuration through the web. Okay, this is of
-primary benefit for list owners rather than list members, and Jamie's
-rant is focused on the member experience. Note though, that Mailman's
-subscription page also gives the user the option of selecting a
-default language (for multilingual lists) and their preferred delivery
-mechanism (digests or regular delivery).
diff --git a/admin/www/jwzrebuttal.html b/admin/www/jwzrebuttal.html
deleted file mode 100644
index a109b320..00000000
--- a/admin/www/jwzrebuttal.html
+++ /dev/null
@@ -1,255 +0,0 @@
-
-
-
-
-
-
-
-
-
-Mailman Considered Beneficial
-
-
-
-
-
-
-
-
-Jamie Zawinski posted an article in 2002 titled Mailman Considered
-Harmful. I know Jamie and respect him, but I respectfully
-disagree with his assessment. You'd be worried if I didn't, eh?
-
-
To give Jamie the benefit of the doubt, I believe he was reviewing
-older versions of the Mailman software, where some of his complaints
-may have been appropriate. Here is a rebuttal to his
-article, based on
-the
-latest stable release of Mailman 2.1, unless otherwise specified.
-
-
Mailman is a pain in the ass for the end user.
-
-Jamie must have reviewed a pre-2.0 version, because Mailman releases
-since 2.0 have implemented the "sane" recipe. Indeed it would be
-insane not to. I may be mad, but I'm not insane. In fact, in Mailman
-2.1, there are several ways to get unsubscribed, any one of which will
-work just fine:
-
-
-
Send a message to list-leave or list-unsubscribe and
- reply to the confirmation message. It doesn't matter at all what
- is in your original message.
-
Mail "unsubscribe" to the list-request address and
- reply to the confirmation message.
-
Use a mail reader that understands the standard
- RFC 2369
- List-Unsubscribe header, then just click on that header and
- reply to the confirmation message.
-
Visit your user's options page, click on the
- Unsubscribe button and reply to the confirmation message.
- Note that with Mailman 2.1, mailing lists can be personalized,
- which means the url to your options page can be included in
- the footer of every message you get from the list (digests
- currently excluded).
-
-
-What could be simpler?
-
-
Mailman's password mechanism provides zero security.
-
-I disagree with Jamie about the utility of Mailman's passwords because
-in general they do prevent malicious people from changing your
-subscription options out from under you. But I will also concede that
-he has a point about password management by naive users, so you should
-know that it is trivial to disable monthly password reminders, either
-on a list-wide basis or on a per-user basis.
-
-
Monthly password reminders serve additional purposes though: they
-remind you of lists you are on which you may have forgotten about,
-they remind you about how to get unsubscribed from such lists, and
-they offer an opportunity for lists to cull their membership of
-non-functioning addresses. In Mailman 2.1, the monthly reminders can
-be sent out with VERP-like envelopes, Mailman
-can unambiguously parse any bounces from dead addresses, and can use
-this information to automatically disable or delete disappeared
-members.
-
-
When you subscribe to a mailing list, the password is completely
-optional -- omit it and Mailman generates a random one for you. You
-generally don't need to know your password except if you want to
-change your delivery options, e.g. to temporarily disable delivery
-while you're on vacation, or to switch to digest delivery, subscribe
-to topics, etc. For simple membership management (subscribing and
-unsubscribing), you never need to know it. The user options
-are useful.
-
-
Web-based subscriptions
-
-If all you care about is web-based subscriptions, then yes it's pretty
-easy to set up a simple CGI to do this. It's just as easy to do with
-Mailman as any other mailing list software. Note though, that
-Mailman's web interface is much more sophisticated because you can do
-nearly all the list configuration through the web. Okay, this is of
-primary benefit for list owners rather than list members, and Jamie's
-rant is focused on the member experience. Note though, that Mailman's
-subscription page also gives the user the option of selecting a
-default language (for multilingual lists) and their preferred delivery
-mechanism (digests or regular delivery).
-
-
-
-We have several mailing lists devoted to Mailman, which also provide a
-nice demonstration of Mailman!
-
-
-
- Mailman Users is the mailing list to subscribe to if you are
- using Mailman at your site, and may have problems or questions
- relating to installation, use, etc. We'll try to keep the deep
- technical discussions off this list.
- (archives)
-
-
- Mailman Announce is a read-only list that you can subscribe to
- if you are only interested in release notices and other important
- news. Only the core Mailman developers can post messages to this
- list.
- (archives)
-
-
- Mailman Developers is the mailing list to use if you are
- interested in helping us develop Mailman, discuss future
- directions, etc. This is the list for more in-depth technical
- issues.
- (archives)
-
-
More information about developer resources is available
- here.
-
-
- Mailman Internationalization is the list for discussing the
- multi-lingual support in Mailman 2.1. Everyone who is working on
- translations of Mailman should subscribe to this mailing list.
- (archives)
-
-
- Mailman Checkins is an adjunct list to the publically
- accessible read-only CVS repository. This list is for the
- hardcore developers, or anybody else submitting patches, since we
- really prefer such patches to be generated against the latest
- snapshot. This is a read-only list; only the core Mailman
- developers can post messages to this list. There is no archive.
-
-
-
Please note that as of 10-Jul-2005, it appears that the listowner.org
-site is no longer available.
diff --git a/admin/www/lists.html b/admin/www/lists.html
deleted file mode 100644
index 6d4bd517..00000000
--- a/admin/www/lists.html
+++ /dev/null
@@ -1,212 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-We have several mailing lists devoted to Mailman, which also provide a
-nice demonstration of Mailman!
-
-
-
- Mailman Users is the mailing list to subscribe to if you are
- using Mailman at your site, and may have problems or questions
- relating to installation, use, etc. We'll try to keep the deep
- technical discussions off this list.
- (archives)
-
-
- Mailman Announce is a read-only list that you can subscribe to
- if you are only interested in release notices and other important
- news. Only the core Mailman developers can post messages to this
- list.
- (archives)
-
-
- Mailman Developers is the mailing list to use if you are
- interested in helping us develop Mailman, discuss future
- directions, etc. This is the list for more in-depth technical
- issues.
- (archives)
-
-
More information about developer resources is available
- here.
-
-
- Mailman Internationalization is the list for discussing the
- multi-lingual support in Mailman 2.1. Everyone who is working on
- translations of Mailman should subscribe to this mailing list.
- (archives)
-
-
- Mailman Checkins is an adjunct list to the publically
- accessible read-only CVS repository. This list is for the
- hardcore developers, or anybody else submitting patches, since we
- really prefer such patches to be generated against the latest
- snapshot. This is a read-only list; only the core Mailman
- developers can post messages to this list. There is no archive.
-
-
-
Please note that as of 10-Jul-2005, it appears that the listowner.org
-site is no longer available.
-
-
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.
-
-
-This document describes the list administrator's interface for GNU
-Mailman 2.1. It contains information a list owner would need to
-configure their list, either through the web interface or through
-email. It also covers the moderator's interface for approving held
-messages and subscription notices, and the web interface for creating
-new mailing lists. In general, it does not cover the command line
-interface to Mailman, installing Mailman, or interacting with Mailman
-from the point of view of the user. That information is covered in
-other manuals.
-
-These variables, grouped under the general list personality section,
-control some public information about the mailing list.
-
-
-
-
real_name
-
Every mailing list has both a posting name and a real
- name. The posting name shows up in urls and in email addresses,
- e.g. the mylist in mylist@example.com. The posting
- name is always presented in lower case, with alphanumeric
- characters and no spaces. The list's real name is used in some
- public information and email responses, such as in the general
- list overview. The real name can differ from the posting name by
- case only. For example, if the posting name is mylist, the
- real name can be Posting.
-
-
-
-
owner
-
This variable contains a list of email addresses, one address per
- line, of the list owners. These addresses are used whenever the
- list owners need to be contacted, either by the system or by end
- users. Often, these addresses are used in combination with the
- moderator addresses (see below).
-
-
-
-
moderator
-
This variable contains a list of email addresses, one address per
- line, of the list moderators. These addresses are often used in
- combination with the owner addresses. For example, when
- you email mylist-owner@example.com, both the owner and
- moderator addresses will receive a copy of the message.
-
-
-
-
description
-
In the general list overview page, which shows you every available
- mailing list, each list is displayed with a short description.
- The contents of this variable is that description. Note that in
- emails from the mailing list, this description is also used in the
- comment section of the To: address. This text should
- be relatively short and no longer than one line.
-
-
-
-
info
-
This variable contains a longer description of the mailing list.
- It is included at the top of the list's information page, and it
- can contain HTML. However, blank lines will be automatically
- converted into paragraph breaks. Preview your HTML though,
- because unclosed or invalid HTML can prevent display of parts of
- the list information page.
-
-
-
-
subject_prefix
-
This is a string that will be prepended to the
- Subject: header of any message posted to the list.
- For example, if a message is posted to the list with a
- Subject: like:
-
-
-
- Subject: This is a message
-
-
-
-and the subject_prefix is [My List] (note the
- trailing space!), then the message will be received like so:
-
-
-
- Subject: [My List] This is a message
-
-
-
-If you leave subject_prefix empty, no prefix will be added
- to the Subject:. Mailman is careful not to add a
- prefix when the header already has one, as is the case in replies
- for example. The prefix can also contain characters in the list's
- preferred language. In this case, because of vagarities of the
- email standards, you may or may not want to add a trailing space.
-
-
-
-
anonymous_list
-
This variable allows you to turn on some simple anonymizing
- features of Mailman. When you set this option to Yes,
- Mailman will remove or replace the From:,
- Sender:, and Reply-To: fields of any
- message posted to the list.
-
-
-Note that this option is simply an aid for anonymization, it
- doesn't guarantee it. For example, a poster's identity could be
- evident in their signature, or in other mail headers, or even in
- the style of the content of the message. There's little Mailman
- can do about this kind of identity leakage.
-
-This section controls what happens to the Reply-To:
-headers of messages posted through your list.
-
-
-Beware! Reply-To: munging is considered a religious issue
-and the policies you set here can ignite some of the most heated
-off-topic flame wars on your mailing lists. We'll try to stay as
-agnostic as possible, but our biases may still peak through.
-
-
-Reply-To: is a header that is commonly used to redirect
-replies to messages. Exactly what happens when your uses reply to
-such a message depends on the mail readers your users use, and what
-functions they provide. Usually, there is both a ``reply to sender''
-button and a ``reply to all'' button. If people use these buttons
-correctly, you will probably never need to munge
-Reply-To:, so the default values should be fine.
-
-
-Since an informed decision is always best, here are links to two
-articles that discuss the opposing viewpoints in great detail:
-
-
-The three options in this section work together to provide enough
-flexibility to do whatever Reply-To: munging you might
-(misguidingly :) feel you need to do.
-
-
-
-
first_strip_reply_to
-
This variable controls whether any Reply-To: header
- already present in the posted message should get removed before
- any other munging occurs. Stripping this header will be done
- regardless of whether or not Mailman will add its own
- Reply-To: header to the message.
-
-
-If this option is set to No, then any existing
- Reply-To: header will be retained in the posted
- message. If Mailman adds its own header, it will contain
- addresses which are the union of the original header and the
- Mailman added addresses. The mail standards specify that a
- message may only have one Reply-To: header, but that
- that header may contain multiple addresses.
-
-
-
-
reply_goes_to_list
-
This variable controls whether Mailman will add its own
- Reply-To: header, and if so, what the value of that
- header will be (not counting original header stripping - see
- above).
-
-
-When you set this variable to Poster, no additional
- Reply-To: header will be added by Mailman. This
- setting is strongly recommended.
-
-
-When you set this variable to This list, a
- Reply-To: header pointing back to your list's posting
- address will be added.
-
-
-When you set this variable to Explicit address, the value
- of the variable reply_to_address (see below) will be
- added. Note that this is one situation where
- Reply-To: munging may have a legitimate purpose. Say
- you have two lists at your site, an announce list and a discussion
- list. The announce list might allow postings only from a small
- number of approved users; the general list membership probably
- can't post to this list. But you want to allow comments on
- announcements to be posted to the general discussion list by any
- list member. In this case, you can set the Reply-To:
- header for the announce list to point to the discussion list's
- posting address.
-
-
-
-
reply_to_address
-
This is the address that will be added in the
- Reply-To: header if reply_goes_to_list is set
- to Explicit address.
-
-
-Mailman sends notifications to the list administrators or list members
-under a number of different circumstances. Most of these
-notifications can be configured in this section, but see the Bounce
-Processing and Auto-responder categories for other notifications that
-Mailman can send.
-
-
-
-
send_reminders
-
By default Mailman sends all list members a monthly password
- reminder. This notice serves two purposes. First, it reminds
- people about all the lists they may be subscribed to on this
- domain, including the lists where their subscription may be
- disabled. Second, it reminds people about their passwords for
- these lists, as well as the url for their personal options pages,
- so that they can more easily configure their subscription options.
-
-
-Some people get annoyed with these monthly reminders, and they can
- disable the reminders via their subscription options page. For
- some lists, the monthly reminders aren't appropriate for any of
- the members, so you can disable them list-wide by setting the
- send_reminders variable to No.
-
-
-
-
welcome_msg
-
When new members are subscribed to the list, either by their own
- action, or the action of a list administrator, a welcome message
- can be sent to them. The welcome message contains some common
- boilerplate information, such as the name of the list,
- instructions for posting to the list, and the member's
- subscription password. You can add additional information to the
- welcome message by typing the text into the welcome_msg
- text box. Note that because this text is sent as part of an
- email, it should not contain HTML.
-
-
-
-
send_welcome_msg
-
This flag controls whether or not the welcome message is sent to
- new subscribers.
-
-
-
-
goodbye_msg
-
Like the welcome_msg, a ``goodbye'' message can be sent to
- members when they unsubscribe from the list. Unlike the welcome
- message, there's no boilerplate for the goodbye message. Enter
- the entire goodbye message you'd like unsubscribing members to
- receive into the goodbye_msg text box.
-
-
-
-
send_goodbye_msg
-
This flag controls whether or not the goodbye message is sent to
- unsubscribing members.
-
-
-
-
admin_immed_notify
-
List moderators get notifications of pending administrative
- actions, such as subscription or unsubscription requests that
- require moderator approval, or posted messages that are being held
- for moderator approval. List moderators will always get a daily
- summary of such pending requests, but they can also get immediate
- notifications when such a request is made. The
- admin_immed_notify variable controls whether these
- immediate notifications are sent or not. It's generally a good
- idea to leave this set to Yes.
-
-
-
-
admin_notify_mchanges
-
This variable controls whether the list administrators should get
- notifications when members join or leave the list.
-
-
-
-
respond_to_post_requests
-
This variable controls whether the original sender of a posting
- gets a notice when their message is held for moderator approval.
-
-
-This section contains some miscellaneous settings for your mailing
-list.
-
-
-
-
emergency
-
When this option is enabled, all list traffic is emergency
- moderated, i.e. held for moderation. Turn this option on when
- your list is experiencing a flamewar and you want a cooling off
- period.
-
-
-
-
new_member_options
-
Each member has a set of subscription options which they can use
- to control how they receive messages and otherwise interact with
- the list. While the members can change these settings by logging
- into their personal options page, you might want to set the
- default for a number of the member options. You can do that with
- this variable, but see also the other categories for other member
- defaults you can set.
-
-
-This variable presents a set of checkboxes which control the
- defaults for some of the member options. Conceal the
- member's address specifies whether or not the address is
- displayed in the list roster. Acknowledge the member's
- posting controls whether or not Mailman sends an acknowledgement
- to a member when they post a message to the list. Do not
- send a copy of a member's own post specifies whether a member
- posting to the list will get a copy of their own posting.
- Filter out duplicate messages to list members (if possible)
- specifies whether members who are explicitly listed as a recipient
- of a message (e.g. via the Cc: header) will also get a
- copy from Mailman.
-
-
-Of course, members can always override these defaults by making
- changes on their membership options page.
-
-
-
-
administrivia
-
This option specifies whether Mailman will search posted messages
- for admimistrivia, in other words, email commands which
- usually should be posted to the -request address for the
- list. Setting this to Yes helps prevent such things as
- unsubscribe messages getting erroneously posted to the list.
-
-
-If a message seems to contain administrivia, it is held for
- moderator approval.
-
-
-
-
max_message_size
-
This option specifies a maximum message size, in kilobytes, over
- which the message will be held for moderator approval.
-
-
-
-
host_name
-
This option specifies the host name part of email addresses used
- by this list. For example, this is the example.com part of
- the posting address mylist@example.com.
-
-
-It's generally not a good idea to change this value, since its
- default value is specified when the mailing list is created.
- Changing this to an incorrect value could make it difficult to
- contact your mailing list. Also not that the url used to visit
- the list's pages is not configurable through the web interface.
- This is because if you messed it up, you'd have to have the site
- administrator fix it.
-
-
-
-
include_rfc2369_headers
-
RFC 2369 is an internet standard that describes a bunch of
- headers that mailing list managers should add to messages to make
- it easier for people to interact with the list. Mail reading
- programs which support this standard may provide buttons for easy
- access to the list's archives, or for subscribing and
- unsubscribing to the list. It's generally a good idea to enable
- these headers as it provides for an improved user experience.
- These headers are often called the List-* headers.
-
-
-However, not all mail readers are standards compliant yet, and if
- you have a large number of members who are using non-compliant
- mail readers, they may be annoyed at these headers. You should
- first try to educate your members as to why these headers exist,
- and how to hide them in their mail clients. As a last resort you
- can disable these headers, but this is not recommended.
-
-
-
-
include_list_post_header
-
The List-Post: header is one of the headers
- recommended by RFC 2369. However for some announce-only mailing
- lists, only a very select group of people are allowed to post to
- the list; the general membership is usually not allowed to post to
- such lists. For lists of this nature, the List-Post:
- header is misleading. Select No to disable the inclusion
- of this header. (This does not affect the inclusion of the other
- List-* headers.)
-
-As mentioned above, there are two primary administrative roles for
-mailing lists. In this category you can specify the password for
-these roles.
-
-
-The list owner has total control over the configuration of their
-mailing list (within some bounds as specified by the site
-administrator). Note that on this page, for historical reasons, the
-list owner role is described here as the list administrator.
-You can set the list owner's password by entering it in the password
-field on the left. You must type it twice for confirmation. Note
-that if you forget this password, the only way for you to get back
-into your list's administrative pages is to ask the site administrator
-to reset it for you (there's no password reminders for list owners).
-
-
-If you want to delegate list moderation to someone else, you can enter
-a different moderator password in the field on the right (typed twice
-for confirmation). Note that if you aren't going to delegate
-moderation, and the same people are going to both configure the list
-and moderate postings to the list, don't enter anything into the
-moderator password fields. If you do enter a separate moderator
-password, be sure to fill in the moderator variable in the
-General options category page.
-
-
-Mailman is multilingual and internationalized, meaning you can set up
-your list so that members can interact with it in any of a number of
-natural languages. Of course, Mailman won't translate list
-postings. :)
-
-
-However, if your site administrator has enabled its support, you can
-set your list up to support any of about two dozen languages, such as
-German, Italian, Japanese, or Spanish. Your list members can then
-choose any of your supported languages as their preferred
-language for interacting with the list. Such things as their member
-options page will be displayed in this language. Each mailing list
-also has its own preferred language which is the language the
-list supports if no other language context is known.
-
-
-These variables control the language settings for your mailing list:
-
-
-
-
preferred_language
-
This is the list's preferred language, which is the language that
- the list administrative pages will be displayed in. Also any
- messages sent to the list owners by Mailman will be sent in this
- language. This option is presented as a drop-down list containing
- the language enabled in the available_languages variable.
-
-
-
-
available_languages
-
This set of checkboxes contains all the natural languages that
- your site administrator has made available to your mailing lists.
- Select any language that you'd either like your members to be able
- to view the list in, or that you'd like to be able to use in your
- list's preferred_language variable.
-
-
-
-
encode_ascii_prefixes
-
If your mailing list's preferred language uses a non-ASCII
- character set and the subject_prefix contains non-ASCII
- characters, the prefix will always be encoded according to the
- relevant standards. However, if your subject prefix contains only
- ASCII characters, you may want to set this option to Never
- to disable prefix encoding. This can make the subject headers
- slightly more readable for users with mail readers that don't
- properly handle non-ASCII encodings.
-
-
-Note however, that if your mailing list receives both encoded and
- unencoded subject headers, you might want to choose As
- needed. Using this setting, Mailman will not encode ASCII
- prefixes when the rest of the header contains only ASCII
- characters, but if the original header contains non-ASCII
- characters, it will encode the prefix. This avoids an ambiguity
- in the standards which could cause some mail readers to display
- extra, or missing spaces between the prefix and the original
- header.
-
-The Membership Management category is unlike the other
-administrative categories. It doesn't contain configuration variables
-or list settings. Instead, it presents a number of pages that allow
-you to manage the membership of you list. This includes pages for
-subscribing and unsubscribing members, and for searching for members,
-and for changing various member-specific settings.
-
-
-More details on membership management are described in the Membership
-Management section.
-
-
-Mailman delivers messages to users via two modes. List members can
-elect to receive postings in bundles call digests one or a few
-times a day, or they can receive messages immediately whenever the
-message is posted to the list. This latter delivery mode is also
-called non-digest delivery. There are two administrative
-categories available for separately controlling digest and non-digest
-delivery. You can even disable one or the other forms of delivery
-(but not both).
-
-
-Both kinds of delivery can have list-specific headers and footers
-added to them which can contain other useful information you want your
-list members to see. For example, you can include instructions for
-unsubscribing, or a url to the lists digest, or any other information.
-
-
-Non-digest deliveries can also be personalized which means
-certain parts of the message can contain information tailored to the
-member receiving the message. For example, the To: header
-will contain the address of the member when deliveries are
-personalized. Footers and headers can contain personalized
-information as well, such as a link to the individual user's options
-page.
-
-
-In addition, personalized messages will contain extra information that
-Mailman can use to unambiguously track bounces from members.
-Ordinarily, Mailman does some pattern recognition on bounce messages
-to determine list members whose addresses are no longer valid, but
-because of the vagaries of mail systems, and the countless forwards
-people can put in place, it's often the case that bounce messages
-don't contain any useful information in them. Personalized messages
-avoid this problem by encoding information in certain headers that
-unambiguously identify the recipient of a message. If that message
-bounces, Mailman will know exactly which member it was intended for.
-
-
-Note that because personalization requires extra system resources, it
-must be enabled by the site administrator before you can choose it.
-
-
-Here are the variables which control non-digest delivery:
-
-
-
-
nondigestable
-
This option controls whether members can receive immediate
- delivery or not. If not, they will be forced to receive messages
- in digests. You can't disable non-digest delivery if digests are
- already disabled.
-
-
-
-
personalize
-
This option turns on message personalization.
-
-
-
-
msg_header
-
This text box lets you enter information that will be included in
- the header of every non-digest message sent through the
- list.
-
-
-See below for more information on what can go in the headers and
- footers. If you leave this text box empty, no header will be
- added.
-
-
-
-
msg_footer
-
Just like with the header, you can add a footer to every message.
- The same rules apply to footers as apply to headers.
-
-
-
-
-Headers and footers can contain any text you want. For non-English
-lists, the headers and footers can contain any character in the
-character set of the list's preferred language. The headers and
-footers can also contain substitution variables which Mailman
-will fill in with information taken from the mailing list. These
-substitutions are in Python string interpolation format, where
-something like %(list_name)s is substituted with he name of
-the mailing list. Note that the trailing "s" is
-required2.
-
-
-For example, a footer containing the following text:
-
-
-
-This is the \%(list_name)s mailing list
-Description: \%(description)s
-
-
-
-might get attached to postings like so:
-
-
-
-This is the Example mailing list
-Description: An example of Mailman mailing lists
-
-
-
-Here is the list of substitution variables available for your headers
-and footers:
-
-
-
-
real_name
-
This is the value of the real_name configuration variable
- in the General options category.
-
-
-
-
list_name
-
This is the canonical name of the mailing list. In other words
- it's the posting address of the list3.
-
-
-
-
host_name
-
This is the domain name part of the email address for this list.
-
-
-
-
web_page_url
-
This is the base url for contacting the list via the web. It can
- be appended with listinfo/%(list_name)s to yield the
- general list information page for the mailing list.
-
-
-
-
description
-
The brief description of the mailing list.
-
-
-
-
info
-
This is the full description of the mailing list.
-
-
-
-
cgiext
-
This is the extension added to CGI scripts. It might be the empty
- string, .cgi, or something else depending on how your site
- is configured.
-
-
-
-
-Note that real_name, host_name, description, and
-info substitution variables take their values from the list
-configuration variables of the same name.
-
-
-When personalization is enabled, the following substitution variables
-are also available:
-
-
-
-
user_address
-
The address of the recipient of the message, coerced to lower case.
-
-
-
-
user_delivered_to
-
The case-preserved address that the user subscribed to the mailing
- list with4.
-
-
The site administrator can configure lists to use a
-simpler interpolation format, where $list_name or
-${list_name} would be substituted with the mailing list's
-name. Ask your site administrator if the've configured your list this
-way.
-
-
Usually it makes no difference which of
- user_address and user_delivered_to is used, but it's
- important to remember that they can be different. When they're
- different, Mailman always uses the lower case address as the key
- to the member's subscription information, but it always delivers
- messages to the case-preserved version.
-
-
-Digest delivery is a way to bundle many articles together into one
-package, which can be delivered once per day (if there were any posted
-articles), or whenever the package is bigger than a specified limit.
-Some users may prefer this style of delivery for higher traffic lists
-since they will receive fewer messages.
-
-
-Mailman supports two standard digest formats, and if digests are
-enabled, users can select which of the two formats they receive. One
-is MIME digests, where each message is an attachment inside a
-multipart/digest. This format also contains a summary
-table of contents, and of course the an optional header and footer,
-and it retains most of the headers of the original messages.
-
-
-The second type is called ``plaintext'' digests because they are
-readable in mail readers that don't support MIME. Actually, they
-adhere to the RFC 1153 digest standard. The retain some, but not
-all of the original messages, but can also include a summary and
-headers and footers.
-
-
-Like non-digest delivery, you can enable or disable digest delivery,
-but you cannot disable both types of delivery. You can specify
-different headers and footers for digest and non-digest deliveries.
-You cannot personalize digest deliveries.
-
-
-As list administrator, you may want to send an urgent message to all
-list members, bypassing the normal digest bundling. To do this, send
-the message with a Urgent: header, where the value of the
-header is the list administrator's password. Non-digest members will
-receive the message like normal, but digest members will receive the
-message immediately5.
-
-
-Here are the variables which control digest delivery:
-
-
-
-
digestable
-
The option controls whether members can receive digest deliveries
- or not. If not, they will be forced to receive immediate
- deliveries. You can't disable digests if non-digests are already
- disabled.
-
-
-
-
digest_is_default
-
Controls which style of delivery is the default for new members.
- You can choose Regular (non-digest) or Digest
- delivery.
-
-
-
-
mime_is_default_digest
-
If a member is allowed to choose digests, this variable controls
- which is the default digest style they will receive. Plain
- digests are RFC 1153 format as described above.
-
-
-
-
digest_size_threshold
-
Normally, digest members get at least one message per day, if
- there have been any messages posted to the list. However, for
- high volume lists, you may want to send out digests when the size
- has reached a certain threshold, otherwise, the one digest they
- receive could be huge. This variable controls the size threshold
- by specifying the maximum digest size in kilobytes. Note that
- this threshold isn't exact. Set this variable to zero to specify
- that there is no size threshold, in which case no more than one
- digest will be sent out per day.
-
-
-
-
digest_send_periodic
-
This variable actually controls whether or not a digest is sent
- daily when the size threshold has not yet been met. If set to
- No, then digests will only be sent when they are bigger
- than digest_size_threshold.
-
-
-
-
digest_header
-
This text box lets you enter information that will be included in
- the header of every digest message sent through the list. The
- same information can go in this header as can go in the
- msg_header, except for the personalization variables.
-
-
-
-
digest_footer
-
Just like with the header, you can add a footer to every message.
- The same rules apply to digest footers as apply to digest headers.
-
-
-
-
digest_volume_frequency
-
Each digest is numbered with a volume and an issue. This variable
- controls how often a new digest volume is sent. When the digest
- volume number is incremented, the issue number is reset to 1.
-
-
-
-
_new_volume
-
This is an action variable, which forces an increment of the
- volume number as soon as you submit the form.
-
-
-
-
_send_digest_now
-
This is another action variable. Select Yes, submit the
- form, and the current digest is packaged up and sent to digest
- members, regardless of size (well, there has to be at least one
- message in the digest).
-
-The Privacy category lets you control how much of the list's
-information is public, as well as who can send messages to your list.
-It also contains some spam detection filters. Note that this section
-is not used to control whether your list's archives are public or
-private; for that, use the category.
-
-
-There are four sub-categories:
-
-
-
Subscription rules - i.e. the rules for joining and leaving
- your mailing list
-
-
-
-
Sender filters - the rules for who may post messages to your
- list
-
-
-
-
Recipient filters - moderation rules based on the recipient of
- the message
-
-
-
-
Spam filters - some regular expression based rules for header
- matching
-
-
-
-
-The sender, recipient, and spam filtering rules are part of the
-general list moderation features of Mailman. When a message is posted
-to the list, it is matched against a number of criteria, the outcome
-of which determines whether the message is reflected to the membership
-or not. In general, the outcome is one of four states:
-
-
-
-
-
Approved or Accepted - the message may be sent on to the
- members of the mailing list.
-
-
-
-
Hold - the message will be held for moderator approval. The
- list owners and moderators will then have to explicitly approve
- the message before the list members will see it.
-
-
-
-
Reject - the message is bounced back to the original sender,
- often with a notice containing the reason the message was
- rejected. The list members never see rejected messages.
-
-
-
-
Discard - the message is simply thrown away without further
- processing.
-
-
-
-
-Many of the fields in this section are text boxes accepting addresses,
-one per line. Unless otherwise noted, these also accept regular
-expressions which will be matched against an address, if the line
-begins with a (caret) character.
-
-
-This subcategory controls the rules for exposing the existance of this
-list, and for what new members must do in order to subscribe to the
-list.
-
-
-
-
advertised
-
This option controls whether this list will show up in the list
- overview for the site. Normally, an overview contains the name
- and short description of every mailing list in the virtual
- domain. By setting this variable to No, it will not show
- up in this overview, nor will it show up in the administrative
- overview. The only way then to find the list is to guess (or
- know!) its name.
-
-
-
-
subscribe_policy
-
This option controls the steps that a new member must take to join
- the list. The available options may differ based on some defaults
- that the site administrator chooses. They are:
-
-
-
-
-
None - No verification is done on the subscribing
- member. This is also called open subscriptions and is
- generally disabled by default. The site administrator must
- allow list admins to choose this option; if not, this option
- will not be presented to you.
-
-
-
-
Confirm - An email confirmation step is required before the
- address is added to the list. When a member requests
- subscription, either via the web page or by sending a
- message to yourlist-join@example.com, Mailman
- will send a confirmation message to the requesting address.
- This mail-back confirmation contains a unique identifier,
- which the requester can present to Mailman in order to
- confirm their subscription. This can be done either by
- replying to the mail-back, or by visiting the url in the
- mail-back message. The url points to a page that lets the
- user either discard or confirm their request.
-
-
-
-
Require approval - All subscription requests are held for
- approval of the list moderator. No mail-back confirmation
- is sent, but the list admins will recieve a message
- indicating that approval is pending.
-
-
-
-
Confirm and approve - Here, a mail-back notice must first
- be confirmed by the requester. Once confirmed, the list
- moderator must then approve the request. This is the most
- secure method for users to subscribe since it both verifies
- the requesting address, and forces the list moderators to
- approve the request.
-
-
-
-
-
-
-
-
unsubscribe_policy
-
Specifies whether the list moderator's approval is required for
- unsubscription requests. No is highly recommended, since
- it is exceedingly impolite to not allow people to leave a mailing
- list whenever they want (i.e. opt-out). Yes is useful in
- some specialized contexts; e.g. you may not want to allow
- employees to unsubscribe from the company newsletter.
-
-
-
-
ban_list
-
This contains a list of addresses (or regular expressiosn), one
- per line, that are banned from ever subscribing to your mailing
- list. If a match occurs during the subscription process, the
- request will be automatically rejected, and the requester will get
- a rejection notice. You can use this to permanently ban
- troublesome posters to a members-only list.
-
-
-
-
private_roster
-
This specifies who is allowed to view the roster of member
- addresses. If you choose Anyone, then the list membership
- is completely public. You can limit exposure of the roster to
- just list members, or just to the list administrators. In the
- former case, a user must enter a valid member's address and
- password before they can view the roster. In the latter case, a
- list administrator's password must be enter; if a matching admin
- password is entered, address field is ignored.
-
-
-
-
obscure_addresses
-
Controls whether some simple obfuscation of addresses is used when
- member addresses are included on web pages. This should reduce
- the opportunity for email address harvesting by spammers, although
- it probably doesn't eliminate it.
-
-When a message is posted to the list, a series of moderation criteria are
-applied to determine the disposition of the message. This section
-contains the modeation controls for postings from both members and
-non-members.
-
-
-
-
default_member_moderation
-
Member postings are held for moderation if their moderation
- flag is turned on. Note that only the list administrators can
- change the value of a member's moderation flag.
-
-
-You can control whether new members get their moderation flag
- turned on or off by default when they subscribe to the list. By
- turning this flag off by default, postings by members will be
- allowed without further intervention (barring other restrictions
- such as size or implicit recipient lists - see below). By
- turning the flag on, you can quarantine new member postings to
- make sure that they meet your criteria for netiquette, topicality,
- etc. Once you determine that the new member understands the
- community's posting rules, you can turn off their moderation flag
- and let their postings go through unstopped.
-
-
-E-newsletter style lists can also be set up by using the
- moderation flag. By setting the member_moderation_action
- to Reject, and by turning off the moderation flag for just
- the few approved senders, your list will operate in essentially a
- one-way direction. Note that you'd also need to reject or discard
- postings from non-members.
-
-
-
-
member_moderation_action
-
This is the action to take for postings from a member who's
- moderation flag is set. For typical discussion lists, you'll
- likely set this to Hold so that the list moderator will get
- a chance to manually approve, reject, or discard the message. For
- e-newsletter and announcement lists, you might want to set this to
- Reject or Discard.
-
-
-Note that when a moderated member posts to your list, and the
- member_moderation_action is set to Hold, the message
- will appear on the administrative requests page. When you dispose
- of the message, you will be given an opportunity to clear the
- moderation flag at the same time. If you're quarantining new
- posts, this makes it very convenient to both approve a new
- member's post and de-moderate them at the same time.
-
-
-
-
member_moderation_notice
-
When a member's moderation flag is turned on and
- member_moderation_action is Reject, this variable
- contains the text sent in the rejection notice.
-
-
-
-
-The next batch of variables controls what happens when non-members
-post messages to the list. Each of these accepts one email address
-per line; regular expressions are allowed if the line starts with the
-(caret) character. These address lists are always consulted in the
-order in which they're presented on this page (i.e. accepts first,
-followed by holds, rejections, and discards).
-
-
-
-
accept_these_nonmembers
-
Postings from non-members whose addresses match this list are
- accepted, barring other list restrictions due to size, implicit
- recipients, etc. You might want to add alternative addresses of
- approved posters to this list.
-
-
-
-
hold_these_nonmembers
-
Postings from non-members whose addresses match this list are
- held for moderator approval.
-
-
-
-
reject_these_nonmembers
-
Postings from non-members whose addresses match this list are
- rejected, i.e. bounced back to the original sender. There
- currently is no way to add additional text to the rejection
- message.
-
-
-
-
discard_these_nonmembers
-
Postings from non-members whose addresses match this list are
- discarded, with no bounce back message. You might want to add the
- addresses of known spammers to this list.
-
-
-
-
generic_nonmember_action
-
This variable controls what happens to non-member posts when the
- address of the sender doesn't match any of the above four lists.
- If you set this to Hold, the posting will appear on the
- administrative requests page, and you will be given an opportunity
- to add the non-member to one of the above four lists at the same
- time you dispose of the held message.
-
-
-
-
forward_auto_discards
-
When messages from non-members are discarded, either because the
- sender address matched discard_these_nonmembers, or because
- generic_nonmember_action is Discard, you can choose
- whether such messages are forwarded to the lsit administrators or
- not.
-
-The variables in this section control various filters based on the
-recipient of the message.
-
-
-
-
require_explicit_destination
-
This controls whether the mailing list posting address must be
- explicitly named in the To: or Cc:
- recipient lists. The main reason why it wouldn't is if the
- message was blind-carbon-copied (i.e. Bcc:'d) to the
- list. Spammers like to do this, but sometimes legitimate messages
- are forwarded to the list this way.
-
-
-If the list is not explicitly addressed and this setting is turned
- on, the message will be held for moderator approval.
-
-
-
-
acceptable_aliases
-
This is the list of alternative addresses that are acceptable as a
- list posting address when require_explicit_destination is
- enabled. This is useful for when there aliases for the main
- posting address (e.g. help@example.com may be an alias for
- help-list@example.com).
-
-
-
-
max_num_recipients
-
This is the maximum number of explicit recipients that are allowed
- on the posted message. Spammers sometimes send messages with lots
- of explicit recipients, so setting this number to a reasonable
- value may cut down on spam.
-
-This section provides some adjuncts to spam fighting tools; it
-doesn't replace dedicated anti-spam tools such as SpamAssassin or
-Spambayes.
-
-
-
-
bounce_matching_headers
-
This variable contains header regular expressions, one per line,
- and if any of a message's headers matches one of these patterns,
- it will be held for moderation. The format is a colon separated
- header and value, where the header is case insensitive and the
- value is any valid Python regular expression. Lines that start
- with # are ignored.
-
-
-This variable can be used to catch known spammers by writing
- regexps that match against To: or Cc:
- lines, or known-bad Message-ID:s. Perhaps more useful
- though are patterns that match headers added by spam detection
- tools higher up in the tool chain. For example, you might
- configure SpamAssassin to add an X-Spam-Score: header
- with between zero and 5 stars depending on the spam score. Then
- you can add a line to this variable like:
-
-
-
- X-Spam-Score: [*]{3,5}
-
-
-
-This line will match from 3 to 5 stars in the value of this
- field.
-
-These policies control the automatic bounce processing system in
-Mailman. Here's an overview of how it works:
-
-
-When a bounce is received, Mailman tries to extract two pieces of
-information from the message: the address of the member the message
-was intended for, and the severity of the problem causing the bounce.
-The severity can be either hard for fatal errors, or
-soft for transient errors. When in doubt, a hard severity is
-used.
-
-
-If no member address can be extracted from the bounce, then the bounce
-message is usually discarded. Every member has a bounce score,
-initialized at zero, and every time we encounter a bounce from a
-member we increment that member's score. Hard bounces increment by 1
-while soft bounces increment by 0.5. We only increment the bounce
-score once per day, so even if we receive ten hard bounces from a
-member per day, their score will increase by only 1 for that day.
-
-
-When a member's bounce score is greater than the bounce score
-threshold (see below), the member's subscription is disabled. Once
-disabled, the member will not receive any postings from the list until
-their membership is explicitly re-enabled, either by the list
-administrator or the user. However, they will receive occasional
-reminders that their membership has been disabled, and these reminders
-will include information about how to re-enable their membership. You
-can control both the number of reminders the member will receive and
-the frequency with which these reminders are sent.
-
-
-There is one other important configuration variable; after a certain
-period of time - during which no bounces from the member are received
-- the bounce information is considered stale and discarded. Thus by
-adjusting this value, and the score threshold, you can control how
-quickly bouncing members are disabled. You should tune both of these
-to the frequency and traffic volume of your list.
-
-
-
-
bounce_processing
-
Specifies whether or not this list should do automatic bounce
- processing.
-
-
-
-
bounce_score_threshold
-
This is the bounce score above which a member's subscription will
- be automatically disabled. When the subscription is re-enabled,
- their bounce score will be reset to zero. This value can be a
- floating point number.
-
-
-
-
bounce_info_stale_after
-
Thenumber of days after which a member's bounce information is
- considered stale. If no new bounces have been received in the
- interrim, the bounce score is reset to zero. This value must be
- an integer.
-
-
-
-
bounce_you_are_disabled_warnings
-
The number of notices a disabled member will receive before their
- address is removed from the mailing list's roster. Set this to 0
- to immediately remove an address from the list once their bounce
- score exceeds the threshold. This value must be an integer.
-
-
-
-
bounce_you_are_disabled_warnings_interval
-
The number of days between each disabled notification.
-
-
-
-
bounce_unrecognized_goes_to_list_owner
-
This variable controls whether unrecognized bounces are discarded,
- or forwarded on the list administrator. The bounce detector isn't
- perfect, although personalization can make it much more accurate.
- The list owner may want to receive unrecognized bounces so that
- they can manually disable or remove such members.
-
-
-
-
bounce_notify_owner_on_disable
-
This option controls whether or not the list owner is notified
- when a member's subscription is automatically disabled due to
- their bounce threshold being reached.
-
-
-
-
bounce_notify_owner_on_removal
-
This option controls whether or not the list owner is notified
- when a member is removed from the list after their disabled
- notifications have been exhausted.
-
-Mailman comes with a built-in web-based archiver called
-Pipermail, although it can be configured to use external,
-third party archivers.
-
-
-
-
archive
-
This option tells Mailman whether to archive messages it receives
- or not, regardless of whether Pipermail or a third party archiver
- is used. Turn this off if you don't want to archive messages.
-
-
-Note that senders can control whether their own posts are
- archived, on an individual per-message basis. If the posted
- message has a X-No-Archive: header (regardless of
- value), or a X-Archive: header with a value of
- No (case insensitive), then the message will not be
- archived, although it will be treated as normal in all other
- ways.
-
-
-
-
archive_private
-
Controls whether Pipermail archives are private or public.
- Private archives require a valid member address and password, or a
- list administrator password in order to access them. This
- option has no effect when a third party archiver is used.
-
-
-
-
archive_volume_frequency
-
Controls how Pipermail splits messages in the archive. The most
- common option is Monthly meaning a new archive volume is
- started every month. Very high volume lists may want a shorter
- frequency (e.g. Weekly or Daily) where as lower
- volume lists may want a longer frequency (e.g. Yearly).
- This option has no effect when a third party archiver is used.
-
-Mailman has a sophisticated mail-to-news gateway feature. It can
-independently gate messages from news to mail and vice versa, and can
-even be used to manage moderated newsgroups.
-
-
-GNU Mailman is software that lets you manage electronic mailing lists.
-It supports a wide range of mailing list types, such as general
-discussion lists and announce-only lists. Mailman has extensive
-features for controlling the privacy of your lists, distributing your
-list as personalized postings or digests, gatewaying postings to and
-from Usenet, and providing automatic bounce detection. Mailman
-provides a built-in archiver, multiple natural languages, as well as
-advanced content and topic filtering.
-
-
-Mailman provides several interfaces to its functionality. Most list
-administrators will primarily use the web interface to customize their
-lists. There is also a limited email command interface to the
-administrative functions, as well as a command line interface if you
-have shell access on the Mailman server. This document does not cover
-the command line interface; see the GNU Mailman site administrator's
-manual for more details.
-
-
-To create an appendix in a Python HOWTO document, use markup like
-this:
-
-
-
-\appendix
-
-\section{This is an Appendix}
-
-To create an appendix in a Python HOWTO document, ....
-
-
-\section{This is another}
-
-Just add another \section{}, but don't say \appendix again.
-
-Every mailing list has a set of email addresses that messages can be
-sent to. There's always one address for posting messages to the list,
-one address that bounces will be sent to, and addresses for processing
-email commands. For example, for a mailing list called
-mylist@example.com, you'd find these addresses:
-
-
-
-
-
mylist@example.com - this is the email address people should
- use for new postings to the list.
-
-
-
-
mylist-join@example.com - by sending a message to this address,
- a new member can request subscription to the list. Both the
- Subject: header and body of such a message are
- ignored. Note that mylist-subscribe@example.com is an alias for
- the -join address.
-
-
-
-
mylist-leave@example.com - by sending a message to this address,
- a member can request unsubscription from the list. As with the
- -join address, the Subject: header and body of the
- message is ignored. Note that mylist-unsubscribe@example.com is
- an alias for the -leave address.
-
-
-
-
mylist-owner@example.com - This address reaches the list owner
- and list moderators directly.
-
-
-
-
mylist-request@example.com - This address reaches a mail robot
- which processes email commands that can be used to set member
- subscription options, as well as process other commands.
-
-
-
-
mylist-bounces@example.com - This address receives bounces from
- members who's addresses have become either temporarily or
- permanently inactive. The -bounces address is also a mail robot
- that processes bounces and automatically disables or removes
- members as configured in the bounce processing settings. Any
- bounce messages that are either unrecognized, or do not seem to
- contain member addresses, are forwarded to the list
- administrators.
-
-
-
-
mylist-confirm@example.com - This address is another email
- robot, which processes confirmation messages for subscription
- and unsubscription requests.
-
-
-
-
-There's also an -admin address which also reaches the list
-administrators, but this address only exists for compatibility with
-older versions of Mailman.
-
-
-There are two primary administrative roles for each mailing list, a
-list owner and a list moderator. A list owner is allowed to change
-various settings of the list, such as the privacy and archiving
-policies, the content filtering settings, etc. The list owner is also
-allowed to subscribe or invite members, unsubscribe members, and
-change any member's subscription options.
-
-
-The list moderator on the other hand, is only allowed to approve or
-reject postings and subscription requests. The list moderator can
-also do things like clear a member's moderation flag, or add an
-address to a list of approved non-member posters.
-
-
-Normally, the list owner and list moderator are the same person. In
-fact, the list owner can always do all the tasks a list moderator can
-do. Access to both the owner's configuration pages, and the
-moderation pages are protected by the same password. However, if the
-list owner wants to delegate posting and subscription approval
-authority to other people, a separate list moderator password can be
-set, giving moderators access to the approval pages, but not the
-configuration pages. In this setup, list owners can still moderate
-the list, of course.
-
-
-In the sections that follow, we'll often use the terms list owner and
-list administrator interchangably, meaning both roles. When
-necessary, we'll distinguish the list moderator explicitly.
-
-
-Every mailing list is also accessible by a number of web pages. Note
-that the exact urls is configurable by the site administrator, so they
-may be different than what's described below. We'll describe the most
-common default configuration, but check with your site administrator
-or hosting service for details.
-
-
-Mailman provides a set of web pages that list members use to get
-information about the list, or manage their membership options. There
-are also list archive pages, for browsing an online web-based archive
-of the list traffic. These are described in more detail in the GNU
-Mailman user's manual.
-
-
-Mailman also provides a set of pages for configuring an individual
-list, as well as a set of pages for disposing of posting and
-subscription requests.
-
-
-For a mailing list called mylist hosted at the domain
-lists.example.com, you would typically access the administrative
-pages by going to http://lists.example.com/mailman/admin/mylist.
-The first time you visit this page, you will be presented with a login
-page, asking for the list owner's password. When you enter the
-password, Mailman will store a session cookie in your browser, so you
-don't have to re-authenticate for every action you want to take. This
-cookie is stored only until you exit your browser.
-
-
-To access the administrative requests page, you'd visit
-http://lists.example.com/mailman/admindb/mylist (note the
-admindb url as opposed to the admin url). Again, the
-first time you visit this page, you'll be presented with a login page,
-on which you can enter either the list moderator password or the list
-owner password. Again, a session cookie is dropped in your browser.
-Note also that if you've previously logged in as the list owner, you
-do not need to re-login to access the administrative requests page.
-
-
-This section will outline the basic architecture of GNU Mailman, such
-as how messages are processed by the sytem. Without going into lots
-of detail, this information will help you understand how the
-configuration options control Mailman's functionality.
-
-
-When mail enters the system from your mail server, it is dropped into
-one of several Mailman queues depending on the address the
-message was sent to. For example, if your system has a mailing list
-named mylist and your domain is example.com, people can
-post messages to your list by sending them to
-mylist@example.com. These messages will be dropped into the
-incoming queue, which is also colloquially called the
-moderate-and-munge queue. The incoming queue is where most of
-the approval process occurs, and it's also where the message is
-prepared for sending out to the list membership.
-
-
-There are separate queues for the built-in archiver, the bounce
-processor, the email command processor, as well as the outgoing email
-and news queues. There's also a queue for messages generated by the
-Mailman system. Each of these queues typically has one queue
-runner (or ``qrunner'') that processes messages in the queue. The
-qrunners are idle when there are no messages to process.
-
-
-Every message in the queues are represented by two files, a message
-file and a metadata file. Both of these files share the same base
-name, which is a combination of a unique hash and the Unix time that
-the message was received. The metadata file has a suffix of
-.db and the message file has a suffix of either .msg if
-stored in plain text, or .pck if stored in a more efficient
-internal representation1.
-
-
-As a message moves through the incoming queue, it performs various
-checks on the message, such as whether it matches one of the
-moderation criteria, or contains disallowed MIME types. Once a
-message is approved for sending to the list membership, the message is
-prepared for sending by deleting, adding, or changing message headers,
-adding footers, etc. Messages in the incoming queue may also be
-stored for appending to digests.
-
-
-After logging into the list configuration pages, you'll see the
-configuration options for the list, grouped in categories. All the
-administrative pages have some common elements. In the upper section,
-you'll see two columns labeled ``Configuration Categories''. Some
-categories have sub-categories which are only visible when you click
-on the category link. The first page you see after logging in will be
-the ``General Options'' category. The specific option settings for
-each category are described below.
-
-
-On the right side of the top section, you'll see a column labeled
-``Other Administrative Activities''. Here you'll find some other
-things you can do to your list, as well as convenient links to the
-list information page and the list archives. Note the big ``Logout''
-link; use this if you're finished configuring your list and don't want
-to leave the session cookie active in your browser.
-
-
-Below this common header, you'll find a list of this category's
-configuration variables, arranged in two columns. In the left column
-is a brief description of the option, which also contains a
-``details'' link. For many of the variables, more details are
-available describing the semantics of the various available settings,
-or information on the interaction between this setting and other list
-options. Clicking on the details link brings up a page which contains
-only the information for that option, as well as a button for
-submitting your setting, and a link back to the category page.
-
-
-On the right side of the two-column section, you'll see the variable's
-current value. Some variables may present a limited set of values,
-via radio button or check box arrays. Other variables may present
-text entry boxes of one or multiple lines. Most variables control
-settings for the operation of the list, but others perform immediate
-actions (these are clearly labeled).
-
-
-At the bottom of the page, you'll find a ``Submit'' button and a
-footer with some more useful links and a few logos. Hitting the
-submit button commits your list settings, after they've been
-validated. Any invalid values will be ignored and an error message
-will be displayed at the top of the resulting page. The results page
-will always be the category page that you submitted.
-
-
-The General Options category is where you can set a variety of
-variables that affect basic behavior and public information. In the
-descriptions that follow, the variable name is given first, along with
-an overview and a description of what that variable controls.
-
-
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.
-
-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.
-
-
-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
---prefixconfigure 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:
-
-
-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.
-
-
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.
-
-
-
-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.
-
-
-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.
-
-
-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:
-
-
-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>
-
-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.
-
-
-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:
-
-
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:
-
-
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.
-
-
-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.
-
-
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.
-
-
-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.
-
-
-First, you need to add some macros to the top of your Exim config file. These
-just make the director (router) and transport below a bit cleaner. Obviously,
-you'll need to edit these based on how you configured and installed Mailman.
-
-
-
- # Home dir for your Mailman installation -- aka Mailman's prefix
- # directory.
- MAILMAN_HOME=/usr/local/mailman
- MAILMAN_WRAP=MAILMAN_HOME/mail/mailman
-
- # User and group for Mailman, should match your --with-mail-gid
- # switch to Mailman's configure script.
- MAILMAN_USER=mailman
- MAILMAN_GROUP=mailman
-
-GNU Mailman 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.
-
-
-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
-
-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.
-
-
-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.
-
-
-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.
-
-
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.
-
-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):
-
-
-which only does recipient verification on addresses in your domain. (That's
-not exactly the same as doing recipient verification only on messages coming
-from non-127.0.0.1 hosts, but it should do the trick for Mailman.)
-
-
-Exim's SMTP callback feature is an even more powerful way to detect bogus
-sender addresses than normal sender verification. Unfortunately, lots of
-servers send bounce messages with a bogus address in the header, and there are
-plenty that 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:
-
-
-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:
-
-
-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:
-
-
-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):
-
-
-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!
-
-
-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.
-
-
-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.
-
-
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.
-
-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:
-
-
-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
-
-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.
-
-
-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:
-
-
-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.
-
-
-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:
-
-
-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:
-
-
-Several Mailman features occur on a regular schedule, so you must set up
-cron to run the right programs at the right time6.
-
-
-If your version of crontab supports the -u option, you must be
-root to do this next step. Add $prefix/cron/crontab.in as a
-crontab entry by executing these commands:
-
-
-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
-
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.
-
-
-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):
-
-
-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:
-
-
-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:
-
-
-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.
-
-
-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.
-
-
-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.
-
-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.
-
-
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:
-
-
-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.
-
-
-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.
-
-
-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:
-
-
-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:
-
-
-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:
-
-
-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.
-
-
-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-gidconfigure 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:
-
-
-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.
-
-
-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:
-
-
-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:
-
-
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-bounces
- # The following line is for VERP
- # echo "|preline /usr/local/mailman/mail/mailman bounces $i" > .qmail-$i-bounces-default
- echo "|preline /usr/local/mailman/mail/mailman confirm $i" > .qmail-$i-confirm
- echo "|preline /usr/local/mailman/mail/mailman join $i" > .qmail-$i-join
- echo "|preline /usr/local/mailman/mail/mailman leave $i" > .qmail-$i-leave
- echo "|preline /usr/local/mailman/mail/mailman owner $i" > .qmail-$i-owner
- echo "|preline /usr/local/mailman/mail/mailman request $i" > .qmail-$i-request
- echo "|preline /usr/local/mailman/mail/mailman subscribe $i" > .qmail-$i-subscribe
- echo "|preline /usr/local/mailman/mail/mailman unsubscribe $i" > .qmail-$i-unsubscribe
-fi
-
-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:
-
-
-
-
-
configured the web server to give permissions to
- $prefix/cgi-bin
-
-
-
-
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
-
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.
-
-
-This document describes the list member interface for GNU
-Mailman 2.1. It contains instructions for subscribing, unsubscribing,
-viewing the archives, editing user options, getting password reminders,
-and other subscriber-level tasks. It also answers some common questions
-of interest to Mailman list members.
-
-Every mailing list has a set of email addresses to which messages can be
-sent. There's always one address for posting messages to the list, one
-address to which bounces are sent, and addresses for processing email
-commands. For a fictional mailing list called
-mylist@example.com, you'd find these addresses:
-
-
-
-
-
mylist@example.com - this is the email address people should
- use for new postings to the list.
-
-
-
-
mylist-join@example.com - by sending a message to this address,
- a new member can request subscription to the list. Both the
- Subject: header and body of such a message are
- ignored. Note that mylist-subscribe@example.com is an alias for
- the -join address.
-
-
-
-
mylist-leave@example.com - by sending a message to this address,
- a member can request unsubscription from the list. As with the
- -join address, the Subject: header and body of the
- message is ignored. Note that mylist-unsubscribe@example.com is
- an alias for the -leave address.
-
-
-
-
mylist-owner@example.com - This address reaches the list owner
- and list moderators directly. This is the address you use if
- you need to contact the person or people in charge.
-
-
-
-
mylist-request@example.com - This address reaches a mail robot
- which processes email commands that can be used to set member
- subscription options, as well as process other commands.
- A list of members' email commands is provided in
- Appendix A.
-
-
-
-
mylist-bounces@example.com - This address is used in
- Mailman's automatic bounce processing.
-
-
-
-
mylist-confirm@example.com - This address is used for
- processing confirmation messages for subscription
- and unsubscription requests.
-
-
-
-
-There's also an -admin address which also reaches the list administrators,
-but this address only exists for compatibility with older versions of
-Mailman.
-
-
-For changing options, we use the LISTNAME-request
-address (for example, mylist-request@example.com).
-
-
-Commands can appear in the subject line or the body of the message. Each
-command should be on a separate line. If your mail program automatically
-appends a signature to your messages, you may want to put the word
-``end'' (without the quotes) on a separate line after your other commands.
-The end command tells Mailman not to process the email after that
-point.
-
-
-The most important command is probably the ``help'' command, since it
-makes Mailman return a message full of useful information about the
-email commands and directions to the web interface.
-
-
-Quick references to the subscriber commands have been provided in
-Appendices A and B. (These have been slightly
-adapted from the output of the help command.)
-
-
-If you have any trouble with any of these commands, you can always reach the
-person or people in charge of a list by using the list administrator email address.
-The list administrators can help you figure out
-how to do something, subscribe/unsubscribe you, or change your
-settings if you are unable to change them yourself for some reason. Please
-remember that many mailing list administrators are volunteers who are donating
-their spare time to run the list, and they may be very busy people.
-
-
-This list administrator email address is in the form LISTNAME-owner@DOMAIN, where LISTNAME is the name of the list (eg: mailman-users) and DOMAIN is
-the name of the server (eg: python.org).
-This email address,
-along with the email addresses of specific administrators, is given on the
-bottom of the list information pages. See Section 3.1 for more
-information on finding the list information page for your list
-
-
-Since subscribing (joining) and unsubscribing (leaving) lists are often the
-only things a list member needs to know, these can both be done without
-requiring you to know a password.
-
-
Look for the section marked ``Subscribing to LISTNAME'' and fill in the
- boxes. You can fill in the following:
-
-
-
You must enter your email address.
-
-
You may choose to supply your real name.
-
-
You may choose a password. If you do not choose one, Mailman will
- generate one for you.
-
-
-Warning:
-Do NOT use a valuable password, since this
- password may occasionally be mailed to you in plain text.
-
-
If the list supports more than one language, you may be able to
- choose your preferred language. Note:
-This setting does not affect
- posts to the list, only Mailman texts that come from the list software,
- such as your member
- options page.
-
-
-
-
-
Press the subscribe button. A new page should appear telling you
- that your subscription request has been received. This page will provide
- you with further instructions, such as the need to wait for and reply to a
- confirmation messages, depending on the list's subscription policies.
-
-
-
-
-Using the email interface:
-
-
-
Open a mail program which sends mail from the address you want to
- subscribe.
-
-
Send a mail to the list subscription address, which will be in the
- form LISTNAME-join@DOMAIN. The subject and body
- of the message will be ignored, so it doesn't matter what you put there.
-
-
-
-
-After following one of these sets of instructions (you don't need to do
-both!), there are a few possible outcomes depending upon the settings for
-that list.
-
-
-
You may receive an email message asking for confirmation that you
-really want to be subscribed to the list. This is to prevent anyone from
-subscribing you to lists without your permission. Follow the instructions
-given in the message to confirm your wish to be subscribed.
-
-
A moderator may also need
-to confirm your subscription if you are subscribing to a closed list.
-
-
Or
-you may have to wait for a moderator and follow the instructions in
-the confirmation mail.
-
-
-
-
-Once this is done, you will likely receive another message welcoming you to
-the list. This message contains some useful information including your list
-password and some quick links for changing your options, so you may want to
-save it for later reference.
-
-
-Note:
-Subscribing can be done in other ways as well. See
-Appendix A for more advanced email subscribing commands.
-
-
-Don't want to be on a list any more? If you're just going on vacation or
-are too busy to read mails and want to temporarily turn them off, you may want
-to stop mail delivery rather than unsubscribing. This means you keep your
-password and other settings so you can, for example, still have access to
-private list archives. If this is what you'd
-prefer, see Section 7.1 for instructions on disabling mail
-delivery temporarily.
-
-
-If you actually want to leave the list, there are two common ways you can
-unsubscribe from a Mailman mailing list.
-
-
Look for the section marked ``LISTNAME subscribers'' (usually found
- near the bottom of the page).
-
-
There should be a button marked ``Unsubscribe or Edit Options.''
- Enter your email address in the box beside this button and press the
- button.
-
-
You should be brought to a new page which has an ``Unsubscribe''
- button. Press it to unsubscribe and follow the instructions given.
-
-
-
-
-Using the email interface:
-
-
-
Open a mail program which sends mail from the address you want to
- unsubscribe.
-
-
Send a mail to the list unsubscribe address, which will be of the form
- LISTNAME-leave@DOMAIN.
- The subject and body
- of this message will be ignored, so it doesn't matter what you put there.
-
-
-
-
-After following one of these sets of instructions (you don't need to do
-both!), you will be sent a confirmation mail and must follow the
-instructions given in that mail to complete the unsubscription. This is to
-stop people from unsubscribing you without your permission. In addition, a
-moderator may need to approve your unsubscription. (Administrator-approved
-unsubscriptions are uncommon.)
-
-
-If you do not receive this confirmation mail with instructions, make sure
-that you typed your email address correctly (if you were using the web
-interface to unsubscribe) and that the address you tried
-to unsubscribe is, indeed, actually subscribed to that list. For security
-reasons, Mailman generates the same member options page regardless of
-whether the address entered is subscribed or not. This means that people
-cannot use this part of the web interface to find out if someone is
-subscribed to the list, but it also means that it's hard to tell if you just
-made a typo.
-
-
-Once your unsubscription has been processed, you will will probably receive
-another message confirming your unsubscription from the list, and at that
-point you should stop receiving messages.
-
-
-If you wish to skip the confirmation process (for example, you might be
-unsubscribing an address which no longer works), it is possible to bypass it by
-using your password instead and either logging in to your options page using
-it (See Section 3.1), or sending it with your email commands to
-LISTNAME-request (See Appendix A for advanced email
-unsubscription commands). See Section 6.1 for more
-information on getting your password.
-
-
-Your password was either set by you or generated by Mailman when you
-subscribed.
-You probably got a copy of it in a
-welcome message sent when you joined the list, and you may also receive a
-reminder of it every month. It is used to verify your identity to Mailman
-so that only the holder of the password (you!) and the administrators
-can view and change your settings.
-
-
-Warning:
-Do NOT use a valuable password for Mailman, since it can be
-sent in plain text to you.
-
-
-If you've forgotten your password and haven't saved the welcome message or
-any reminder messages, you can always get a reminder through the web interface:
-
-
-
-
-
Go to the list information page for the list from which you wish to
- get your password
- (This will probably be something like
- http://WEBSERVER/mailman/listinfo/LISTNAME)
-
-
Look for the section marked ``LISTNAME subscribers''
- (this section is usually found near the bottom of the page).
-
-
There should be a button marked ``Unsubscribe or Edit Options.''
- Enter your email address in the box beside this button and press the
- button.
-
-
You should be brought to a new page which has an ``Password
- Reminder'' section. Press the ``Remind'' button to have your password
- emailed to you.
-
-
-
-
-If you do not receive the password reminder email after doing this, make sure
-that you typed your
-email address correctly and that the address you used is, indeed, actually
-subscribed to that list. For security reasons, Mailman generates the same
-member options page regardless of whether the address entered is subscribed
-or not. This means that people cannot use this part of the web interface to
-find out if someone is subscribed to the list, but it also means that it's
-hard to tell if you just made a typo.
-
-
-You can also get a reminder using the email interface,
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- password
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
-If you are not sending mail from your subscribed address, you can also
- specify this address by sending the command password address=ADDRESS.
-
- Warning:
-Do NOT use a valuable password, since this
- password may be mailed to you in plain text.
-
-
-From the web interface:
-
-
-
Log in to your member options page. (See Section 3.1 for
- instructions on how to do this.)
-
-
-
-
Look for the password changing boxes on the right-hand side of the
- page and enter your new password in the appropriate boxes, then press the
- button marked ``Change My Password.''
-
-
-
-
-This can also be changed for multiple lists at the same time if you are subscribed to
-more than one list on the same domain. See Section 10.1 for
-information about changing settings globally.
-
-
-From the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- password OLDPASSWORDNEWPASSWORD.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
-If you are not sending mail from your membership address, you can also
- specify this address with address=ADDRESS after NEWPASSWORD.
-
-
-For example, if kathy@here.com wanted to change her mylist
- password from zirc to miko, but she was sending mail from
- her work address kathy@work.com, she could send a message
- to mylist-request@example.com with the subject set to
- password zirc miko address=kathy@here.com.
-
-If you don't wish to the reminder email including your password every month,
-you can disable it from the member options page. (You can always get the
-password mailed out when you actually want it. See
-Section 6.1 for instructions.)
-
-
-Using the web interface:
-
-
-
Log in to your member options page. (See Section 3.1 for
- instructions on how to do this.)
-
-
Look for the section marked ``Get password reminder email for this
- list?'' and change the value accordingly.
-
-
-
-
-This can also be changed for multiple lists at the same time if you are subscribed to
-more than one list on the same domain. See Section 10.1 for
-information about changing settings globally.
-
-
-Using the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set reminders on or set reminders off.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``on'' to receive reminders, and ``off'' to stop receiving
- reminders.
-
-
-7.1 How do I turn mail delivery on or off?
- (delivery option)
-
-
-
-You may wish to temporarily stop getting messages from the
-list without having to unsubscribe.
-If you disable mail delivery, you will no longer receive messages, but will
-still be a subscriber and will retain your password and other settings.
-
-
-This can be handy in a many different cases. For example, you could be
-going on vacation or need a break from the list because you're too busy to
-read any extra mail.
-Many mailing lists also allow only subscribers to post to the list, so if you
-commonly send mail from more than one address (eg, one address for at home
-and another for when you're travelling), you may want to have more than
-one subscribed account, but have only one of them actually receive mail.
-You can also use this as a way to read private archives even on a list which
-may be too busy for you to have sent directly to your mailbox. All you need to do is subscribe, disable mail delivery, and use your password and email to
-log in to the archives.
-
-
-To disable/enable mail delivery using the web interface:
-
-
-
Log in to your options page. (See Section 3.1 for instructions.)
-
-
Go down to the section marked ``Mail delivery'' and select ``Disabled''
- to stop receiving mail, and ``Enabled'' to start receiving mail.
-
-
-
-
-This can also be changed for multiple lists at the same time if you are subscribed to
-more than one list on the same domain. See Section 10.1 for
-information about changing settings globally.
-
-
-To disable/enable mail delivery using the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set delivery off or set delivery on.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``off'' to stop receiving posts, and ``on'' to start
- receiving them again.
-
-
-7.2 How can I avoid getting duplicate messages? (duplicates option)
-
-
-
-
-Mailman can't completely stop you from getting duplicate messages, but it
-can help. One common reason people get multiple copies of a mail is that
-the sender has used a ``group reply'' function to send mail to both the list
-and some number of individuals. If you want to avoid getting these messages,
-Mailman can be set to check and see if you are in the To: or
-CC: lines of the message. If your address appears there, then
-Mailman can be told not to deliver another copy to you. This means you get
-only the copy sent by the original sender, and not a copy which been altered by
-Mailman (to include headers and footers, strip attachments, etc.).
-
-
-To turn this on or off using the web interface:
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Scroll down to the bottom of the page to the section marked
- ``Avoid duplicate copies of messages?'' and change the value accordingly.
-
-
-
-
-This can also be changed for multiple lists at the same time if you are subscribed to
-more than one list on the same domain. See Section 10.1 for
-information about changing settings globally.
-
-
-To turn this on or off using the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set duplicates on or set duplicates off.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``on'' to receive list copies of messages already sent
- to you, set it to ``off'' to avoid receiving these duplicates.
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
In the section marked ``Changing your LISTNAME membership information,''
- enter your new address.
-
-
If you wish to change your address for all subscriptions using the
- old address, select the ``Change globally'' box. If you have subscriptions
- under another address or for lists on a different domain, these will have
- to be done separately. See Section 10.1 for more
- information about changing settings globally.
-
-
-
-
-A confirmation message will be sent to your new address, and the change will
-not happen until you confirm the change by following the instructions in that
-message.
-
-
-There is no special way to do this from the email interface, but you can
-subscribe and unsubscribe for more or less the same effect. (See
-Sections 5.1 and 5.2 for more information
-on subscribing and unsubscribing.)
-
-
-
-7.4 How do I stop or start getting copies of my own posts? (myposts
- option)
-
-By default in Mailman, you get a copy of every post you send to the list.
-Some people like this since it lets them know when the post has gone through
-and means they have a copy of their own words with the rest of a discussion,
-but others don't want to bother downloading copies of their own posts.
-
-
-Note:
-This option has no effect if you are receiving digests.
-
-
-You may also want to see Section 7.5, which discusses
-acknowledgement emails for posts sent to the list.
-
-
-To set this using the web interface:
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Look for the section marked ``Receive your own posts to the list?''
- Set it to ``Yes'' to receive copies of your own posts, and ``No'' to avoid
- receiving them.
-
-
-
-
-To set this using the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set myposts on or set myposts off.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``on'' to receive copies of your own posts, and ``off''
- to avoid receiving them.
-
-
-Release 2.1, documentation updated on 7 October 2003.
-
-
-
-
-
diff --git a/admin/www/mailman-member/node24.html b/admin/www/mailman-member/node24.html
deleted file mode 100644
index 96b043db..00000000
--- a/admin/www/mailman-member/node24.html
+++ /dev/null
@@ -1,153 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-7.5 How can I get Mailman to tell me when my post has been received
-by the list? (ack option)
-
-
-
-
-7.5 How can I get Mailman to tell me when my post has been received
-by the list? (ack option)
-
-
-
-On most lists, you will simply receive a copy of your mail when it has gone
-through the list software, but if this is disabled (See
-Section 7.4), your list mail delivery is disabled (See
-Section 7.1), you are not subscribed to that topic (See
-Section 9.2) or you
-simply want an extra acknowledgement from the system, this option may
-be useful to you.
-
-
-Note:
-If you are not subscribed to the list, this option cannot be used.
-You must either check the archives yourself (if the list has public archives),
-ask someone who is subscribed to the list, or subscribe to use this option.
-
-
-To set this using the web interface:
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Look for the section marked ``Receive acknowledgement mail when you
- send mail to the list?''
- Set it to ``Yes'' to receive a mail letting you know your post has been
- received, and ``No'' to avoid receiving such an acknowledgement.
-
-
-
-
-To set this using the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set ack on or set ack off.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``on'' if you wish to receive mail letting you know your
- post has been received, and ``off'' to avoid receiving such an
- acknowledgement.
-
No one has sent any mail to the list(s) you're on for a little while.
-
-
-To check if this is the case, try visiting the archives of the list
- (assuming that the list has archives). If the list has no archives, you
- may have to ask another subscriber. (See Section 3.1 for help
- in finding the list archives.)
-
-
-Note:
-Generally, it is considered
- impolite to send test messages to the entire list.
- If you feel a need to test that the list is working and for some reason you
- cannot simply compose a regular message to the list, it is less disruptive
- to send a help message to
- the list request address (LISTNAME-request@DOMAIN) to see if that works,
- or to contact the list
- administrator (LISTNAME-owner@DOMAIN) to ask if the list is working.
-
-
-
-
You were bouncing mail and have had mail delivery (temporarily)
- disabled by the list software.
-
-
-If your mail provider ``bounces'' too many messages (that is, it tells
- Mailman that the message could not be delivered)
- Mailman eventually stops trying to send you mail. This feature allows
- Mailman to gracefully handle addresses which no longer exist (for example,
- the subscriber has found a new Internet service provider and forgot to
- unsubscribe the old address), as well
- as addresses which are temporarily out-of-service (for example, the
- subscriber has used up all of the allotted space for his or her email
- account, or the subscriber's mail provider is experiencing difficulties).
-
-
-Even if you are unaware of any difficulties with your mail provider, it
- is a good idea to check this. Some popular webmail providers and
- internet servers are not as reliable as one might assume, nor is the
- internet as a whole. You may want to also send yourself a test message
- from another account or ask a friend to send you a test message to make
- sure your subscribed address is working.
-
-
-To check if this may be the reason you are not receiving messages, log in
- to the your options page (See
- Section 3.1 for more details on how to do this) and
- look at your options.
- If your subscription has been disabled or Mailman has received bounces from
- your email address, there will be a big banner at the top of this page.
-
-
-To re-enable mail delivery, look for an option marked ``Mail Delivery'' and
- set it to ``Enabled'' to start receiving mail again.
- To get rid of your bounce score, you can disable and then re-enable delivery.
- For more instructions on disabling or enabling mail delivery,
- see Section 7.1.
-
-
-Note:
-Even if you have not been disabled at the time you check, you could be
- bouncing messages and not have reached the threshold for your
- subscription to be disabled. You may need to check again.
-
-
-
-
There is a delay or break in the networks between you and the
- list server.
-
-
-No matter what many of us would like, the internet is not 100%
- reliable, nor is it always fast. Sometimes, messages simply take a long
- time to get to you. Try to be patient, especially if the server is far
- (in terms of networks, not geography, although often one implies the other)
- from your internet service provider.
-
-
-To check if this might be causing your problem, you can try pinging
- the list server or tracing the route between you and it. (Instructions
- on how to do this varies from platform to platform, so you may want to
- use a search engine to find those appropriate for you.)
-
-
-
-
The mail server or Mailman might not be functioning properly. This
- can happen if the system is overloaded with viruses or spam and the mail
- system that hosts Mailman has trouble keeping up.
-
-
-To test if this is a case, try visiting the list's web interface and
- try sending a message to LISTNAME-request@DOMAIN with the command
- ``help'' (without the quotes) in the Subject:. If
- neither of these works after a reasonable length of time, this may be
- the problem. You may wish to contact either the list or site
- administrator(s).
-
-
-8.1 How can I start or stop getting the list posts grouped into one
-big email? (digest option)
-
-
-
-Groups of posts are called ``digests'' in Mailman. Rather than get messages
-one at a time, you can get messages grouped together. On a moderately busy
-list, this typically means you get one email per day, although it may be
-more or less frequent depending upon the list.
-
-
-You may also want to look at Section 8.2 which discusses MIME
-and plain text digests.
-
-
-To turn digest mode on or off using the web interface,
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Look for the section marked ``Set Digest Mode.''
-
-
-Set it to ``On'' to
- receive messages bundled together in digests. Set it to ``Off'' to
- receive posts separately.
-
-
-
-
-To turn digest mode on or off using the email interface,
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set digest plain or set digest mime or set digest off.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``off'' if you wish to receive individual posts separately,
- and to ``plain'' or ``mime'' to receive posts grouped into one large mail.
- See Section 8.2 for more information on plain versus MIME
- digests.
-
-
-8.2 What are MIME and Plain Text Digests? How do I change which one
-I get? (digest option)
-
-
-
-MIME is short for Multipurpose Internet Mail Extensions. It is used to
-send things by email which are not necessarily simple plain text. (For
-example, MIME would be used if you were sending a picture of your dog to
-a friend.)
-
-
-A MIME digest has each message as an attachment inside the message, along
-with a summary table of contents.
-
-
-A plain text digest is a simpler form of digest, which should be readable
-even in mail readers which don't support MIME. The messages are simply put
-one after the other into one large text message.
-
-
-Most modern mail programs do support MIME, so you only need to choose
-plain text digests if you are having trouble reading the MIME ones.
-
-
-Note:
-This option has no effect if you are not receiving mail bunched
-as digests. (See Section 8.1 for more information on
-receiving mail as digests.)
-
-
-To set your digest type using the web interface:
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Look for the section marked ``Get MIME or Plain Text Digests?.''
-
-
-Set it to ``MIME'' to receive digests in MIME format, or ``Plain text'' to
- receive digests in plain text format.
-
-
-
-
-This can also be changed for multiple lists at the same time if you are subscribed to
-more than one list on the same domain. See Section 10.1 for
-information about changing settings globally.
-
-
-To set your digest type using the email interface,
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set digest plain or set digest mime.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``plain'' to get posts bundled into a plain text digest,
- or ``mime'' to get posts bundled together into a MIME digest.
-
-Some lists are set up so that different topics are handled by Mailman.
-For example, the courses list on Linuxchix.org is a discussion list for
-courses being run by linuxchix members, and often there are several courses
-being run at the same time.
-(eg: Networking for beginners, C programming, LATEX document mark up.)
-Each of the courses being run is associated with a separate topic on the list so that people
-can choose only to receive the course they want to take.
-
-
-These
-topics must be configured by the list administrator, but it is the
-responsibility of each poster to make sure that their post is put with
-the correct topic. Usually, this means adding a word or tag of some type to the
-subject line (eg: [Networking] What type of cables do I need?) or making
-sure the Keywords: line has the right information. (By default,
-you can put a Keywords: section in the beginning of the body
-of your message, but this can be configured by your list administrator.)
-Note that these tags are case-insensitive.
-
-
-This document is intended to help the members of a Mailman 2.1 mailing list
-learn to use the features available to them. It covers the use of the
-web and email interfaces for subscribing and unsubscribing, changing
-member options, getting password reminders and other subscriber-level
-tasks. It also answers some common questions of interest to Mailman list
-members.
-
-
-Information for list and site administrators is provided in
-other documents.
-
-
-This document need not be read in order. If you are simply looking for
-an answer to a specific question, jump to the appropriate place and
-references to other sections will be provided if necessary or potentially
-helpful.
-
-
-Note:
-For the purposes of this document,
-we assume that the reader is familiar with common terms related to email (eg:
-Subject line, body of the message) and web sites (eg: drop-down box, button) or
-can look them up. We also assume that the reader can already use his or her
-email program and web browser well enough that instructions such as ``send email
-to this address'' or ``visit this web page'' or ``fill in the form provided'' are
-clear. If you are not familiar with these actions, you may want to consult
-other documentation to learn how to do these things with your particular
-setup.
-
-
-
-9.1 How do I make sure that my post has the right
- topic?
-
-
-
-When a list administrator defines a topic, he or she sets three things:
-
-
-
a topic name
-
-
a regular expression (regexp.)
-
-
a description
-
-
-
-
-You can view this information by logging in to your member options page.
- (See Section 3.1 for more details on how to do this.) and
-clicking on the ``details'' link for any topic that interests you.
-
-
-To post on a given topic, you need to make sure that the
-Keywords: or Subject: headers in a message
-match the regular expression for that topic.
-A regular expression is a pattern which may match more than one thing.
-Regular expressions can actually be fairly complex, so you may want to
-just ask the list administrator if you don't know how to make
-heads or tails of the expression given.
-
-
-If you really want to know more about regular expressions, read on, but for the
-most part, your list administrator should include in the topic description what
-you need to add to your Keywords or Subject line to match the topic pattern.
-
-
-Most Mailman topic expressions will be fairly simple regular expressions, so
-in this document we will simply give you some common examples. Regular
-expressions are a bit too complex to teach in a few lines here, so if you
-really want to understand how the regular expressions work, you should
-find a tutorial or reference elsewhere. (For example, DevShed has a decent
-tutorial at
-http://www.devshed.com/Server_Side/Administration/RegExp/)
-
-
-Here are some examples of possible regular expressions and matching lines:
-
-
-
-
-
-
Regular expression
-
Matching lines
-
-
-
-
zuff
-
Keywords: zuff
-
zuff
-
Keywords: ZUFF
-
zuff
-
Keywords: Zuff
-
zuff
-
Keywords: amaryllis, zuff, applesauce
-
zuff
-
Subject: [zuff] Do you have the right stuff for zuff?
-
zuff
-
Subject: Do you have the right stuff for zuff?
-
zuff
-
Subject: What is zuff?
-
-
\[zuff\]
-
Keywords: [zuff]
-
\[zuff\]
-
Subject: [zuff] Do you have the right stuff?
-
\[zuff\]
-
Subject: Online zuff tutorials (was Re: [zuff] What is zuff?)
-
-
-
-A few notes:
-
-
-
The matching is case-insensitive, so if zuff matches, so will ZUFF,
- zuFF, and any other variations in capitalization.
-
-
Some characters have special meaning in a regular expression, so
- to match those characters specifically, they must be ``escaped'' with a
- backslash (\). As you can see in the above example,
- [ and ] are such characters. (Others include ``.'', ``?'', and ``*'').
- The backslash is also used for other things (I wasn't kidding about
- regular expressions being complex: consult other documentation
- for details about other uses of the backslash character), but this
- is the most likely use in a topic expression.
-
-
-9.2 How do I subscribe to all or only some topics on a
- list?
-
-
-
-If topics have been set up by your mailing list administrator, you can
-choose to subscribe to only part of a list by selecting the topics you
-want to receive.
-
-
-If you wish to get all messages sent to the list, make sure you
-are not subscribed to any topics.
-
-
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Look for the section marked ``Which topic categories would you like
- to subscribe to?''
-
-
-If any topics are defined, you can select those you wish. If you do
- not select any topics of interest, you will receive all posts
- sent to the list.
-
-
-
-
-You probably also want to look at Section 9.3 which discusses
-changing your settings for messages where no topic is set.
-
-
-
-9.3 How do I get or avoid getting messages with no topic set?
-
-
-Some messages will not match any predefined topic pattern. You can choose to
-receive or ignore such non-matching messages.
-If you wish to get all messages sent to the list, make sure you are
-not subscribed to any specific topic. (See Section 9.2.)
-
-
-If you are only subscribed to some topics, you can either choose to either
-receive or not receive messages with no topic set, much the way you can
-choose to subscribe only to certain topics.
-
-
-To change this setting,
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
Look for the section marked ``Do you want to receive message that do
- not match any topic filter?''
-
-
-If you wish to receive messages with no topic set, select ``Yes.'' If you
- do not wish to receive such messages, choose ``No.''
-
-
-
-
-This setting has no effect if you are not subscribed to any topics.
-
-
-
-10.1 Change Globally? Set Globally? What does that mean?
-
-
-
-
-For some of the options given in your member options page, there is a
-checkbox which says ``Change Globally'' or ``Set Globally.''
-This means that if you change this
-option, you can also have the change made for all your other
-subscriptions on the same domain.
-This can be handy if, for example, you
-want to make sure all your passwords are the same, or you are going on
-vacation and want to turn off mail delivery from all the lists.
-
-
-
-10.2 How do I change my name as Mailman knows it?
-
-
-
-
-To change your subscription name,
-
-
-
Log in to your member options page. (See Section 3.1
- for more details on how to do this.)
-
-
In the section marked ``Changing your LISTNAME membership information,''
- enter your new name in the appropriate box.
-
-
-
-
-This can also be changed for multiple lists at the same time if you are subscribed to
-more than one list on the same domain. See Section 10.1 for
-information about changing settings globally.
-
-
-Note:
-You do not need to have a subscription name set.
-
-
-Mailman is multi-lingual, meaning its interface has been translated to many
-different languages. Your list administrator can enable various languages for
-their use when interacting with Mailman.
-(For a complete listing of the languages see
-http://www.list.org/i18n.html.) If your list has other languages
-enabled, you may be able to have the web interface, etc. in a language of your
-choice.
-
-
-Note:
-This does NOT necessarily mean that all the posts sent to the list will
-be in the language you selected. Only the pre-prepared texts presented by
-Mailman will be affected by this setting. Posts are in whatever language the
-poster uses.
-
-
-Your preferred language is set when you subscribe (see
-Section5.1), and can be changed later if the list supports
-more than one language.
-
-
-To change your preferred language in Mailman,
-
-
-
Log in to your member options page. (See Section 3.1 for
- instructions on how to do this.)
-
-
Go to the section marked ``What language do you prefer?'' and choose
- the appropriate language from the drop-down list. If there is no
- drop-down list of languages, the list you are on probably only supports
- one language.
-
-
-
-
-If your list does not support the language you would prefer to use, you may
-contact the list administrator (LISTNAME-owner@DOMAIN) to see if it can be
-added, but remember that this may mean some work that the list and/or site
-administrator(s) do not have time or the ability to do.
-
-
-If your language of choice is not available because no translation
-exists for Mailman, please consider volunteering your time as a translator.
-For more information you may want to consult the mailman-i18n mailing
-list at http://mail.python.org/mailman/listinfo/mailman-i18n. The
-current status of internationalization efforts is available at
-http://www.list.org/i18n.html.
-
-
-Note:
-i18n is a common short-hand for ``internationalization'' because the word
-starts with an i, ends with an n, and has 18 letters in between. If you mumble
-a bit, i18n even sounds a bit like ``internationalization.''
-
-
-
-10.4 How do I avoid having my name appear on the subscribers list?
- (the hide option)
-
-
-
-If you do not want to have your email address show up on the subscriber list
-for any reason, you can opt to have it concealed.
-
-
-Common reasons for doing this include avoiding unsolicited bulk email (spam).
-By default, the subscribers list is obscured to hinder spam harvesters,
-but if you feel this is insufficient it's easy enough to remove your address
-from the subscriber list given in the information pages or by email request.
-(Note that this does not conceal your address from the list administrators.)
-You may wish to see Section 11.2 for more information on what
-Mailman can do to help avoid spam.
-
-
-To change this setting using the web interface:
-
-
-
Log in to your member options page. (See Section 3.1 for
- instructions on how to do this.)
-
-
Go to the section marked ``Conceal yourself from subscriber list?'' and
- choose ``Yes'' to hide your name from the list, or ``No'' to allow your name
- to appear on the list.
-
-
-
-
-To change this setting using the email interface:
-
-
-
Send a mail to LISTNAME-request@DOMAIN with the command
- set hide on or set hide off.
-
-
-Commands can appear
- in either the body or the subject of the message. (See
- Section 3.2 for more information about sending mail
- commands.)
-
-
Set it to ``on'' to conceal your email address from the membership
- list, or ``off'' to stop concealing your address.
-
-If the list is being archived, previously posted messages can be viewed by
-going to the archive's web pages, a link to which can be found on the list
-information page and in the List-Archive: header of every posted
-message (unless your list administrator has disabled such headers).
-Many mail programs hide the List-Archive: mail header, so you may
-have to tell your mail program to allow you to view full headers before you
-will be able to see it.
-
-
-Sections of this document have been borrowed from the List Administrator Manual
-found in Mailman CVS, which was written by Barry A. Warsaw, and from the in-line
-help for Mailman 2.1.
-
-
-The rest of this manual has been written by Terri Oda.
-Terri has been maintaining mailing lists since the year she attained
-voting age in Canada, although the two are not related. She currently
-oversees the mailing lists at Linuxchix.org, as well as several smaller
-servers. In the world outside of list administration, Terri is doing
-work with an artificial life spam detector, and is actually more of a
-programmer than technical writer.
-
-
-Thanks to Margaret McCarthy, Jason Walton and Barry Warsaw for their help
-in proofreading and otherwise improving this manual.
-
-
-Thanks also to Ikeda Soji, who has made a Japanese translation of this document.
-
-
-
-11.2 What does Mailman do to help protect me from unsolicited bulk email
-(spam)?
-
-
-
-A technical list's archives may include answers to a range of
-different questions. Often, the people who have posted these answers would
-be happy to help someone who doesn't quite understand the answer, and don't
-mind giving their address out for that purpose. But
-although it would be wonderful if everyone could contact each other easily,
-we also want to make sure that the list and list archives are not abused by
-people who send spam.
-
-
-To make a range of options available to list administrators, Mailman allows
-a variety of configurations to help protect email addresses.
-Many of these settings are optional to the list administrator, so your
-particular list may be set up in different ways. List administrators
-must walk a fine line between protecting subscribers and making it difficult
-for people to get in touch.
-
-
-
-
-
Subscriber lists
-
-
-
The list administrator can choose to have the subscriber list
- public, viewable only to list members, or viewable only to list
- administrators.
-
-
The subscriber list is shown with the addresses obscured to
- make it difficult for spam harvesters to collect your address.
-
-
You can choose to have your address hidden from the subscriber
- list. (See Section 10.4 for more information.)
-
-
Note:
-The entire subscriber list is always available to the
- list administrators.
-
-
-
-
-
-
-
List archives
-
-
-
The list administrator can choose for the archives to be public,
- viewable only to members (private), or completely unavailable.
-
-
The HTML archives which are created by Pipermail (the
- archiving program which comes default with Mailman) contain only
- obscured addresses. Other archiving programs are available and can
- do different levels of obfuscation to make addresses less readable.
-
-
If you wish to be more sure, you can set the mail header
- ``X-No-archive: yes'' and Mailman will not archive your
- posts. Similarly, you can set the mail header
- ``X-Archive: no'' to disable archiving.
-
-
-Warning:
-This does not stop other members from quoting your posts,
- possibly even including your email address.
-
-
-
-
-
-
-
Limited posting to the lists
-
-
-
The list administrator can choose who can post to the list.
- Most lists are either moderated (a moderator or administrator
- reviews each posting), set so only subscribers may post to the list,
- or allow anyone to post to the list.
-
-
By allowing only subscribers to post to a list, Mailman often
- blocks all spam and some viruses from being sent through the list.
- As such, this is a fairly common setting used by list administrators.
-
-
-
-
-
-
-
Anonymous lists
-
-
-
Lists can also be made fully anonymous: all identifying
- information about the sender is stripped from the header before the
- message is sent on.
-
-
This is not typically used for anti-spam measures (it has
- other uses), but it could be used in that way if desired.
-
-
-
-
-
-
-
-Of course, many address-obscuring methods can be circumvented by determined
-people, so be aware that the protections used may not be enough.
-
-
Retrieve or change your password. With no arguments, this returns
- your current password. With arguments OLDPASSWORD and NEWPASSWORD
- you can change your password.
-
-
-
-
-
-
-
set ...
-
-
-
Set or view your membership options.
-
-
-Use `set help' (without the quotes) to get a more detailed list of the
- options you can change. This list is also given in
- Appendix B.
-
-
-Use `set show' (without the quotes) to view your current option
- settings.
-
-
Subscribe to this mailing list. Your password must be given to
- unsubscribe or change your options, but if you omit the password, one
- will be generated for you. You may be periodically reminded of your
- password.
-
-
-The next argument may be either: `nodigest' or `digest' (no quotes!).
- If you wish to subscribe an address other than the address you sent
- this request from, you may specify `address=ADDRESS' (no brackets
- around the email address, and no quotes!)
-
-
-
-
-
-
-
unsubscribe [PASSWORD] [address=ADDRESS]
-
-
-
Unsubscribe from the mailing list. If given, your password must match
- your current password. If omitted, a confirmation email will be sent
- to the unsubscribing address. If you wish to unsubscribe an address
- other than the address you sent this request from, you may specify
- `address=ADDRESS' (no brackets around the email address, and no
- quotes!)
-
-
-
-
-
-
-
who [PASSWORD] [address=ADDRESS]
-
-
-
See everyone who is on this mailing list. The roster is limited to
- list members only, and you must supply your membership password to
- retrieve it. If you're posting from an address other than your
- membership address, specify your membership address with
- `address=ADDRESS' (no brackets around the email address, and no
- quotes!)
-
-
View your current option settings. If you're posting from an address
- other than your membership address, specify your membership address
- with `address=ADDRESS' (no brackets around the email address, and no
- quotes!).
-
-
-
-
-
-
-
set authenticate PASSWORD [address=ADDRESS]
-
-
-
To set any of your options, you must include this command first, along
- with your membership password. If you're posting from an address
- other than your membership address, specify your membership address
- with `address=ADDRESS' (no brackets around the email address,
- and no quotes!).
-
-
-
-
-
-
-
set ack on
-
-set ack off
-
-
-
When the `ack' option is turned on, you will receive an
- acknowledgement message whenever you post a message to the list.
-
-
-
-
-
-
-
set digest plain
-
-set digest mime
-
-set digest off
-
-
-
When the `digest' option is turned off, you will receive postings
- immediately when they are posted. Use `set digest plain' if instead
- you want to receive postings bundled into a plain text digest
- (i.e. RFC 1153 digest). Use `set digest mime' if instead you want to
- receive postings bundled together into a MIME digest.
-
-
-
-
-
-
-
set delivery on
-
-set delivery off
-
-
-
Turn delivery on or off. This does not unsubscribe you, but instead
- tells Mailman not to deliver messages to you for now. This is useful
- if you're going on vacation. Be sure to use `set delivery on' when
- you return from vacation!
-
-
-
-
-
-
-
set myposts on
-
-set myposts off
-
-
-
Use `set myposts off' to avoid receiving copies of messages you post to
- the list. This has no effect if you're receiving digests.
-
-
-
-
-
-
-
set hide on
-
-set hide off
-
-
-
Use `set hide on' to conceal your email address when people request
- the membership list.
-
-
-
-
-
-
-
set duplicates on
-
-set duplicates off
-
-
-
Use `set duplicates off' if you want Mailman not to send you messages
- if your address is explicitly mentioned in the To: or Cc: fields of
- the message. This can reduce the number of duplicate postings you
- will receive.
-
-
-
-
-
-
-
set reminders on
-
-set reminders off
-
-
-
Use `set reminders off' if you want to disable the monthly password
- reminder for this mailing list.
-
-
-A mailing list is simply a list of addresses to which the same information
-is being sent. If you were a magazine publisher, you would have a list of
-the mailing addresses of all the subscribers to the magazine. In the case
-of an electronic mailing list, we use a list of email addresses from people
-interested in hearing about or discussing a given topic.
-
-
-Two common types of email mailing lists are announcement lists and discussion
-lists.
-
-
-Announcement lists are used so that one person or group can send
-announcements to a group of people, much like a magazine publisher's mailing
-list is used to send out magazines. For example, a band may use an
-announcement mailing list to let their fan base know about their upcoming
-concerts.
-
-
-A discussion list allows a group of people to discuss topics amongst
-themselves, with everyone able to send mail to the list and have it distributed
-to everyone in the group. This discussion may also be moderated, so only
-selected posts are sent on to the group as a whole, or only certain people are
-allowed to send to the group. For example, a group of model plane enthusiasts
-might use a discussion mailing list to share tips about model construction and
-flying.
-
-
-Some common terms:
-
-
-
A ``post'' typically denotes a message sent to a mailing list.
- (Think of posting a message on a bulletin board.)
-
-
People who are part of an electronic mailing list are usually called
- the list's ``members'' or ``subscribers.''
-
-
``List administrators'' are the people in charge of maintaining that
- one list. Lists may have one or more administrators.
-
-
A list may also have people in charge of reading posts and deciding
- if they should be sent on to all subscribers. These people are called
- list moderators.
-
-
Often more than one electronic mailing list will be run using the same
- piece of software. The person who maintains the software which runs
- the lists is called the ``site administrator.'' Often the site administrator
- also administrates individual lists.
-
-GNU Mailman is software that lets you manage electronic mailing lists. It
-supports a wide range of mailing list types, such as general discussion
-lists and announce-only lists. Mailman has extensive features which make it
-good for list subscribers, such as easy subscription and unsubscription,
-privacy options, and the ability to temporarily stop getting posts from the
-list. The list member features are covered in this document.
-
-
-Mailman also has many features which make it attractive to list and site
-administrators. These features are covered in the list and site administrator
-manuals.
-
-
-Often, it's easier to simply give an example than explain exactly how
-to find the address for your specific list. As such, we'll frequently
-give examples for a fictional list called
-LISTNAME@DOMAIN whose list information page can be found at
-http://WEBSERVER/mailman/listinfo/LISTNAME.
-
-
-Neither of these are
-real addresses, but they show the form of a typical list address.
-The capital letters used for the list-specific parts of each address should
-make it easier to see what should be changed for each
-list. Although specific list configurations may be different, you will
-probably be able to just replace the words given in capital letters with the
-appropriate values for a real list:
-
-
-
-
LISTNAME
-
The name of your list.
-
-
-
DOMAIN
-
The name of the mail server which handles that list.
-
-
-
WEBSERVER
-
The name of the web server which handles the list web interface. This may be the same as DOMAIN, and often refers to the same machine, but does not have to be identical.
-
-
-
-
-As a real-life example, if you are interested in the mailman-users list, you'd
-make the following substitutions: LISTNAME=mailman-users, DOMAIN=python.org, WEBSERVER=mail.python.org. As such, for the
-mailman-users@python.org
-mailing list, the list information page can be found at the URL
-http://mail.python.org/mailman/listinfo/mailman-users. (These, unlike
-most of the examples given in this document, are real addresses.)
-
-
-Most lists will have this information stored in the List-*:
-headers. Many
-mail programs will hide these by default, so you may have to choose to view
-full headers before you can see these informational headers.
-
-
-Mailman has two different interfaces for the list subscriber: the web
-interface and the email interface. Most discussion list subscribers use
-the email interface, since this includes the email address you use to send
-mail to all the subscribers of that list.
-
-
-The interface you use for changing options is largely
-a matter of preference, since most (but not all) of the options which can
-be changed from the web interface can also be changed by email.
- Usually it is easier to use the web interface for
-changing options, since the web interface provides instructions as you go, but
-there are times when people may prefer the email interface, so both are
-provided.
-
-
-The web interface of Mailman is its selling point for many people,
-since it makes it much easier for subscribers and administrators to see
-which options are available, and what these options do.
-
-
-Every mailing list is also accessible by a number of web pages. Note that
-the exact URLs are configurable by the site administrator, so they may be
-different than what's described below. We'll describe the most common
-configuration, but check with your site administrator or hosting
-service for details.
-
-
The listinfo page is the starting point for the subscriber
- interface. As one would assume from the name it's given, it
- contains information about the LISTNAME list.
- Usually all the other subscriber pages can be accessed from this
- point, so you really only need to know this one address.
-
-
This page can also be accessed by going to the listinfo page
- and entering your email address into the box beside the button
- marked ``Unsubscribe or Edit Options'' (this is near the bottom of the
- page).
-
-
-
-
The member options page allows you to log in/out and change your
- list settings, as well as unsubscribe or get a copy of your password
- mailed to you.
-
-
-
-
To log in to your member options page:
- If you are not already logged in, there will be a box near the top for
- you to enter your password. (If you do not know your password, see
- Section 6.1 for more information on getting your
- password.) Enter your password in the box and press the button.
-
-
-
-
Once you are logged in, you will be able to view and change
- all your list settings.
-
-
The list archive pages have copies of the posts sent to the
- mailing list, usually grouped by month. In each monthly group, the
- posts are usually indexed by author, date, thread, and subject.
-
-
-
-
Note:
-Pipermail is the name of the default archiver that
- comes with Mailman. Other archive programs are available.
-
-
-
-
If the archive is private, you will need to supply your
- subscribed email address and your password to log in. (See
- Section 6.1 for more information on getting
- your password.)
-
-
-Mailman is software to help manage email discussion lists, much like
-Majordomo and SmartList. Unlike most similar products, Mailman gives
-each mailing list a web page, and allows users to subscribe,
-unsubscribe, etc. over the web. Even the list manager can administer
-his or her list entirely from the web. Mailman also integrates most
-things people want to do with mailing lists, including archiving,
-mail-to-news gateways, integrated bounce handling, spam prevention,
-email-based admin commands, direct SMTP delivery (with fast bulk
-mailing), support for virtual domains, and more.
-
-
-Mailman runs on most Un*x-like systems, is compatible with most web
-servers and browsers, and most SMTP servers. Mailman requires
-Python version 1.5 or newer.
-Python is a free object-oriented scripting language. A few files are
-written in C for security purposes.
-
-
The manual is still only a set of READMEs provided in the Mailman
-distribution. For now, more information can be found at
-www.list.org.
-
-
-There are several mailing lists devoted to Mailman, which also provide
-nice demonstrations of Mailman!
-
-
-
- Mailman Announce is a read-only list that you can subscribe to
- if you are only interested in release notices and other important
- news. Only the core Mailman developers can post messages to this
- list.
-
-
- Mailman Users is the mailing list to subscribe to if you are
- using Mailman at your site, and may have problems or questions
- relating to installation, use, etc. We'll try to keep the deep
- technical discussions off this list.
-
-
- Mailman Developers is the mailing list to use if you are
- interested in helping us develop Mailman, discuss future
- directions, etc. This is the list for more in-depth technical
- issues.
-
-
- Mailman Checkins is an adjunct list to the publically
- accessible read-only CVS repository. This list is for the
- hardcore developers, or anybody else submitting patches, since we
- really prefer such patches to be generated against the latest
- snapshot. This is a read-only list; only the core Mailman
- developers can post messages to this list. There is no archive.
-
Here are some random rants on Mailman, email, list servers, and
-other fun topics. They should be considered the opinions of the
-authors of the articles only.
-
-
-
-The Dragon De Monsyne created and donated two logos for Mailman which
-you can use to link back to the Mailman website. Sergio I. Rivera donated an
-alternative logo which is preferred by the
-Free Software Foundation.
-
-
Here are some random rants on Mailman, email, list servers, and
-other fun topics. They should be considered the opinions of the
-authors of the articles only.
-
-
-
-The Dragon De Monsyne created and donated two logos for Mailman which
-you can use to link back to the Mailman website. Sergio I. Rivera donated an
-alternative logo which is preferred by the
-Free Software Foundation.
-
-
Mailman currently runs only on GNU/Linux and any other Un*x-like
-operating system, such as *BSD, Solaris, etc. It works on
-MacOS X but not on MacOS 9. It probably does not work
-on Windows, although it's possible you could get it running on a
-Cygwin system (please let the developer
-community know if you have success with this!)
-
-
You must have the
-Python
-interpreter installed somewhere on your system. Currently Python 2.1
-or newer is required, with Python 2.3 or 2.4 being recommended. Mailman
-should work with latest patch release on any Python branch from 2.1 to
-2.4, which as of this writing (29-Aug-2006) is
-Python 2.1.3,
-Python 2.2.3,
-Python 2.3.5, and
-Python 2.4.3.
-
-
Note that because Python 2.1 and 2.2 are no longer being developed, and
-only critical bugs are being fixed on the Python 2.3 branch, it is recommended
-that you upgrade to Python 2.4. It is possible that support for Python 2.1
-and 2.2 will be dropped in a future release of Mailman. Python 2.3 support
-will most likely be maintained for the duration of the Mailman 2.1 series.
-
-
Most GNU/Linux systems and MacOSX come with Python pre-installed, so you
-just need to make sure you're running an up-to-date version. You can do this
-by executing the following at your shell's command line:
-
-
-
-% python -V
-Python 2.4.3
-
-
-
-If your Python executable doesn't understand the -V
-option, it's definitely too old!
-
-
You must have a mail server (MTA) 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 MTAs such as
-Postfix,
-Exim,
-Sendmail, and
-qmail
-should work just fine.
-
-
You will need an ANSI C compiler to build Mailman's security
-wrappers. All modern versions of the
-GNU C compiler should work well.
diff --git a/admin/www/requirements.html b/admin/www/requirements.html
deleted file mode 100644
index e153e74b..00000000
--- a/admin/www/requirements.html
+++ /dev/null
@@ -1,245 +0,0 @@
-
-
-
-
-
-
-
-
-
Mailman currently runs only on GNU/Linux and any other Un*x-like
-operating system, such as *BSD, Solaris, etc. It works on
-MacOS X but not on MacOS 9. It probably does not work
-on Windows, although it's possible you could get it running on a
-Cygwin system (please let the developer
-community know if you have success with this!)
-
-
You must have the
-Python
-interpreter installed somewhere on your system. Currently Python 2.1
-or newer is required, with Python 2.3 or 2.4 being recommended. Mailman
-should work with latest patch release on any Python branch from 2.1 to
-2.4, which as of this writing (29-Aug-2006) is
-Python 2.1.3,
-Python 2.2.3,
-Python 2.3.5, and
-Python 2.4.3.
-
-
Note that because Python 2.1 and 2.2 are no longer being developed, and
-only critical bugs are being fixed on the Python 2.3 branch, it is recommended
-that you upgrade to Python 2.4. It is possible that support for Python 2.1
-and 2.2 will be dropped in a future release of Mailman. Python 2.3 support
-will most likely be maintained for the duration of the Mailman 2.1 series.
-
-
Most GNU/Linux systems and MacOSX come with Python pre-installed, so you
-just need to make sure you're running an up-to-date version. You can do this
-by executing the following at your shell's command line:
-
-
-
-% python -V
-Python 2.4.3
-
-
-
-If your Python executable doesn't understand the -V
-option, it's definitely too old!
-
-
You must have a mail server (MTA) 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 MTAs such as
-Postfix,
-Exim,
-Sendmail, and
-qmail
-should work just fine.
-
-
You will need an ANSI C compiler to build Mailman's security
-wrappers. All modern versions of the
-GNU C compiler should work well.
-
-
-
-
-
diff --git a/admin/www/reset_pw.py b/admin/www/reset_pw.py
deleted file mode 100644
index fce42cb6..00000000
--- a/admin/www/reset_pw.py
+++ /dev/null
@@ -1,90 +0,0 @@
-#! /usr/bin/env python
-#
-# Copyright (C) 2004 by the Free Software Foundation, Inc.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-# Inspired by Florian Weimer.
-
-"""Reset the passwords for members of a mailing list.
-
-This script resets all the passwords of a mailing list's members. It can also
-be used to reset the lists of all members of all mailing lists, but it is your
-responsibility to let the users know that their passwords have been changed.
-
-This script is intended to be run as a bin/withlist script, i.e.
-
-% bin/withlist -l -r reset_pw listname [options]
-
-Options:
- -v / --verbose
- Print what the script is doing.
-"""
-
-import sys
-import getopt
-
-import paths
-from Mailman import Utils
-from Mailman.i18n import _
-
-
-try:
- True, False
-except NameError:
- True = 1
- False = 0
-
-
-
-def usage(code, msg=''):
- if code:
- fd = sys.stderr
- else:
- fd = sys.stdout
- print >> fd, _(__doc__.replace('%', '%%'))
- if msg:
- print >> fd, msg
- sys.exit(code)
-
-
-
-def reset_pw(mlist, *args):
- try:
- opts, args = getopt.getopt(args, 'v', ['verbose'])
- except getopt.error, msg:
- usage(1, msg)
-
- verbose = False
- for opt, args in opts:
- if opt in ('-v', '--verbose'):
- verbose = True
-
- listname = mlist.internal_name()
- if verbose:
- print _('Changing passwords for list: %(listname)s')
-
- for member in mlist.getMembers():
- randompw = Utils.MakeRandomPassword()
- mlist.setMemberPassword(member, randompw)
- if verbose:
- print _('New password for member %(member)40s: %(randompw)s')
-
- mlist.Save()
-
-
-
-if __name__ == '__main__':
- usage(0)
diff --git a/admin/www/security.ht b/admin/www/security.ht
deleted file mode 100644
index 6ac9473f..00000000
--- a/admin/www/security.ht
+++ /dev/null
@@ -1,12 +0,0 @@
-Title: Mailman security issues
-
-
Mailman security issues
-
-The GNU Mailman developers take security very seriously. All Mailman security
-concerns should be emailed to
-mailman-security at python dot org.
-This is a closed list that reaches the core Mailman developers.
-
-
To ensure the highest security of your Mailman site, it is always best to
-run the latest release. If you are not running the latest release, please
-upgrade before reporting security issues.
diff --git a/admin/www/security.html b/admin/www/security.html
deleted file mode 100644
index f548cf87..00000000
--- a/admin/www/security.html
+++ /dev/null
@@ -1,175 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-The GNU Mailman developers take security very seriously. All Mailman security
-concerns should be emailed to
-mailman-security at python dot org.
-This is a closed list that reaches the core Mailman developers.
-
-
To ensure the highest security of your Mailman site, it is always best to
-run the latest release. If you are not running the latest release, please
-upgrade before reporting security issues.
-
-
The GNU Mailman - Installation
-Manual describes how to build and install Mailman. It contains general
-instructions, as well as specific details for various platforms, mail, and web
-servers. It is also available in
-PDF format (approx. 110k),
-PostScript format, (approx. 129k),
-and
-plain text format (approx. 63k).
-
-
By definition, the site administrator has shell access to the Mailman
-installation, and the proper permissions for total control over Mailman at the
-site. The site admin can edit the Mailman/mm_cfg.py
-configuration file, and can run the various and sundry command line scripts.
-
-
Command line scripts
-
-This is a brief overview of the current crop of command line scripts
-available to the site administrator in the bin directory.
-For more details, run the script with the --help option,
-which will print out the usage synopsis. You must run these
-scripts from the bin directory in the Mailman installation location,
-usually /home/mailman.
-
-
-
add_members
-
Use this script to mass add members to a mailing list. Input
- files are plain text, with one address per line. Command line
- options allow you to add the addresses as digest or regular
- members, select whether various notification emails are sent, and
- choose which list to add the members to.
-
-
arch
-
Use this to rebuild a list's archive. This script can't be used
- to modify a list's raw mbox file, but once you've edited the mbox
- file some other way, you can use this script to regenerate the
- HTML version of the on-line archive.
-
-
change_pw
-
Use this to change the password for a specific mailing list.
-
-
check_db
-
Use this script to check the integrity of a list's
- config.pck and config.pck.last database
- files.
-
-
check_perms
-
Use this script to check, and optionally fix, the permissions of
- the various files in a Mailman installation.
-
-
clone_member
-
Use this script to clone an address on a particular list
- into different address. This is useful when someone is changing
- email addresses and wants to keep all their old configuration
- options. Eventually members will be able to do their own cloning,
- but for now, only the site administrator can do this. Command
- line options let you remove the old address, clone addresses in
- the list managers addresses, etc.
-
-
config_list
-
This is a very powerful script which lets you view and modify a
- list's configuration variables from the command line. E.g. you
- can dump out all the list options into a plain text file (actually
- a valid Python file!), complete with comments explaining each
- variable. Or you can apply the configuration from such a file to
- a particular list.
-
-
Where this might be useful is if you wanted to change the
- web_page_url attribute on every list. You could
- create a file containing only the line
-
-
-
- and then feed this file back to config_list for every
- list on your system. config_list only sets the
- list variables that it finds in the input file.
-
-
digest_arch
-
This script is deprecated.
-
-
dumpdb
-
This script dumps the plain text representation for any .db
- database file. These files usually contain Python marshaled
- dictionaries, and can be found in the qfiles
- directory, the lists/listname directory,
- etc. This script can also be used to print out the contents of a
- pickled message file, which are stored in .pck files.
-
-
find_member
-
Use this script to search all the lists, or some subset of lists,
- for an address matching a regular expression. command line
- options let you also search the list managers as well.
-
-
genaliases
-
Use this script to regenerate the plain text and db alias
- files for Postfix (if you're using Postfix as your MTA).
-
-
list_admins
-
List all the owners of a mailing list.
-
-
list_lists
-
List all, or some subset of, the mailing lists in the system.
-
-
list_members
-
List the members of a mailing list. Command line options let you
- print just the regular or just the digest members, print the
- case-preserved addresses of the members, etc.
-
-
mailmanctl
-
The main qrunner control script. Use this to start, stop, and
- restart the qrunner.
-
-
mmsitepass
-
Use this script to set the site password, which can be used anywhere in
- the system a list or user password can be used.
- Essentially, the site password trumps any other password, so
- choose wisely!
-
-
move_list
-
Use this script when you move Mailman to a new installation location.
-
-
newlist
-
Use this script to create new mailing lists.
-
-
qrunner
-
Use this to run a single qrunner once (for debugging).
-
-
remove_members
-
Use this list to remove members from a mailing list.
-
-
rmlist
-
Use this script to remove a mailing list. By default, a list's
- archives are not removed unless the --archives option
- is given.
-
-
sync_members
-
Use this to synchronize mailing lists in a list's database with a
- plain text file of addresses, similar to what is used for
- add_members. In a sense, this script combines the
- functionality of add_members and
- remove_members. Any addresses in the file that are
- not present in the list roster are added, and any addresses in the
- roster that are not present in the file are removed.
-
-
Command line options let you send various notification emails,
- preview the changes, etc.
-
-
update
-
Don't use this script manually; it is used as part of the
- installation and upgrade procedures.
-
-
version
-
Prints the Mailman version number.
-
-
withlist
-
This is the most powerful and flexible script in Mailman. With it
- you can do all manner of programmatic changes to mailing lists, or
- look at and interactively inspect almost any aspect of Mailman.
- By default, you run this using Python's interactive prompt, like
- so:
-
-
-
- Here you see that you're left at the Python prompt after the list
- has been loaded and instantiated. Note that without the
- --lock option, the list is not locked. List must be
- locked if you plan to make modifications to any attributes (and
- they must be explicitly saved, as withlist does not
- automatically save changes to list objects).
-
-
At the prompt, the global object m is the instantiated
- list object. It's a Python instance so you can do all the normal
- things to it, view or change attributes, or make method calls on
- it.
-
-
Have a look also at the --run option, which lets
- you put your programmatic changes into a Python module (file) and
- run that module over any mailing list you want. This makes
- withlist essentially a framework for easily adding
- your own list-specific command line scripts.
-
-
-
Cron scripts
-
-Mailman comes with a number of scripts that are typically only run by
-cron. However, it is generally okay for the site administrator to run
-these scripts manually, say to force a sending of accumulated digests,
-or to mail out member passwords, etc. You generally run these by
-invoking the Python executable on them, like so:
-
-
-
-% cd /home/mailman
-% python -S cron/senddigests
-
-
-
-The -S option is an optimization and (minor) security
-recommendation; it inhibits Python's implicit import site
-on initialization. Not all of these scripts support the
---help option. Here is a brief description of what the
-cron scripts do:
-
-
-
bumpdigests
-
Bumps the digest volume numbers for the specified lists.
- Resets the issue number to 1.
-
-
checkdbs
-
Checks for ending list requests (posts and subscriptions) and
- mails the list manager if there are any.
-
-
gate_news
-
Polls the NNTP servers for messages and forwards any new messages
- to their mailing list gateways.
-
-
mailpasswds
-
Sends the password reminder emails to all users and all mailing lists.
-
-
nightly_gzip
-
Regenerates the Pipermail gzip'd flat archive files.
-
-
The GNU Mailman - Installation
-Manual describes how to build and install Mailman. It contains general
-instructions, as well as specific details for various platforms, mail, and web
-servers. It is also available in
-PDF format (approx. 110k),
-PostScript format, (approx. 129k),
-and
-plain text format (approx. 63k).
-
-
By definition, the site administrator has shell access to the Mailman
-installation, and the proper permissions for total control over Mailman at the
-site. The site admin can edit the Mailman/mm_cfg.py
-configuration file, and can run the various and sundry command line scripts.
-
-
Command line scripts
-
-This is a brief overview of the current crop of command line scripts
-available to the site administrator in the bin directory.
-For more details, run the script with the --help option,
-which will print out the usage synopsis. You must run these
-scripts from the bin directory in the Mailman installation location,
-usually /home/mailman.
-
-
-
add_members
-
Use this script to mass add members to a mailing list. Input
- files are plain text, with one address per line. Command line
- options allow you to add the addresses as digest or regular
- members, select whether various notification emails are sent, and
- choose which list to add the members to.
-
-
arch
-
Use this to rebuild a list's archive. This script can't be used
- to modify a list's raw mbox file, but once you've edited the mbox
- file some other way, you can use this script to regenerate the
- HTML version of the on-line archive.
-
-
change_pw
-
Use this to change the password for a specific mailing list.
-
-
check_db
-
Use this script to check the integrity of a list's
- config.pck and config.pck.last database
- files.
-
-
check_perms
-
Use this script to check, and optionally fix, the permissions of
- the various files in a Mailman installation.
-
-
clone_member
-
Use this script to clone an address on a particular list
- into different address. This is useful when someone is changing
- email addresses and wants to keep all their old configuration
- options. Eventually members will be able to do their own cloning,
- but for now, only the site administrator can do this. Command
- line options let you remove the old address, clone addresses in
- the list managers addresses, etc.
-
-
config_list
-
This is a very powerful script which lets you view and modify a
- list's configuration variables from the command line. E.g. you
- can dump out all the list options into a plain text file (actually
- a valid Python file!), complete with comments explaining each
- variable. Or you can apply the configuration from such a file to
- a particular list.
-
-
Where this might be useful is if you wanted to change the
- web_page_url attribute on every list. You could
- create a file containing only the line
-
-
-
- and then feed this file back to config_list for every
- list on your system. config_list only sets the
- list variables that it finds in the input file.
-
-
digest_arch
-
This script is deprecated.
-
-
dumpdb
-
This script dumps the plain text representation for any .db
- database file. These files usually contain Python marshaled
- dictionaries, and can be found in the qfiles
- directory, the lists/listname directory,
- etc. This script can also be used to print out the contents of a
- pickled message file, which are stored in .pck files.
-
-
find_member
-
Use this script to search all the lists, or some subset of lists,
- for an address matching a regular expression. command line
- options let you also search the list managers as well.
-
-
genaliases
-
Use this script to regenerate the plain text and db alias
- files for Postfix (if you're using Postfix as your MTA).
-
-
list_admins
-
List all the owners of a mailing list.
-
-
list_lists
-
List all, or some subset of, the mailing lists in the system.
-
-
list_members
-
List the members of a mailing list. Command line options let you
- print just the regular or just the digest members, print the
- case-preserved addresses of the members, etc.
-
-
mailmanctl
-
The main qrunner control script. Use this to start, stop, and
- restart the qrunner.
-
-
mmsitepass
-
Use this script to set the site password, which can be used anywhere in
- the system a list or user password can be used.
- Essentially, the site password trumps any other password, so
- choose wisely!
-
-
move_list
-
Use this script when you move Mailman to a new installation location.
-
-
newlist
-
Use this script to create new mailing lists.
-
-
qrunner
-
Use this to run a single qrunner once (for debugging).
-
-
remove_members
-
Use this list to remove members from a mailing list.
-
-
rmlist
-
Use this script to remove a mailing list. By default, a list's
- archives are not removed unless the --archives option
- is given.
-
-
sync_members
-
Use this to synchronize mailing lists in a list's database with a
- plain text file of addresses, similar to what is used for
- add_members. In a sense, this script combines the
- functionality of add_members and
- remove_members. Any addresses in the file that are
- not present in the list roster are added, and any addresses in the
- roster that are not present in the file are removed.
-
-
Command line options let you send various notification emails,
- preview the changes, etc.
-
-
update
-
Don't use this script manually; it is used as part of the
- installation and upgrade procedures.
-
-
version
-
Prints the Mailman version number.
-
-
withlist
-
This is the most powerful and flexible script in Mailman. With it
- you can do all manner of programmatic changes to mailing lists, or
- look at and interactively inspect almost any aspect of Mailman.
- By default, you run this using Python's interactive prompt, like
- so:
-
-
-
- Here you see that you're left at the Python prompt after the list
- has been loaded and instantiated. Note that without the
- --lock option, the list is not locked. List must be
- locked if you plan to make modifications to any attributes (and
- they must be explicitly saved, as withlist does not
- automatically save changes to list objects).
-
-
At the prompt, the global object m is the instantiated
- list object. It's a Python instance so you can do all the normal
- things to it, view or change attributes, or make method calls on
- it.
-
-
Have a look also at the --run option, which lets
- you put your programmatic changes into a Python module (file) and
- run that module over any mailing list you want. This makes
- withlist essentially a framework for easily adding
- your own list-specific command line scripts.
-
-
-
Cron scripts
-
-Mailman comes with a number of scripts that are typically only run by
-cron. However, it is generally okay for the site administrator to run
-these scripts manually, say to force a sending of accumulated digests,
-or to mail out member passwords, etc. You generally run these by
-invoking the Python executable on them, like so:
-
-
-
-% cd /home/mailman
-% python -S cron/senddigests
-
-
-
-The -S option is an optimization and (minor) security
-recommendation; it inhibits Python's implicit import site
-on initialization. Not all of these scripts support the
---help option. Here is a brief description of what the
-cron scripts do:
-
-
-
bumpdigests
-
Bumps the digest volume numbers for the specified lists.
- Resets the issue number to 1.
-
-
checkdbs
-
Checks for ending list requests (posts and subscriptions) and
- mails the list manager if there are any.
-
-
gate_news
-
Polls the NNTP servers for messages and forwards any new messages
- to their mailing list gateways.
-
-
mailpasswds
-
Sends the password reminder emails to all users and all mailing lists.
-
-
nightly_gzip
-
Regenerates the Pipermail gzip'd flat archive files.
-
-
-Here's the wish list for future versions of Mailman. Many new
- features have been added to Mailman 2.1, and it is currently
- undecided whether the next release will be 2.2 or 3.0.
- Please also see the Mailman design notes wiki at
- http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
-
-
Email Handling
-
-
-
Re-implement the bulk mailer to do DNS lookups and remote MTA delivery directly (optional).
-
-
For low-traffic sites, a queued message could trigger a qrunner process. It would work until all mail was delivered, then sleep
- and exit if no new work arrived.
-
-
Strip any addresses of members who have nodupe turned on, from the Cc headers of the list copy of a message.
-
-
Separate processing for MIME and plaintext digests. E.g. you might want to filter images out of plaintext but not MIME
- digests.
-
-
-
Documentation
-
-
-
A detailed feature list
-
A user's guide
-
A site-admin's guide
-
A list-admin's guide
-
More on-line documentation and UI help
-
A developer's guide w/ architecture and API information
-
manpages for the scripts in bin and cron
-
Integrate Christopher Kolar's documentation
-
-
General Web UI
-
-
-
NO DEAD ENDS and every web page is reachable.
-
All web UI must be configurable so that it more easily integrates into an existing site's design. Probably means using
- a better template language/system like Zope's Presentation
- Templates, Quixote, or PHP.
-
-
Default UI should add a navigation sidebar to all web pages.
-
Web pages should never mention disabled features.
-
Allow a site admin and list admins to categorize lists, so that they can be better organized on the listinfo and admin overview
- pages.
-
-
-
List Administration
-
-
-
Allow the moderator to edit posts being held for approval (make it evident, either through a header or other means that the
- message was edited by the moderator).
-
-
Allow the admin to disable option settings by users
-
Allow admins to block nomail settings
-
Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes
- very useful, but could be dangerous!)
-
-
New moderation choice: archive but don't send to list.
-
New moderation choice: annotate and send to author for resubmittal. Or just be able to annotate the message for
- multiple moderator scenarios.
-
-
Better integration with moderated newsgroups (and allow some addresses to bypass even that moderation and be delivered to a
- secondary channel, like moderators@isc.org).
-
-
Allow a list to be marked `disabled' so things like the replybot still works, and the archives are still available, but mail
- posted to the list is always returned unsent.
-
-
Ability to `sideline' some messages in the moderation queue
-
Hook moderation up to a whitelist a la TMDA. A non-member message gets held in a non-admindb queue, and the sender gets a
- confirmation message. When they confirm, we moderate the
- message as normal, but if they don't we assume it's spam (after
- some period of time) and discard it. The admin should be able
- to see all these super-quarantined messages with the flip of a
- button.
-
-
Add a moderation option to pass through any message which is a reply to a message previously distributed through the list, even
- if it comes from a non-member. Treat that non-member as a
- member for the duration of the thread. Use In-Reply-To,
- References and Message-ID to match these up.
-
-
When a held message is forwarded (for admin editing and approved resend) there should be a way to auto-discard the held message
- when the approved resend is received.
-
-
Have an option to sort the list of members by real name or email address.
-
-
Test a message for all hold criteria, record them all instead of just the first match, and do a SpamAssassin like scoring to
- decide whether the message should get held or not.
-
-
-
List Membership
-
-
-
Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever
- address they want to whichever list, with different options per
- subscription.
-
-
Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this)
-
-
More flexible digests: index digests (subject and authors only, with URLs to retrieve the article)
-
-
Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.
-
-
Keep user-centric stats, such as the date the user was subscribed, the date of their last change to their account, the
- date they last sent a message through the list. Perhaps also
- log each message they send through the list.
-
-
-
Site Administration
-
-
-
Allow the site admin to define list styles or themes, and list admins to choose one of the canned styles to apply to their
- list.
-
-
Allow the site admin to send an email message to all the list admins using a mechanism similar to the Urgent: header (possibly
- by addressing it to mailman@site.dom).
-
-
-
Other Usability Improvments
-
-
-
A better strategy is needed for sub-lists and super-lists, including dealing with the resulting password reminders and
- authorization to modify the sub & superlists.
-
-
Add a limit on the number of posts from any one individual within a period of time (1 post per day, 10 per week, etc).
- Also, limits on mailbacks, infos, etc.
-
-
-
Mailcmd interface
-
-
-
Provide an email interface to all administrative commands
-
Allow email unsubs from matching address to unsubscribe, possibly adding an "allow open unsubscribes" option to control
- this. Also, adding a confirmation with click-thru confirmation
- to resubscribe.
-
-
For email subscribes, keep an audit of where requests are coming from, and send the original request headers in the confirmation
- message. Helps track down subscribe bombs.
-
-
Use a real transactional database for all information, and allow various bits of information to come from different sources (a
- relational database, ZODB, LDAP, etc)
-
-
Member profiles
-
Allow lists of the same name in two different virtual domains
-
Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc.
-
-
Implement something like Roundup's nosy lists, maybe even integrate with Roundup.
-
-
Split Mailman into libraries so, e.g. the delivery part could be used by other projects.
-
-
-
Bounce handling
-
-
-
Add more patterns for bounce handling (never ending)
-
Send mail to people who are being removed without their knowledge (even though they're likely not to get it).
-
-
-
Pipermail + Archiving mechanism
-
-
-
Search engine for archives
-
Provide downloadable tar.gz's of the html archives
-
sort by date should go most-recent to oldest
-
allow list owner to edit archive messages
-
optional form front-end to public interfaces as a filter to address harvesters.
-
-
In general the whole Pipermail subsystem needs a good rewrite.
-
Write an API between Mailman and the archiver so that message footers can contain the URL to the archived message.
-
-
-
Code cleanup
-
-
-
Turn all remaining string exceptions into class exceptions
-
-Here's the wish list for future versions of Mailman. Many new
- features have been added to Mailman 2.1, and it is currently
- undecided whether the next release will be 2.2 or 3.0.
- Please also see the Mailman design notes wiki at
- http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
-
-
Email Handling
-
-
-
Re-implement the bulk mailer to do DNS lookups and remote MTA delivery directly (optional).
-
-
For low-traffic sites, a queued message could trigger a qrunner process. It would work until all mail was delivered, then sleep
- and exit if no new work arrived.
-
-
Strip any addresses of members who have nodupe turned on, from the Cc headers of the list copy of a message.
-
-
Separate processing for MIME and plaintext digests. E.g. you might want to filter images out of plaintext but not MIME
- digests.
-
-
-
Documentation
-
-
-
A detailed feature list
-
A user's guide
-
A site-admin's guide
-
A list-admin's guide
-
More on-line documentation and UI help
-
A developer's guide w/ architecture and API information
-
manpages for the scripts in bin and cron
-
Integrate Christopher Kolar's documentation
-
-
General Web UI
-
-
-
NO DEAD ENDS and every web page is reachable.
-
All web UI must be configurable so that it more easily integrates into an existing site's design. Probably means using
- a better template language/system like Zope's Presentation
- Templates, Quixote, or PHP.
-
-
Default UI should add a navigation sidebar to all web pages.
-
Web pages should never mention disabled features.
-
Allow a site admin and list admins to categorize lists, so that they can be better organized on the listinfo and admin overview
- pages.
-
-
-
List Administration
-
-
-
Allow the moderator to edit posts being held for approval (make it evident, either through a header or other means that the
- message was edited by the moderator).
-
-
Allow the admin to disable option settings by users
-
Allow admins to block nomail settings
-
Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes
- very useful, but could be dangerous!)
-
-
New moderation choice: archive but don't send to list.
-
New moderation choice: annotate and send to author for resubmittal. Or just be able to annotate the message for
- multiple moderator scenarios.
-
-
Better integration with moderated newsgroups (and allow some addresses to bypass even that moderation and be delivered to a
- secondary channel, like moderators@isc.org).
-
-
Allow a list to be marked `disabled' so things like the replybot still works, and the archives are still available, but mail
- posted to the list is always returned unsent.
-
-
Ability to `sideline' some messages in the moderation queue
-
Hook moderation up to a whitelist a la TMDA. A non-member message gets held in a non-admindb queue, and the sender gets a
- confirmation message. When they confirm, we moderate the
- message as normal, but if they don't we assume it's spam (after
- some period of time) and discard it. The admin should be able
- to see all these super-quarantined messages with the flip of a
- button.
-
-
Add a moderation option to pass through any message which is a reply to a message previously distributed through the list, even
- if it comes from a non-member. Treat that non-member as a
- member for the duration of the thread. Use In-Reply-To,
- References and Message-ID to match these up.
-
-
When a held message is forwarded (for admin editing and approved resend) there should be a way to auto-discard the held message
- when the approved resend is received.
-
-
Have an option to sort the list of members by real name or email address.
-
-
Test a message for all hold criteria, record them all instead of just the first match, and do a SpamAssassin like scoring to
- decide whether the message should get held or not.
-
-
-
List Membership
-
-
-
Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever
- address they want to whichever list, with different options per
- subscription.
-
-
Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this)
-
-
More flexible digests: index digests (subject and authors only, with URLs to retrieve the article)
-
-
Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.
-
-
Keep user-centric stats, such as the date the user was subscribed, the date of their last change to their account, the
- date they last sent a message through the list. Perhaps also
- log each message they send through the list.
-
-
-
Site Administration
-
-
-
Allow the site admin to define list styles or themes, and list admins to choose one of the canned styles to apply to their
- list.
-
-
Allow the site admin to send an email message to all the list admins using a mechanism similar to the Urgent: header (possibly
- by addressing it to mailman@site.dom).
-
-
-
Other Usability Improvments
-
-
-
A better strategy is needed for sub-lists and super-lists, including dealing with the resulting password reminders and
- authorization to modify the sub & superlists.
-
-
Add a limit on the number of posts from any one individual within a period of time (1 post per day, 10 per week, etc).
- Also, limits on mailbacks, infos, etc.
-
-
-
Mailcmd interface
-
-
-
Provide an email interface to all administrative commands
-
Allow email unsubs from matching address to unsubscribe, possibly adding an "allow open unsubscribes" option to control
- this. Also, adding a confirmation with click-thru confirmation
- to resubscribe.
-
-
For email subscribes, keep an audit of where requests are coming from, and send the original request headers in the confirmation
- message. Helps track down subscribe bombs.
-
-
Use a real transactional database for all information, and allow various bits of information to come from different sources (a
- relational database, ZODB, LDAP, etc)
-
-
Member profiles
-
Allow lists of the same name in two different virtual domains
-
Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc.
-
-
Implement something like Roundup's nosy lists, maybe even integrate with Roundup.
-
-
Split Mailman into libraries so, e.g. the delivery part could be used by other projects.
-
-
-
Bounce handling
-
-
-
Add more patterns for bounce handling (never ending)
-
Send mail to people who are being removed without their knowledge (even though they're likely not to get it).
-
-
-
Pipermail + Archiving mechanism
-
-
-
Search engine for archives
-
Provide downloadable tar.gz's of the html archives
-
sort by date should go most-recent to oldest
-
allow list owner to edit archive messages
-
optional form front-end to public interfaces as a filter to address harvesters.
-
-
In general the whole Pipermail subsystem needs a good rewrite.
-
Write an API between Mailman and the archiver so that message footers can contain the URL to the archived message.
-
-
-
Code cleanup
-
-
-
Turn all remaining string exceptions into class exceptions
-
s/images/PythonPoweredSmall.png)
s/images/logo-70.jpg){kind=logo}
ADDRESS
.
-![[Delivered by Mailman logo]](/graphics/dragonlogo.jpg)
(jpeg 6k)
-
-
