In article <[log in to unmask]>,
David Sitman  <[log in to unmask]> wrote:
>>                               Listserv    |    Majordomo
>>[...]
> moderated lists                    y             ?
 
moderated lists                    y               y
restricted-access list             y               y
posting-by-members-only list       y               y
easily customizable                n               y
administrative checking            y               y
  (i.e. check for subscription requests sent to the list)
MSP (RFC 1312) support             y (need server) n
 
>There are other important considerations not mentioned here such as
>CPU load, network load, security, management of bounced mail, etc.
>Herman, I would suggest that you post this on the listproc list also.
 
Eric and I have argued on this point before; but the recent sendmail
releases are quite efficient and IMHO as or more efficient than
SMTP+MAILER.  Sendmail is good at load balancing and connection
caching, and is infinately customizable in many ways including
queue handling and routing.  Mail delivery is not a very CPU-intensive
task.  Its speed depends on how many hoops and calls the system
has to go through to get the message, figure out where it goes,
then open up SMTP connection, etc.  LISTSERV's problem is that
the messsage flies around a lot of places before it can even
get anwhere.  Between SMTP, MAILER, LISTSERV, that's a lot of
shuffles.  In sendmail, everything happens in /var/spool/mqueue.
(and majordomo does stuff in /tmp)
 
As far as Majordomo's speed, Perl is quite fast - it's often compared
to C in terms of speed.  I'll put it up against VM's Pascal any day.
Majordomo is very modular in design - it's easy to add features.
Don't like the digest format?  Just modify the 'digest' program.
Want a new command?  Just add a line to the parsing section and write
the new function to do the command.  No compiler needed - and you
always have the source code.
 
One thing Majordomo doesn't do that LISTSERV does is "real" automatic
bounce handling.  Majordomo doesn't even attempt at parsing all
the myriad different formats of bounce messages.  What it does
do is provide a Perl program that the list owner can run to
move "bad" addresses into a special "bounces" list, and then majordomo
can send out mail periodically saying "you were removed from the
list thus-n-such because mail was bouncing - here's how you can
get back on the list and stop getting these messages".  (assuming
the error was a transient one)  I prefer Majordomo's method
of tackling the problem.  (it certainly is simpler and therefore
less prone to bugs or errors)
 
Majordomo 2.0 is in the works, which will add several features and make
things even easier to customize and manage.
 
[be sure to Cc: [log in to unmask]]
--
"Don't ever take a fence down until you know why it was put up."
- Robert Frost