Version: $Id: majordomo-faq.html,v 1.3 1997/04/27 14:57:00 cwilson Exp $ Archive-Name: mail/list-admin/majordomo-faq Posting-Frequency: monthlyNote: This FAQ has been recently updated to be exclusively for Majordomo 1.94. If you have a prior release of Majordomo, then you must either upgrade or refer to the old copy of the majordomo FAQ at http://www.math.psu.edu/barr/majordomo-faq-old.html
I will not be making any future changes to the old FAQ.
Table of Contents:
Credits:
This FAQ originally written by Vincent D. Skahan. Many thanks to
the members of the majordomo-workers and majordomo-users mailing lists for many
of the questions and answers found in this FAQ. Thanks to fen@comedia.com (Fen
Labalme) for getting an HTML version started.
You can get an HTML version of this FAQ on the World Wide Web at http://www.math.psu.edu/barr/majordomo-faq.html. You can request a copy by email by sending a message to mail-server@rtfm.mit.edu, with the following text in the body:
send usenet/comp.mail.list-admin.software/Majordomo_Frequently_Asked_QuestionsIf you have any questions or submissions regarding this FAQ, send them to barr@math.psu.edu (David Barr).
Majordomo controls a list of addresses for some mail transport system (like sendmail or smail) to handle. Majordomo itself performs no mail delivery (though it has scripts to format and archive messages).
majordomo - n: a person who speaks, makes arrangements, or takes charge for another. From latin "major domus" - "master of the house".
Majordomo is written in Perl. It will work with Perl 4.036 or Perl 5.002 or greater. It will not work with Perl 5.001!!! It has reportedly worked with Perl 5.000 on some but not all platforms. This is due to bugs in Perl which have since been fixed. It is recommended that you use the latest release of Perl that you can get, which can be found at http://www.perl.com/perl/. While Majordomo is still compatible with Perl 4.036, future versions will likely be Perl 5 only.
Many people have been having problems with DEC OSF/1 AXP systems with Majordomo. Apparently Perl on the Alphas is not as stable as compared to other platforms, and Majordomo tickles bugs in that port of Perl. If you are having problems, please make sure you are running the very latest version of Perl (version 5.002 is known to work).
There have also been reported problems with the native compiler for AIX 3.2.5. Perl compiled with that compiler will crash when running Majordomo (even though it passes all the regression tests), however if you compile Perl with gcc it will work.
Majordomo was developed under UNIX based systems, but will probably work on others. If you can get Perl to compile and run cleanly on your system, and can send Internet mail by piping or calling an external program (and that external program reads its list of recipients from a plain text file), you can probably get Majordomo to work on a wide variety of UNIX-based and non-UNIX based systems.
Here's a short list of some of the features of Majordomo.
1.2 - Where do I get Majordomo?
Via anonymous FTP at: ftp://ftp.greatcircle.com/pub/majordomo/
The current version is 1.94.1. This release is significantly easier to install and offers many features over 1.93. (Subscription confirmations, "taboo" checks to forward matched messages for approval, finer grained access control to who/which/get/index/info/intro, "config-test" script to test your installation, improvements to digest, and more) If you don't have Perl, you can get it from:
Use that link for more information about Perl, too. The FTPMAIL package can be found in ftp://src.doc.ic.ac.uk/packages/ftpmail or any comp.sources.misc archive (volume 37).
1.3 - How do I install it?
Majordomo comes with a rather extensive
INSTALL file. Read this file completely. There's also a README file which also
covers some common problems. This FAQ is meant to be a supplement to Majordomo's
documentation, not a replacement for it. If you have any questions that this FAQ
doesn't cover, chances are that it is covered in the documentation in the
Majordomo distribution. For anyone who is going to run a list, you must read
Doc/list-owner-info before trying to do anything. If you don't have access to
the system where your list is being run, the Majordomo maintainer who set up
your list should have sent it to you. Bug him if he didn't.
If you have permission problems unpacking the distribution, try using the 'o' flag to tar to ignore user/group information.
1.4 - How do I upgrade from an earlier release?
Be sure to browse
the "Changelog" file to get an idea what has changed. There currently is no
canned set of instructions for upgrading from an earlier release. The most
straightforward method is to simply install the current release in a different
directory, (with the same list/archive/digest directories) and change the mail
aliases for each list to use the new Majordomo scripts as soon as you feel
comfortable with the new setup.
Be careful in upgrading to 1.94 that you update your $mailer and $bounce_mailer variables in your majordomo.cf! There are also some other new variables too. You may want to update the list .config files so they contain any new variables found in the new release. You just need to do a 'writeconfig' for each list, and majordomo will update the .config file using the existing values in the old .config file. Any new variables will be set to defaults for a new list.
1.5 - Where do I report bugs or get help with Majordomo?
Please DO
NOT ask the FAQ maintainer for help on Majordomo. I will probably accidently
delete your message. Let me say that about 90% of the answers I give are from
the documentation or this FAQ. Most of the rest are answered by reading the
source. It's really not that hard to figure out.
If you need help, there is a mailing list majordomo-users@greatcircle.com, which is frequented by lots of users of Majordomo. Report actual bugs to majordomo-workers@greatcircle.com. (check the list archives to see if the bug hasn't been reported or fixed already!) There are searchable list archives (thanks to jason Tibbitts) at http://www.hpc.uh.edu/majordomo-users/ and http://www.hpc.uh.edu/majordomo-workers/.
Be sure always to include which version of Majordomo you are using. You should also include what operating system you are using, what version of Perl, and what mailer (sendmail, smail, etc) and version you are using, especially if you can't get Majordomo to work at all. But first, you must have thoroughly read the ALL documentation in the Majordomo distribution and this FAQ. If you got this FAQ from the Majordomo distribution, or anywhere except from the WWW site at the top of this document don't expect it to be up-to-date. It's probably not.
There is an FTP site for unofficial patches. See ftp://sol.ccsf.cc.ca.us/majordomo-patches/ . What's in it? Messages that are saved from the majordomo-users and -workers mailing lists. There are INDEX files in each part with one-line summaries of each patch, and a README file in the top directory with overall information. If you have patches that you think should be in the archive, you can FTP or email them in. The top-level README file tells how to do it. Please contribute -- to save other people the headaches you had. NOTE: The patches are NOT "official" patches approved by Chan Wilson or anyone else. Use your own judgement before (and after) you apply them.
Do NOT ask questions about Majordomo on the list-managers@greatcircle.com list. That list is for general discussions about running mailing lists, not for help on specific packages. The same goes for the Usenet group comp.mail.list-admin.policy.
There is a good guide for people running majordomo lists at http://www.uchicago.edu/a.docs/Mail/majordomo.admin.html.
1.6 - Which is better, Majordomo or LISTSERV?
For a good comparison
of various mailing list managers (MLM's) there's a good FAQ by Norm Aleks. It is
posted monthly to news.answers and comp.mail.list-admin.software. It's also
mirrored at the following URL. ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq
You can also request a copy via email, by sending the text "get mlm-software
faq" in the body of a mail message to LISTSERV@listserv.net. Contact
naleks@library.ummed.edu (Norm Aleks) for more information.
1.7 - How can I access Majordomo via the Web?
There are various Web
interfaces to Majordomo available.
Section 2: Problems setting up Majordomo
2.1 - What are the proper permissions and ownership of all Majordomo files
and directories?
By far the biggest problem in setting up Majordomo is
getting all the permissions and ownerships right. In part this is due to the
security model that Majordomo uses, and it's also due to the fact that it's hard
to automate this process. Once you install majordomo, run "./wrapper
config-test" as some other user (like you) and read the results. Do NOT
run "./wrapper config-test" as 'root' or your 'majordom' user. That will defeat
the test of the wrapper operation. The config-test script will check your
installation for correct permissions (as well as other tests) and report any
problems. It's not quite perfect, but it catches 95% of all problems.
Majordomo works by using a small C "wrapper" which works by allowing Majordomo to always run as the "majordom" user and group that you create. (note that the wrapper may disappear in a future release, since its function could safely be replaced by features found in Perl 5) You can use a different name than "majordom" for your user and group, but that is what is assumed for the explanations found in this document. The 1.94.1 INSTALL file suggests using 'daemon' as your majordomo group. This is the group that 'sendmail' runs as, and allows you to have $homedir permissions set to 750. This has the disadvantage in environments where there may be one or more administrators of the Majordomo system or where you don't want to always have to 'su' the the majordomo user to do administration. (you don't really want to put other normal users in the 'daemon' group for security reasons) If you create a separate 'majordom' group and add yourself and other majordomo administrators to it, then you'll need to make sure the $homedir and wrapper have world execute permission, and you may have to add 'majordom' to the 'trusted' list of users in your sendmail.cf. (otherwise sendmail 8.x will probably give "X-Authentication-Warning:"'s)
Because Majordomo does not run with any "special" (root) priviliges, and because of the fact that Majordomo does a lot of .lock-style locking (with shlock.pl), permissions on all files and directories are critical to the correct operation of Majordomo.
Some systems which are non-POSIX: SunOS 4.x, Ultrix, most BSD 4.2 and 4.3-based systems. POSIX systems include: Solaris 2.x, IRIX 5.x, BSDI (and other 4.4 BSD-based systems), Linux.
Make sure W_PATH is right in the Makefile. On IRIX 5.x, you need to add /usr/bsd to the W_PATH to get the hostname (needed by Perl) command. (IRIX doesn't have a /usr/ucb). If you are on a non-POSIX system, the wrapper must be both suid and sgid (mode 6755) to "majordom". It must not be setuid root!
OR
On a POSIX system the wrapper must be setuid root, and double-check that W_USER and W_GROUP are the uid and gid of the "majordom" user and group. Don't ever set W_USER to be 0!
Then compile the wrapper and install it. Do not install the wrapper on an NFS filesystem mounted with the "nosuid" option set. This will prevent the wrapper from working.
See section 1.1> above for what versions of Perl won't work with Majordomo.
[reported by Russell Street]
You may also get problems when messages to
majordomo are queued (for example if you change sendmail's behavior to always
queue messages rather than perform immediate delivery). The problem was that if
sendmail queues a message it smashes the case in command lines and addresses
when the queue gets processed. This is in spite of the lines shown by mailq.
This is sendmail 5.x on Solaris 2.3, but it might apply to other versions of
sendmail.
2.4 - I get an error "insecure usage" from the wrapper
The argument
to "wrapper" should be simply be the command, not the full path to the command.
"wrapper" has where to look compiled in to it (the "W_HOME" setting in the
Makefile) and for security reasons will not let you specify another directory.
Your alias should say for example:
|"/path/to/majordomo/wrapper majordomo"
2.5 - I get "majordomo: No such file or directory" from the
wrapper
Make sure that the #! statement at the beginning of all the
Majordomo Perl executables contain the correct path to the perl program (the
default is /usr/local/bin/perl). Note many UNIXes have a 32 character limit on
that path -- make sure it doesn't exceed this limit. Make sure also that
majordomo and all the related scripts are in the W_HOME directory as defined in
the Makefile when you compiled the wrapper.
2.6 - I get an error "Can't locate majordomo.pl"
[from Brent
Chapman]
Majordomo adds "$homedir" from the majordomo.cf file to the @INC
array before it goes looking for "majordomo.pl". Since it's not finding it, I'd
guess you have one of two problems:
1) $homedir is set improperly (or not set at all; there is no default) in your majordomo.cf file.
2) majordomo.pl is not in $homedir, or is not readable.
[from John P. Rouillard]
3) Note that the new majordomo.cf file checks to
see if the environment variable $HOME is set first, and uses that for $homedir.
Since the wrapper always sets HOME to the correct directory, you get a nice
default, unless you are running a previously built wrapper, in which case you
may get the wrong directory.
[from Andreas Fenner]
4) I had the same problem when I installed majordomo
(1.62). My Problem was a missing ";" in the majordomo.cf file - just in the line
before setting homedir .... My hint for you: Check your perl-files carefully.
2.7 - I told my majordomo.cf where to archive the list, why isn't it
working?
[From John Rouillard]
The archive variables in majordomo.cf
aren't used to archive anything. You have to use a separate archive program, or
a sendmail alias to do the archiving. The info is used to generate a directory
where the archive files are being placed by some other mechanism.
You are telling majordomo to look in the directory:
/usr/local/mail/majordomo/archive/listname
for files that it should allow to be gotten using the get command.
Majordomo comes with three different archive programs that run under wrapper, that do various types of archiving. Look in the contrib directory.
2.8 - config-test can't seem to find ctime.pl or resend can't find
getopts.pl
ctime.pl and getopts.pl are included in the standard Perl
distribution. If it can't find it, it means Perl was not installed correctly.
Re-install Perl. (you may want to take the opportunity to upgrade Perl, too)
2.9 - A list is visible via lists, but can't subscribe or 'get'
files
[From Brent Chapman]
I'll bet your list name has capital
letters in it... Majordomo smashes all list names to all-lower-case before
attempting to use the list name as part of a filename. So, while it's OK to
advertise (for instance) "Majordomo-Users" and have the headers say
"Majordomo-Users", the file names and archive directory names themselves all
need to be in lower case. If you want to use mixed case, simply configure the
list using the lower-case names everywhere, except put the mixed-case version in
the "-l" and "-h" flags to resend.
Section 3: Setting up mailing lists and aliases
3.1 - How do I direct bounces to the right address?
You should use
'resend' to filter all messages. Make sure the "sender" variable in the list
config file points to "owner-listname" and that you have defined the
"owner-listname" alias to point to the owner of the list.
What this does is force outgoing mail to have the out-of-band envelope FROM be "owner-listname", and thus all bounces will be redirected to that address. (Users often see this mirrored in the message body as the "From " or "Return-Path:" header). 'resend' also inserts a "Sender:" line with the same address to help people identify where it came from, but that header is not used for the bounce address.
If you are using sendmail v8.x, you don't have to use 'resend' to do the same thing. You simply have to define an alias like this:
owner-sample: joe,
Note the trailing comma is necessary to prevent sendmail from resolving the alias first before putting it in the header. Without the comma, it will put "joe" in the envelope from instead of "owner-sample". Either address will work, of course, but the generic address is preferred should the owner ever change.
However if you choose not to use 'resend', you will have to do without much of majordomo's other features like moderating, administrivia checks, and others.
3.2 - Semi-automated handling of bounced mail
This is not true
automation of bounced mail. What this does is the next best thing. You
unsubscribe the user from the list, but add the user to a special 'bounces' list
(there's a perl script in the distribution called bounceyou run to
make this easier) The majordomo maintainer then runs (out of cron) the
'bounce-remind' script periodically, which sends mail to all the people on the
bounces list, saying essentially "you were removed from list 'foo' because mail
to you bounced. To subscribe yourself back to the list, send the following
commands ...". There's no facility yet for trimming the bounces list, but it's
easy to write one because the date the person was added to the bounces list is
included (so you could write a perl script which removes anyone on the list for
more than one week, assuming you run bounce-remind more than once a week).
There's no facility for automatically detecting what addresses are failing. You
have to determine that based on the bounce messages you receive from other
sites.
[From John Rouillard]
Just create a mailing list called "bounces". I
usually set mine up as an auto list just to make life easier.
All that "bounce" script does is create an email message to majordomo that says:
approve [passwd] unsubscribe [listname] [address] approve [passwd] subscribe bounces [address]The [address] and [listname], are given on the command line to bounce. The address of the majordomo, and the passwords are retrieved from the .majordomo file in your home directory.
A sample .majordomo file might look like (shamelessly stolen from the comments at the top of the bounce script):
this-list passwd1 Majordomo@This.COM other-list passwd2 Majordomo@Other.COM bounces passwd3 Majordomo@This.COM bounces passwd4 Majordomo@Other.COMA command of "bounce this-list user@fubar.com" will mail the following message to Majordomo@This.COM:
approve passwd1 unsubscribe this-list user@fubar.com approve passwd3 subscribe bounces user@fubar.com (930401 this-list)while a command of "bounce other-list user@fubar.com" will mail the following message to Majordomo@Other.COM:
approve passwd2 unsubscribe other-list user@fubar.com approve passwd4 subscribe bounces user@fubar.com (930401 this-list)Note that the date and the list the user was bounced from are included as a comment in the address used for the "subscribe bounces" command.
3.3 - What's this Owner-List and List-Owner stuff? Why both?
[From
David Barr]
The "standard" is spelled out in RFC 1211 - "Problems with the
Maintenance of Large Mailing Lists".
It's here where the "owner-listname" and "listname-request" concepts got their start. (well it was before this, but this is where it was first spelled out)
Personally, I don't use "listname-owner" anywhere. You don't really have to put both, since the "owner" alias is usually only for bounces, which you add automatically anyway with resend's "-f" flag, or having Sendmail v8.x's "owner-listname" alias.
(while I'm on the subject) The "-approval" is a Majordomo-ism, and is only necessary if you want bounces and approval notices to go to different mailboxes. (though you'll have to edit some code in majordomo and request-answer if you want to get rid of the -approval alias, since it's currently hardwired in)
So, to answer your question, I'd say "no". You don't have to have both. You should just have "owner-list".
3.4 - How should I configure resend for Reply-To headers?
Whether
you should have a "Reply-To:" or not depends on the charter of your list and the
nature of its users. If the list is a discussion list and you generally want
replies to go back to the list, you can include one. Some people don't like
being told what to do, and prefer to be able to choose whether to send a private
reply or a reply to the list just by using the right function on their mail
agent. Take note that if you do use a "Reply-To:", then some mail agents make it
much harder for a person on the list to send a private reply. The most important
reason why Reply-To: to the list is bad is that it can cause mail loops if any
of the members of your list are running fairly-common but broken software which
doesn't know what an envelope address is. (Many Microsoft products, as well as
many other PC-based non-SMTP/Internet mail systems which work through an SMTP
gateway.)
You should read the following FAQ on why you shouldn't set the Reply-To: field. http://www.unicom.com/FAQ/reply-to-harmful.html
If you are using resend, use the 'reply_to' configuration variable in the list .config file.
3.5 - How can I hide lists so they can't be viewed by 'lists'?
That
is what advertise and noadvertise are for. These two variables take regular
expressions that are matched against the from address of the sender. A list
display follows the rules:
3.6 - How can I restrict a list such that only subscribers can send mail to
the list?
See the restrict_post variable in the config file. Just set it
to the filename that holds the list of subscribers. Unfortunately this means you
probably will need help from the Majordomo maintainer in setting it if you don't
have access to the host machine. This is due to be improved in a future release
of Majordomo.
However, there is a problem with either of these methods. Majordomo works by filtering the messages coming in through the "listname" alias, doing its dirty work, then passing the resulting message out to another alias you define like "listname-outgoing". If you trust people to not send mail directly to the "listname-outgoing" alias, then you'll be fine. If however you're not trusting, there are several steps to make sure people don't bypass the restrictions of the list.
There are several methods. First you need to change your "listname-outgoing" alias such that it is not obvious. Next, you need to make it such that people can't find out what your -outgoing alias is.
You can use the "@filename" directive in resend to move the command-line options of resend into a file readable only by the majordomo user/group. This will make it such that you can't find out the -outgoing address by connecting to your mailer and doing an EXPN or VRFY. The "@filename" directive seems to have fallen into undocumentation for some reason. This should be fixed in future releases.
Another more direct approach is to simply disable EXPN or VRFY altogether. See the documentation for your mailer on how to do this. However this doesn't prevent local reading if the aliases file.
Sendmail 8.x will unfortunately log your -outgoing alias in the "Received:" lines. To get around this you need to specify more than one address for the list name argument to resend. (for example "mylist:|"/usr/local/lib/majordomo/wrapper resend -h foo.org -l mylist mylist,nobody"" where nobody is an alias for /dev/null) For Sendmail 8.x you must not define an alias 'owner-mylist-seekrit' to be something like 'owner-mylist,' (with the commma). Otherwise sendmail will set the envelope address of outgoing mail to contain your secret outgoing alias.
Finally it should be noted that it is impossible with any method to prevent people from forging mail as someone on the list, and sending to the list that way.
3.7 - Can I have the list owner or approval person be changeable without
intervention from the Majordomo owner?
Sure! Just make owner-listname
and/or listname-approval be another majordomo list. (probably hidden, for
simplicity's sake)
3.8 - What are all these different passwords?
Think of three
separate passwords:
Note that the admin passwd in the config file is not a file name, but the password itself. This is the only way that the list-maintainer could change the password since they wouldn't have access to the file.
3.9 - How do I tell majordomo to handle "get"-ing of binary
files?
Majordomo is not designed to be a general-purpose file-by-mail
system. If you want to do anything more than trivial "get"-ing of text files
(archives, etc) than you should get and install ftpmail. Majordomo has hooks to
allow transparent access to files via ftpmail (see majordomo.cf). See the
beginning of this FAQ for where to get ftpmail.
3.10 - How do I set up a moderated list?
First, you need to tell
Majordomo that the list is moderated. In the configuration file for the list,
you set "moderated = yes". Do not try to use the now-deprecated "-A" option to
resend. In fact you shouldn't be using ANY options to resend except "-h" and
"-l", since all the others are handled in the config file.
Any mail which is not "approved", gets bounced with "Approval required". If
the moderator wishes to approve the message for the list, then you need to tag
the message as "approved" and send it to the list. The "approve" script which
comes with Majordomo does this for you. If you don't have access to "approve"
(e.g. you're not on a UNIX system with Perl), you have to do it by hand. The
easiest way is to forward the original message to the list, add the line
"Approved: approval-password" to the very first line of the body, and
then the entire contents of the original message. (meaning there should not be a
blank line before and after the "Approved:" line.)
Alias entry:
You'll need to modify request-answer slightly if you want the virtual host to
be used there in replies. Look for:
it gets treated these as the three addresses: [From Alan Millar] Remember that all Majordomo does is add and remove addresses from a list.
Majordomo does not interpret the contents of the list for message distribution;
the system mailer (such as sendmail) does.
I'm using SMail3 instead of sendmail, and it has an alternative (read
"stupid") view of how mixed angle-bracketed and non-angle-bracketed addresses
should be interpreted. I found that putting a comma at the end of each line was
effective to fix the problem, and I got to keep my comments. So I patched
Majordomo to add the comma at the end of each address it writes to the list
file.
You can also change to "strip = yes" in the config file so that none of the
addresses are angle-bracketed.
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. 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): 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.
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:.
3.11 - How do I set up a digested version of a list?
[ Modified from
explanation given by jmb@kryten.atinc.com (Jonathan M. Bresler)]
3.12 - How do I setup virtual majordomo domains?
[From Alan Millar,
et. al.]
Set up a majordomo.cf file for each virtual domain, defining
$whereami as appropriate. Use your mailer's virtual domain stuff to get to it,
making an alias for it if necessary.
majordomo-domain2: |/your/wrapper majordomo -C /your/domain2.cf
Virtual domain stuff:
majordomo@domain2 = majordomo-domain2
majordomo-owner@domain2 = whoever
I use the sendmail virtual domain examples right off the Sendmail
FAQ. Works for me.
From: $list-request
in the source and change it to: From: $list-request\@$whereami
Don't forget to use the -C option to request-answer for your virutal
aliases.
Section 4: Miscellaneous mailer problems
4.1 - Address with blanks are being treated separately
If a
subscriber to the list is
John Doe < jdoe@node.com>
John
Doe
<
jdoe@node.com>
Majordomo does not treat these as three addresses.
Apparently your mailer does.
4.2 - Why aren't my digests going out?
[from John Rouillard] echo mkdigest [digest-name] [digest-password] | mail majordomo@...
This will force a digest to be created. Or you can set the max size in the
digest list config file down low, and force automatic generation.
4.3 - Why do I get duplicate mail sent to the list?
If you're
running MMDF, read on: [From Gunther Anderson]
Well, I can tell you what
happened to me recently. We use MMDF here, which certainly colors the picture a
little. What was happening here was that MMDF was verifying the validity of the
whole mailing list before returning from the Submit call. The thing calling the
Submit would time out and close, but the Submit itself would still be running
somewhere. The calling routine would believe that the message had failed in its
delivery, but the Submit would eventually succeed. The calling process would try
again some time later. This, of course, is bad. The larger the list got, the
more addresses there were to verify (verification 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).
[ 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/.
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.
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.
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.