summaryrefslogtreecommitdiff
path: root/README
blob: 4e79233d968f8eb893a23ca266fe763f2bc0b297 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
Mailman - A mailing list management system
Copyright (C) 1998 by the Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

			      Background
			      ==========
This is Mailman, a mailing list management system written mostly in
Python.  Mailman was originally developed by John Viega.  Subsequent
development (through version 1.1) was by Ken Manheimer.  Currently,
Mailman development is a group effort, led by John Viega, Ken
Manheimer and Barry Warsaw.

Initial version of Mailman (v. 0.9) written by John Viega Dec 12-15
1996.  Mailman 1.0b3, 2, and  1.1 developments by Ken Manheimer,  4/98
and 5/98.  Autoconf support added 5/98 by Barry Warsaw.

See the Mailman home site for current status, including new releases
and known problems: http://www.list.org

To join the Mailman user's mailing list (recommended) - and to see an
example of a Mailman list interface in action - visit:

    http://www.python.org/mailman/listinfo/mailman-users

To track, and/or participate in, the mailman development crowd:

    http://www.python.org/mailman/listinfo/mailman-developers

See file DONE for info on changes since v. 0.9

Features:

  o Most standard mailing list features, including:
	moderation, mail based commands, digests, etc...
  o An extensive Web interface customizable on a per-list basis.
  o Web based list administration interface for *all* admin-type tasks.
  o*Automatic Web based hypermail-style archives (using pipermail or
    other external archiver), including provisions for private archives
  o Integrated mail list to newsgroup gatewaying
  o Integrated newsgroup to mail list gatewaying (polling-based... if you
     have access to the nntp server, you should be able to easily do 
     non-polling based news->mail list gatewaying; email viega@list.org, 
     I'd like to help get that going and come up
     with instructions)
  o Smart bounce detection and correction
  o Integrated fast bulk mailing (useful for sendmail users)
  o Smart spam protection
  o Extensible logging
  o Multiple list owners and moderators are possible
  o Optional MIME-compliant digests
  o Nice about which machine you subscribed from if you're from the
	right domain.

* Now missing, but will return soon!

			    Using Mailman
			    =============
Requirements:

  You must  be root on a machine  running a mail transport  program that
  uses an /etc/aliases file, and has a sendmail executable (smail should
  be OK).  We will    soon be switching     over to use a  direct   SMTP
  connection to  whatever  you have  running  on port   25.  The machine
  really needs to have a web server in order to configure lists.

Install:
  Please see the file INSTALL for details on installing Mailman.  In the
  instructions that follow, all file paths are assumed to be relative to
  the installation directory $prefix.

Adding a new list:
  o Run the program bin/newlist
  o Visit the list general admin page, and use the descriptions and
    the "details" help feature to understand the configuration settings.

List managers, note that:

  o Being a list administrator does not entail receiving the traffic - 
    you have to subscribe, as well.
  o Relevant urls - the DEFAULT_URL plus:
    - mailman/listinfo/listname for public view of list
    - mailman/admin/listname for options
    - mailman/admindb/listname for pending requests
    - and generally, mailman/listinfo for the list of (public) lists

Troubleshooting:

  If from the web you get "document contains no data":
  If mail isn't getting delivered:

    The  cgi  wrappers are failing.   Either a  UID is  wrong, or your web
    server / mailer has a non-standard name.

    If you're unsure about  the proper settings,  the cgi and mail wrapper
    programs  use syslog to   register mismatches, indicating  the correct
    setting  in  the process.   You  need   to   have syslog  running  and
    configured to log the mail.error log class somewhere - on sun 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,  if   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 the web pages hang:

    CERN web servers might leave python's running, and in some cases might
    hang the cgi completely.  In that case, switch to Apache.

  Check ~mailman/logs/error periodically:

    Many of the scripts have  their stderr logged to  ~mailman/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.

    One thing that   is  *not* caught  by  stderr hook  is syntax  errors!
    However, most files can be run  from the command  line with no effect.
    (The  ones that will   do stuff you  want  to avoid, like  sending out
    spurious  password  reminders, are in the  cron  dir.)  So you can and
    should use  the python interpreter to check  the of any changes before
    trying them out.
    
How to add a new user option

    You'll need to do some of these things and not others.

	1) Add a flag to mm_defaults.py, and mm_cfg.py.dist if it's
	   likely to require a custom value for each site.
	2) Add an entry to mm_html GetStandardReplacements name
	 & mapping, to enable referring to the value from mailman html.
	3) Add replacements lines to the cgi/options and cgi/listinfo
	   scripts, to hook the mailman html up with the option.
	4) For user-specific options, make SetUserOption calls in
	 & cgi/handle_opts.
	5) For user-specific options, add to 2 data structs at top of
	 &  mm_mailcmd.
	6) For user-specific options, add description to mm_mailcmd help
	7) Update templates if the options have replacements
	8) Use your option wherever appropriate...

Interactive python sessions with maillists

    You  can  do substantial  things  with maillists from the interpreter!
    Include the mailman  homedir on  your shell  python path, or  manually
    insert it on sys.path  from within python, and import Mailman.MailList
    and Mailman.Utils  from within the  interpreter.  You  can instantiate
    the maillist of your choice, eg for a list named postal:

>>> sys.path.insert(0, '/local/mailman')
>>> from Mailman import MailList, Utils
>>> l = MailList.MailList('postal', lock=0)

    (Don't set lock=0 if  you're  going to  be  changing the state of  the
    list, eg adding or  removing  members, etc.   However, be  aware  that
    while you're locking  it you'll be blocking  any other  processes that
    are trying to obtain the lock -  including handling of new postings to
    the list, subscriptions, administrative changes, and so forth.)

    Now you can examine various aspects of the list:

>>> l.members
['klm@python.org']
>>> l.digest_members
[]
>>> l.real_name
'Postal'
>>> l._internal_name
'postal'

    dir(l) will present the  components  of the list. MailList.py  has
    the descriptions of many of them, though some are defined in other
    modules.

    If you  want to save changes, 'l.Save()'  will do it.  It's a real
    good  idea to  play with   trial lists, first,  before using  this
    method to do surgery on production lists!

    When you  do get  comfortable with it,  you use  it and  a utility
    routine, Utils.map_maillists(),  to do batched  changes on all
    your lists.  It takes a function as its argument, and applies that
    function to every one of the  lists on your system.  For instance,
    to get the  names of  all   the lists on   your system  which  are
    advertised:

>>> def advertised(lst):
...    if lst.advertised: return lst.real_name
...
>>> advertised(l)
>>> filter(None, Utils.map_maillists(advertised))
['Mailman-Developers', 'Meta-sig', 'Python-Help', 'C++-SIG', 'Matrix-SIG',
'DB-SIG', 'DO-SIG', 'Doc-SIG', 'GUI-SIG', 'Image-SIG', 'Objc-SIG',
'Plot-SIG', 'Pythonmac-SIG', 'String-SIG', 'Thread-SIG', 'Grail', 'XML-SIG',
'JPython-Interest', 'Trove-Dev', 'Mailman-Users']

    If you do list surgery with this  mechanism, make really sure that
    you're doing  what you  intend  before having   the routine do any
    .Save()'s.