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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Mailman 1.0b3 (README $Revision: 516 $, $Date: 1998-05-04 19:18:08 +0100 (Mon, 04 May 1998) $)
This is mailman, maillist management software written mostly in
Python. Mailman was originally developed by John Viega. Ken
Manheimer picked it up after substantial revisions of the development
version were lost in a system crash, and refined some of the rough
edges, enough so that mailman is now the production system for
python.org. We expect to continue to develop mailman, and see
blossoming of this very promising foundation as other people join in.
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.
For anyone interested in joining the development crowd, or just
tracking the progress, there's a maillist for you to join:
mailman-developers@python.org
Visit http://www.python.org/mailman/listinfo/mailman-developers for
more info (and for an example of the system in action).
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 Smart bounce detection and correction
o Fast bulk mailing
o Smart spam protection
o Extendable logging
o Multiple list owners and moderators
o Optional MIME-Compliant digests
o Nice about which machine you subscribed from if you're from the
right domain.
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:
o Make sure Python is installed as /usr/local/bin/python (currently
hardcoded -- this obviously needs to change, and should be
handled by a config program)
o As root, add a mailman user
o As mailman, copy the mailman dir to /home/mailman. Currently the
system requires the source be located there. [I've been running
with the untarred mailman dir as a subdir of /home/mailman, so eg
maillist.py, the main mailman list object module, is situated as
/home/mailman/mailman/maillist.py.]
o As mailman, in /home/mailman make public_html, cgi-bin, and logs
directories. Chmod them g+sw.
o As mailman, in /home/mailman make archives/private and archives/public
directories. Chmod them g+sw.
o Copy /home/mailman/mailman/misc/Cookie.py to /home/mailman/cgi-bin
o As root, Configure your web server to give /home/mailman/cgi-bin
perms to run cgi in the cgi-bin dir, and restart the web server.
The line you should add should look something like:
Exec /mailman/* /home/mailman/cgi-bin/*
or:
ScriptAlias /mailman/ /home/mailman/cgi-bin/
(Or whatever is equivalent for your web server)
o As root, edit /home/mailman/mailman/src/*.c and edit the UID and
GID const lines as appropriate. (See Troubleshooting, below, for
hints about determining the proper settings when you're unsure.)
o As root, cd to /home/mailman/mailman/src and type: make
o As root, Add mailman as a trusted mail user. This is usually done
by adding: Tmailman to /etc/sendmail.cf under the line: Troot
o As root, Restart sendmail.
o As mailman, cd to /home/mailman/mailman/cron, and add crontab.in
as your crontab. (probably done w/: crontab crontab.in)
o Edit mailman/modules/mm_cfg.py - if you don't already have one, make a
copy from mailman/modules/mm_cfg.py.dist. Include settings in mm_cfg.py
for any of the defaults in mm_defaults.py that you want to tailor
for your site.
o Create the site password, if you don't already have one, using
'mailman/bin/mmsitepass password'.
o Point external archiver at public and private archives (we recommend
http://starship.skyport.net/crew/amk/maintained/pipermail.html ).
Adding a new list:
o Run the program bin/newlist
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 syntax
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 th interpreter!
Cd to the modules subdir and, with '.' on your pythonpath, start
the interpreter and import maillist and mm_utils. You can
instantiate the maillist of your choice, eg for a list named
postal:
>>> l = maillist.MailList('postal')
>>> l.Unlock()
Don't do the Unlock() if you're going to be doing surgery on the
list. However, if the list is active, and you aren't going to be
saving any changes, be sure to do the l.Unlock() immediately.
Otherwise, anyone visiting a web interface involving the list, or
postings going to the list, will be held awaiting the lock.
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. maillists.py has
the descriptions of many of the components, 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 doing surgery
with this method on production lists.
When you do get comfortable with it, you use it and a utility
routine, mm_utils.mm_utils.map_maillists(), to do wholesale changes
on all your lists. It takes a function 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:
>>> import maillist, mm_utils
>>> def advertised(l):
... if l.advertised: return l.real_name
...
>>> filter(None, mm_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']
If you do list surgery with this mechanism, double check that
you're doing what you intend before having the routine do l.Save()'s.
|
