This FAQ is split into several sections:
1. What is Majordomo and how can I get it?
2. Problems setting up Majordomo
3. Setting up mailing lists and aliases
4. Miscellaneous mailer problems

This FAQ is Copyright 1994 by David Barr and The Pennsylvania State
University.  This document may be reproduced for free or for profit, so
long as it is kept in its entirety and in its original format.

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

You can get this FAQ by sending an e-mail message to
"majordomo@pop.psu.edu" with "get file majordomo-faq" in the BODY of
the message.


Section 1: What is Majordomo and how can I get it?
==================================================

Subject: What is Majordomo?
---------------------------

Majordomo is a program which automates the management of Internet
mailing lists.  Commands are sent to Majordomo via electronic mail to
handle all aspects of list maintainance.  Once a list is set up,
virtually all operations can be performed remotely, requiring no
intervention upon the postmaster of the list site.

(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 (at least 4.035, preferably 4.036).

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

Subject: Where do I get it?
---------------------------

Via anonymous FTP at:

ftp://ftp.greatcircle.com/pub/majordomo/

If you don't have Perl, you can get it from:

ftp://prep.ai.mit.edu/pub/gnu/perl-4.036.tar.gz


Section 2: Problems setting up Majordomo
========================================

Subject: I get an error "insecure usage" from the wrapper
---------------------------------------------------------

> Hello, I'm trying to install majordomo and after putting everything the
> way the documentation told me I'm getting the following error message when
> I send a message to majordomo:
>
> /usr/local/udla/etc/majordomo/wrapper: error: insecure usage
> 554 "|/usr/local/udla/etc/majordomo/wrapper
> /usr/local/udla/etc/majordomo"...
> unknown mailer error 2
>
>
> I double checked the permissions and everything looks fine to me, does any
> have any tip that would help me? Thanks in advance.

The argument to ".../wrapper" should be simply "majordomo", not
"/usr/local/udla/etc/majordomo".  "wrapper" has where to look
(/usr/local/udla/etc) compiled in to it (the "W_BIN" setting in the
Makefile), for security reasons.

Your alias should say:

        |"/users/majordomo/wrapper majordomo"


Subject: I get "majordomo: No such file or directory" from the wrapper
----------------------------------------------------------------------
Make sure that the #! statement at the beginning of all the
Majordomo executables contain the correct path to the perl
program.  (the default is /usr/local/bin/perl)  Make sure also
that majordomo and all the related scripts are in the W_BIN
directory as defined in the Makefile.


Subject: I get an error "Can't locate majordomo.pl"
---------------------------------------------------

> Whenever I send either mail to a list or a command to majordomo, receive
> the following:
> 
> Can't locate majordomo.pl in @INC at /usr/majordom/mjdm/resend line 61.
> 554 "|/usr/majordom/mjdm/resend -p bulk  -l test -f brian -h  -s
> test-outgoing".
> .. unknown mailer error 2

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


Subject: I get "Permission denied at ..." when majordomo runs
-------------------------------------------------------------

> > shlock: open(">/usr/local/lib/majordomo/shlock.15260"): 
> Permission denied at /usr/local/lib/majordomo/shlock.pl line 131, 
> <_GEN_1> line 7.

The directory "/usr/local/lib/majordomo" needs to be writable by the
uid/gid that the "wrapper" program run as, so that Majordomo can
create its lock file.

In general, for any file Majordomo writes, both the file _AND_ the
directory the file is in must be writable by Majordomo, so that it can
create lock files and new versions of the data file (Majordomo usually
"updates" a file by creating "file.new" and then, when that has
succeeded, deleting "file" and renaming "file.new" to "file").

# Also, should everything
# in my majordomo directory by owned by majordom and the group set to
# majordom?

Basically, yes, and it should all (including the directory itself) be
writable by whatever uid/gid wrapper is set to run as.
 

Section 3: Setting up mailing lists and aliases
===============================================

Subject: Handling bounced mail
------------------------------

 > If a subscriber sends a message to a mailing list containing addresses
 > that cause bounces, then the subscriber/sender gets a copy of the
 > bounced mail.  They don't care to receive the bounce.  Can this be
 > prevented? (Without removing the offending addresses from the list --
 > I'm aware of the Majordomo 'bounce' utility.)

This was somewhat of a RTFM question.  The answer is to use 'resend'
to your advantage.  The following is an example of a sendmail alias
that I was using:

   sample: :include:/usr/local/mail/lists/sample

Whereas this example (from the 'sample.aliases' file distributed with
Majordomo) fixes the problem.

   sample: "|/usr/local/mail/majordomo/wrapper resend -p bulk -M 10000
           -l Sample -f Owner-Sample -h GreatCircle.COM -s
           sample-outgoing"
   sample-outgoing: :include:/usr/local/mail/lists/sample
   owner-sample: joe

See the 'resend.README' file for more info on resend's options.

What this does is force outgoing mail to have the out-of-band envelope
FROM be "Owner-Sample@GreatCircle.COM", 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@GreatCircle.COM,

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@GreatCircle.COM" in the envelope from instead of
"owner-sample@greatcircle.com".  Either address will work, of course,
but the generic address is preferred should the owner ever change.


Subject: What's this Owner-List and List-Owner stuff?  Why both?
----------------------------------------------------------------

>I see both of these in use, but I get tired of assigning both of them for
>every alias I add in the list.  I looked in RFC 822 and 1123, but neither
>specified anything.  So is there a standard?  Or should I just add both
>owner-list and list-owner to be safe?

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


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

If you are using resend, use the '-r <listname>' flag to set the
Reply-To field to the list.
 

Subject: How can I hide lists so they can't be viewed by 'lists'?
-----------------------------------------------------------------

> Could you add a 'private_lists' parameter to the config file that would
> prevent people from seeing that the list exists (and from getting the
> description for the list).  I think you've given us the ability to lock down
> pretty much everything else.


That is what advertise and noadvertise are for. The two keywords take
regular expressions that are matched against the from address of the
sender. A list display follows the rules:

1) If the from address is on the list, it is shown.

2) If the from address matches a regexp in noadvertise (e.g. /.*/) the list
   is not shown.

