> 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.