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