Great Circle Associates List-Managers
(July 1994)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: My Listproc-Majordomo comparison
From: ckoenig @ midway . uchicago . edu
Date: Thu, 21 Jul 94 12:25:56 -0500
To: majordomo-users @ greatcircle . com, list-managers @ greatcircle . com
Reply-to: ckk @ uchicago . edu

Here's a slight revision of something I posted to comp.mail.misc,
following up a thread there. Some people on the Majordomo-Users and
List-Managers lists apparently hadn't seen this on the newsgroup. Feel
free to add this to whatever archives. Tasos, the author of ListProc,
said that I was basically on the mark concerning ListProc.

Chris Koenigsberg: ckk @
 uchicago .
 edu, ckoenig @
 midway .
 uchicago .
U. of Chicago Academic Information Technologies

Subject: Re: Which is better Majordomo or Listserv?
References: <2t7qgu$773 @
 ccnet .
 ccnet .

The real LISTSERV (Revised LISTSERV) relies on Bitnet networking
transport protocols.

A complex Unix list processor was written, in a partial emulation of
the Bitnet LISTSERV. The "Listserv for Unix" system was renamed
"listproc" last summer, after threats from the original LISTSERV
author, because it differs in user interface and list owner interface
from LISTSERV, and was accused of misleading users who would confuse
it with the "real thing".

Majordomo was apparently written, in Perl, because listproc (AKA Unix
LISTSERV) was too complex and did not do quite what was needed to
manage a set of Usenix SAGE mailing lists.

LISTSERV and ListProc want the whole world to be interconnected, i.e.
all mailing list server hosts can know about each other and exchange
info on remote lists; someday I imagine there'll be a DNS-like
namespace of mailing lists and server hosts out there somehow.

Majordomo, on the other hand, is a much smaller package, designed for
easier administration on an individual host, and I have even heard (on
the Majordomo-Users list) that some Majordomo hosts do NOT wish their
lists advertised publicly on the net.

We (U. of Chicago Academic Information Technologies) are planning to
go ahead and offer new campus list management service soon using
Majordomo, but we did have some requests from faculty to use listproc
(they asked for LISTSERV but since this is on Unix, they would have to
get listproc instead).

I tried briefly to configure and build listproc for a comparison test,
but gave up when it got weird, probably too soon, maybe I'll try again
when I have more time to play with compilers etc :-) Listproc
documentation etc. is a bit cryptic and not well thought out overall,
at least from the point of view of someone new to the concept trying
to understand all of its complex workings.  I have seen correspondence
from the Listproc author, on the listproc users' mailing list
archives, where he defends his documentation because it is in the
usual Unix style.  (maybe "damning by faint praise"? :-)

Majordomo is simpler and written in Perl scripts, so documentation is
more comprehensive, and is improving, as an active community of
developers is contributing to it.  It only took 2 days for the current
maintainers to put out small patches to fix some recently-discovered
potential security holes, and since it's Perl, no recompilation is

Listproc requires a server daemon to be alive, which forks off child
processes somewhat like lpd, and appears to be designed to do a lot of
complex, tricky things which requires a lot of C source code doing
networking stuff (multi-level automated archiving and indexing, with
retrieval via ftpmail, automatic digestification creation and
propagation, remote cooperation of "peer" list hosts, interactive
administration via TCP connections, operation over other transport and
delivery protocols besides TCP and SMTP, maintain its own message
queueing system independently of the system mail queues, ...), which
are perhaps overkill (for us, in a completely Internet TCP/SMTP
environment), perhaps not, this is what I'd like to hear more
discussion about.

Majordomo is more focused on the essentials of individual mailing list
management, and is implemented as Perl scripts, which are modular and
can be used in subsets, as they are individually invoked out of system
mail aliases. It lets the underlying system software do the networking
and message queueing stuff, so it doesn't have to deal with TCP
sockets etc. Majordomo's recently-added archiving, digestification,
etc. is simpler than listproc's, and is undergoing more improvements.

Apparently, Listproc's daemon with its own queueing system used to
give better performance, for high-traffic lists on heavily loaded
server hosts, than older versions of sendmail. But now, newer sendmail
versions have greatly improved efficiency so Majordomo with new
sendmail may be just as fast and load-capable as a Listproc system.
(comments welcomed on this point?)

With Listproc, if you can get it configured and running smoothly, you
can apparently join a growing inter-operating network of cooperating
"peer" list hosts, and even inter-operate with Bitnet LISTSERV list
hosts too. Thus your local users can easily find out about other lists
elsewhere, you can have local re-distributions for a larger global
list, etc. (but re-distributions can be a source of administrative
headache when global list owners try to track down mysterious errors,
or unsubscribe requests from people who aren't subscribed to the
global list.... :-).

One big flaw in Listproc's design, in my opinion (correct me if I'm
wrong!), is that it does funny things to the headers of outgoing
messages which are arguably "wrong" in the RFC 822 SMTP world (I've
seen arguments in the listproc users' archives), and for
incoming messages, it only uses the Unix From field (i.e. the SMTP
Envelope MAIL FROM, in the SMTP world) to determine the sender's
identity, for subscribing, unsubscribing, accepting or rejecting
messages, etc.

Majordomo on the other hand will use the RFC 822 headers (Gene
Spafford's Perl code for parsing mail headers), so it will recognize a
"Reply-To:" for example, and will allow you to subscribe your
canonical address, even if the return path of your message is
convoluted (although the list owner may need to approve your
subscription). You have various per-list configuration options, about
what appears in the various RFC 822/SMTP headers, concerning the
return address for errors, the default reply address (to the list, to
the original author, to the list owner/moderator, etc.)...

Both Listproc and Majordomo share concepts like moderated lists.
Listproc's moderated lists have a queue of incoming messages, and the
moderator has to approve or reject them by giving the message queue
numbers to the server, in order to clear the queue.

For a moderated list, Majordomo simply bounces messages to the
moderator and then forgets about them, so the moderator can easily
re-submit them with an approval password in a new header. Any message
arriving with the proper approval password header will be
automatically approved and propagated to the list.

An outfit called CREN, an offshoot of Educom, has taken over the
development of both the Bitnet LISTSERV, and the Unix Listproc, and is
planning to offer a commercial version of Listproc sometime later in
1994. They have a global vision building on the inter-operating "peer"
list host concept, integrating gopher, ftp, etc. (their vision
statement doesn't mention WWW but I assume that must be added soon

We are very interested to see if CREN's new Listproc version will come
with improved support, including better documentation, and we might
consider switching to it sometime in the future, but we are planning
to stick with Majordomo for now.

Chris Koenigsberg: ckk @
 uchicago .
 edu, ckoenig @
 midway .
 uchicago .
U. of Chicago Academic Information Technologies

Indexed By Date Previous: News to Mail gateways
From: David Bowen <dmb @ sdiv . cray . com>
Next: Re: My Listproc-Majordomo comparison
From: Brent Chapman <brent @ mycroft . GreatCircle . COM>
Indexed By Thread Previous: News to Mail gateways
From: David Bowen <dmb @ sdiv . cray . com>
Next: Re: My Listproc-Majordomo comparison
From: Houghton Mifflin Math <sine @ world . std . com>

Search Internet Search