[Mailman-Users] Large-number of users in Mailman/switching from Listproc

[David Champion]

On 2000.05.30, in <Pine.OSF.4.21.0005301728310.15062-100000 at emerald.tufts.edu>,
	"Anne Cross" <across01 at emerald.tufts.edu> wrote:
> Currently, Tufts University is looking at switching from Listproc to
> something a little more stable and a lot easier to administrate.  All the
> things I've seen in testing Mailman would tend to indicate that I've found
> an acceptable replacement for Listproc.  
> 
> However, I'd appreciate any firsthand accounts from administrators of more
> than 300 lists, or more than 5000 users, or anyone who's switched from
> Listproc to Mailman.

We operate 578 lists right now -- we add two or three per day.  Most
are under 100 members, but 80 or so are between [100 and 999], four
are between 1000 and 4000, and one is slightly over 20000.  We've
switched over the last six months from Majordomo to Mailman, with mixed
results.

Majordomo seems to give users a lot more of the flexibility they seem
to want.  It's a very rough judgment, without numbers to back it up,
but it seems that very few of our list admins take advantage of the
spiffier features in Mailman.  They mostly don't seem to care -- they
just want a nice webby front-end, and we never ran MajorCool or any of
the other front-ends to Majordomo.  The ones we hear from, by and
large, miss things like editing a message before approving it and
resubmitting it to the list, or viewing list options as a file, and
being able to save that file locally.  There's not a lot of complaint,
except when they get those irritating tracebacks in the web browser.
We're still running a very old non-release, though, so I'm not sure
whether that counts for much.  (We'll be upgrading once the academic
year is up, and 2.0 is out.)

The package is severely underdocumented.  For a lot of people, it's
sufficiently self-documenting, or they just don't care about what they
don't understand.  But we do spend upward of an hour per day dealing
with list support issues of one kind or another.  Often the information
is there, but they simply don't "get it".  I'm not convinced this is
strictly a reading-comprehension problem.  The people we spend most
time with have technical problems with how, or how well, Mailman passes
mail through cleanly, or they can't figure out how which options to use
-- generally NOT stuff covered in the Aurora documentation project,
which we've linked to.

As J.C. mentioned, Mailman's web interface doesn't always perform very
well at these levels, but I wait eagerly to see how this improves once
2.0 is released.  (I think this is what he was referring to.)  It's not
bad for the smaller lists, but web interaction is slow, and listing the
lists is excruciating.  The general lag is surely, in part, because we
SSL the whole kit & kaboodle to protect passwords.

Performance, SMTP-wise, seems fine.  We certainly do notice a big drop
in performance when we mail to the 20K-member list.  The several-
thousands lists don't usually seem to strain the system noticeably, but
they're not very busy lists, and I'm sure that if we knew a message was
going through, we could detect the performance hit.  Our server is a
dual-processor Sun Enterprise 2, and it routes other mail, as well.

Turn off the periodic emailed password reminders.  They're just not a
good idea -- sorry.

My biggest complaint with Mailman so far is that so many database
modifications are unavailable unless you can write Python.  The package
stores list and user information in database files from Python's
"cPickle" module.  I hope that's technically correct; I only gather
this from a rough skimming of the code.  In our version, it also stores
queued mail in the cPickle databases, though I think this has (will?)
change.  Since the configs are not text, and Mailman/Python provide no
tools for direct manipulation, and this pickle stuff is not a portable
(and ported) format, you really need to know Python and a fair amount
of Mailman's innards to manipulate configuration data outside the web
interface.  For our volume and environment, this is occasionally
necessary and often very useful, but we don't have any full-time
employees who are Python programmers, so we grasp and scratch.  The
"withlist" script makes this marginally more convenient, but you still
have to know some Python, and no, sorry, wrong, Python is not the
Everyman's programming language it's sometimes touted as.

I think I'm leaving some things out, and I suspect some people will
have rebuttal to things I've said, so I'm leaving this in the open for
commentary.

-- 
 -D.	dgc at uchicago.edu	NSIT	University of Chicago