[Mailman-Users] Pig at the wedding question/diatribe

Stephen J. Turnbull stephen at xemacs.org
Mon Nov 1 06:43:43 CET 2004


>>>>> "Stewart" == Stewart Dean <sdean at bard.edu> writes:

    Stewart> <scraping sound of soapbox being pulled up>

    Stewart> I really, /really/ appreciate applications that build
    Stewart> into a single binary or a very few files, that can be
    Stewart> built on a (different) build and test host, then copied
    Stewart> over to the production when everything is thrashed out
    Stewart> and ripe...you know, like Pine and UoW IMAP.

Mailman solves a different kind of problem from Pine and IMAP.  IMAP
has no user interface; Pine doesn't need to worry about screwing up
anything but the user's own data if it screws up.  The MLM problem is
much less straightforward; it requires careful attention to security
issues, both against hostile entities like crackers and spammers, and
against benign but still dangerous activity (aka "fool-proofing").  In
order to deal with the inherent complexity, AFAIK most MLMs are
written in scripting languages like Python or Perl, and the rest (eg,
smartlist, which is distributed with procmail) are very inflexible,
require list manager == system administrator, and require separate
CGIs, invariably written in a scripting language, to provide the web
interface.

    Stewart> = there's prolly other things that don't come to mind
    Stewart> right now.

Microsoft Exchange sounds like it's just what you need.  It's only
your money and your freedom that are at stake.  ;-)

    Stewart> I guess I'm just hopelessly behind-the-times in not
    Stewart> wanting the installation fairy sprinkling files here and
    Stewart> there and generally making heavy local dependencies.

Not at all.  In fact, that's been a design goal and within the
constraints imposed by dealing with an MTA and multiple user
interfaces, it's been successful IMO.  Compared to earlier versions of
majordomo (I haven't dealt with anything but Mailman for about 4
years), Mailman has a well-defined structure which makes it easy to
find the things I need, and has very few local dependencies except for
Python and the MTA.  On the other hand, compared to smartlist it
allows me to delegate list configuration to the owners with little
worry, and makes user-specific configuration possible.

All the files are under one directory, except for the MTA
configuration and possibly the archives.  If your production system is
binary-compatible with your test system, you just tar up the whole
thing on the test side and untar on the production system.  You may
have to make any MTA changes by hand, although it's not hard to
configure some MTAs (sendmail comes to mind) to use multiple alias
files.

    Stewart> I Just Wanted A Mailing List Manager...

Actually, I suspect you define Mailing List Manager in a way that
doesn't apply to Mailman.  What "mailing list manager" means in this
context is "a set of user interfaces that allow list owners and users
to configure their lists and subscriptions without requiring effort on
the part of system administrators."  It's about allowing delegation of
responsibility without complicating your life, rather than about
simplifying your life per se.

If you're mostly setting up one-way announcement lists and the like,
you might be more interested in CRM (customer relations management)
software.  If you are looking for something that just manages
distribution lists and don't care about flexibility for list owners
and users, smartlist might be more up your alley.

    Stewart> Augustine's Law #405:
    Stewart> Anything that isn't in a design won't break

Murphy's Corollary to Augustine's Law #405: The users will
nevertheless complain that the feature is broken by its very absence.

So design the system that gives you exactly what you need, no more,
and no less, and put it out for bid.  Be it ever so humble, it won't
be cheap.<wink>

    Stewart> Or tell me how wonderful it is............

It would help if you described what your needs are rather than
complaining about aspects of Mailman that are designed-in in order to
meet the needs perceived by the designers.  It's quite possible that
you would be better served by a different package.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.



More information about the Mailman-Users mailing list