3) If the advertise list is empty, the list is shown unless 2 applies.

4) If the advertise list is non-empty, the from address must match
   an address in advertise. Otherwise the list is not shown. Rule 2
   applies, so you could allow all hosts in umb.edu except hosts in
   cs.umb.edu.


Subject: 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)


Subject: What about all of these passwords starting in version 1.90?
--------------------------------------------------------------------

Think of three separate passwords:

1) A master password that can be used by both resend and majordomo
   contained in <listname>.passwd. To be used by the master list
   manager when using writeconfig commands etc. This allows someone
   who handles a number of mailing lists all using the same password.

2) A password for the manager of this one list. The admin_passwd can be
   used by subsidiary majordomo list maintainers.

3) A password for those concerned with the list content (approve_passwd)

This way the administration and moderation functions can be split. The
original reason for maintaining <listname>.passwd was to allow a new
config file to be put in if the config file was trashed and the
admin_password was obliterated, and may still be useful to allow a
single password to be used for admin functions by the majordomo admin
or some other "superadmin"

> [...stupid question - is the admin passwd in the config file a file name
> or the password itself for the list ? ...]

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.


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


Subject: Majordomo seems to be taking many minutes to process commands
----------------------------------------------------------------------

| Commands are being processed at the rate of about two per
| hour.  It should take about three days for all 160 users to be
| unsubscribed!

Majordomo tries to lock the log file (by creating a lock file in the
directory with the log file) for 10 minutes for each log message,
before giving up.  It's typically going to log one log message for each
command in the input.  If the directory containing the file is
not writable by the Majordomo user/group, then majordomo won't
be able to lock the file and thus will take a very long time to
process commands.


Section 4: Miscellaneous mailer problems
========================================

Subject: Address with blanks are being treated separately
---------------------------------------------------------

> Does anyone else have the problem:
> 
> If a subscriber to the list is
>       John Doe <jdoe@node.com>
> 
> Majordomo or sendmail treats this as 3 addresses:
>       John
>       Doe
>       <jdoe@node.com>
> 
> Of course the first two always fail. 

[From Alan Millar]
Majordomo does not treat these as three addresses.  Your apparent
version of Sendmail does.

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 comment at the end
of each address it writes to the list file.

You can also add the $listname.strip option so that none of the
addresses are angle-bracketed.  (the "strip" config option for 1.90)
