> 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 8.6.x is acceptably fast; it's nowhere near the speed of
MMDF or zmailer on the same hardware. Unfortunately, sendmail
8.6.x is not what most sites are running -- remember, at least
one major 3-letter vendor is still shipping a non-MX capable
sendmail as the default sendmail binary. Without significant
investment in installing a decent version of sendmail, the
performance of sendmail on most Unix systems is still absolutely
abysmal.
 
> 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.
 
Again, it's important to distingush that there is significant
overhead involved in spinning off a process to handle delivery.
Sendmail 8.6.x does a better job of this, but it still spins off
one process per site for delivery, which is very expensive on
most architectures. Sendmail is a non-trivial application, even
with a simple config file.
 
> 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)
 
The real bottleneck is SMTP's large I/O requirement. Message
transit between MAILER and LISTSERV is essentially negligable;
it's completely analagous to dumping the message in
/var/spool/mqueue for processing. LISTSERV also uses a work disk
for temporary storage, so the approach is not all that different.
 
> 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.
 
There's no real problem with adding commands or features with
LISTSERV; I've done a number of interesting and useful commands
that used LISTSERV. I do agree that it's more difficult to change
standard behaviors with LISTSERV, but I rarely need to do that.
 
> [bounce errors handled by moving to special list]
> 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)
 
Simpler, but less suited to really large lists. When you have 40K
subscribers, most list owners don't have time to hunt that sort
of thing down.
 
> Majordomo 2.0 is in the works, which will add several features and make
> things even easier to customize and manage.
 
Cool. I'm looking forward to it.