n was really just a DNS search on the target machine
name), the more likely, under load, that the message would duplicate.
We finally got so large, with so many international addresses (which
seem to timeout on DNS queries much more ofen than US addresses) that
we were always duplicating. Infinitely (until I killed the original
submitter).

The solution for us was MMDF-specific. We used a different channel for
submission and delivery, one which deliberately doesn't verify the
addresses before accepting a job. We used the list-processor channel,
and only had to check that the listname-request name was set properly,
because list-processor insists on making listname-request the envelope
"From " header name.

If you're running Sendmail, this is more rare. There have been
unconfirmed reports that on some systems having the queue process
interval set too short can cause problems, even though sendmail is
supposed to handle this. Workarounds are to increase your queue
process interval (-q flag), or decrease the interval between queue
checkpoints (OC flag in sendmail.cf).

There have been many reports from Linux users complaining about
duplicate mail. The problem seems to be that flock() under Linux is
broken. This may be fixed in a future release, but for now in
sendmail's conf.h in the #ifdef __linux__ section add a line #define
HASFLOCK 0. There are also reports that some versions of the libc have
problems, and that linking with the libresolv.a from a recent BIND
version will work around the problem.
[ Please let me know if you have any more information --ed ]

        4.4 - How do I gate my list to and/or from a newsgroup?

The easiest method is to use a program called newsgate. You can find
it at ftp://ftp.isc.org/isc/inn/contrib/. Installation instructions
are straightforward, it provides sample entires for your newsfeeds/sys
file and aliases entries. The newsgate package includes news2mail and
mail2news.

        4.5 - How can I improve Majordomo's performance?

 Mail to list throughput

Majordomo does very little except pass each message to the list
through 'resend', and then pass it on to your mailer for distribution.
Improving your mailer is the first step to improving speed of delivery
of mail to the list. Upgrading your sendmail to version 8.x will
improve things greatly, as this version has a lot of enhancements
which use connections more efficiently. For most lists, this is
enough. Majordomo itself doesn't use very much in the way of resources
except perhaps memory. Adding more memory will help if your machine
does a lot of paging during mail delivery. Using other mailers instead
of sendmail like ZMailer has met with varying success. qmail has been
used with majordomo, and performance there I'm told generally far
exceeds that of sendmail. qmail also is written in a far more secure
way than sendmail. See http://www.qmail.org.

If your lists are very large you may try installing bulk_mailer, by
Keith Moore. It pre-sorts the list into chunks grouped by site, and
passes the resulting chunks off to individual sendmail processes for
delivery (see note next paragraph). Get it from
ftp://cs.utk.edu/pub/moore/bulk_mailer/. It installs simply by
replacing your usual -outgoing alias with (line wrapped for clarity):

sample-outgoing: |"/path/to/bulk_mailer owner-sample@your.site
 /path/to/lists/sample"

bulk_mailer has reportedly resulted in dramatic speedups in delivery
times, on the order of several times faster. Note this works just as
well on digested lists as well as normal lists. bulk_mailer did have
one problem. Until version 1.3 it didn't understand parenthesized
comments in addresses, resulting in incorrect sorting and reduced
performance. Your list must be configured with strip=yes in the
configuration file if you don't upgrade to 1.3.

TLB is another package which is like bulk_mailer, but has other
features. You can get it from ftp://ftp.hpc.uh.edu/pub/tlb/.

The restrict_post list option with large lists can cause a significant
slowdown in mail delivery, since resend has to do a sequential search
through the subscription list for each mail sent to the list (to
verify that the sender is subscribed to the list). Think twice about
using this option with very large lists.

 Majordomo command processing

Most of the improvements in this are are experimental and not widely
available or not yet completed but scheduled for future releases. Some
areas include: improvements in shlock.pl to use exponential backoffs
to reduce contention and starvation of locks, using some sort of
dbz-style database for subscription lists to speed up subscribe and
unsubscribe commands, and changes in the configuration file system to
allow faster parsing and faster execution of certain commands such as
"lists". If you are interested in working on improvements in this
area, join the majordomo-workers list mentioned above. If you make any
specific patches or additions available, please let me know so I can
add references to it here.

        4.6 - How can I handle X.400 addresses?

Majordomo by default treats addresses starting with "/" as "hostile",
and won't let people subscribe. This is to prevent someone from
subscribing a majordomo-owned filename to the list, and being able to
write by sending mail to the list. Unfortunately, all X.400 addresses
begin with a "/". See the $no_x400at and $no_true_x400 variables and
the associated comments in the majordomo.cf. There is a reported bug
in 1.94 - you may need to change both tests for these variables in
majordomo.pl to put "main'" before them. Like this:

     if (!$main'no_x400at) {


     if (!$main'no_true_x400) {

This is fixed in Majordomo 1.94.1 and higher.

        4.7 - Why is the Subject of my messages missing?

[from Dave Wolfe]

But it's not. Oh, you probably mean "Why is the subject line of
messages to my moderated list blank?" Because you didn't include any
headers after the Approved: header in the body of the messages. Or you
deleted them when you approved the bounced messages.


When resend finds an Approved: header in the first line of the body, it
throws away all the headers it's collected for the message and looks for
more headers following the Approved: header (which is the format of a
bounced message). So if you put the Approved: header in an original
message (as opposed to a bounced message), you have to also fill in some
headers to be sent out, such as Subject:, To:, and From:.