From: barr@pop.psu.edu (David Barr)
Newsgroups: comp.mail.misc,comp.mail.sendmail,comp.mail.smail,comp.answers,news.answers
Subject: Majordomo Frequently Asked Questions
Date: 30 Aug 1994 10:03:08 -0400
Organization: Penn State Population Research Institute
Message-ID: <majordomo-faq_778255381@pop.psu.edu>

Version: $Id: majordomo-faq,v 1.12 1994/08/24 14:09:04 barr Exp barr $
Archive-Name: mail/majordomo-faq
Posting-Frequency: monthly

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 and other problems

This FAQ is Copyright 1994 by David Barr and The Pennsylvania State
University.  This document may be reproduced, 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.  If you have any questions or submissions regarding
this FAQ, send them to David Barr <barr@pop.psu.edu>.


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

Here's a short list of some of the features of Majordomo.

- supports various types of lists, including moderated ones.
- List options can be set easily through a configuration file,
  editable remotely.
- Supports archival and remote retrieval of messages.
- Supports digests.
- Written in Perl, - easily customizable and expandable.
- Modular in design.
- Includes support for FTPMAIL.


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

The FTPMAIL package can be found in ftp://src.doc.ic.ac.uk/packages/ftpmail
or any comp.sources.misc archive (volume 37).


Subject: How do I install it?
-----------------------------

Majordomo comes with a rather extensive README.  Read this file
completely.  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 README or other documentation in the Majordomo distribution.


Subject: How do I upgrade from an earlier release?
--------------------------------------------------

Be sure to browse the "Changes" and "Changelog" files 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.

Subject: Which is better, Majordomo or LISTSERV?
------------------------------------------------

Here's a slight revision of something Chris Koenigsberg posted to
comp.mail.misc, following up a thread there. Tasos, the author of
ListProc, said that he was basically on the mark concerning ListProc.

Chris Koenigsberg: ckk@uchicago.edu, ckoenig@midway.uchicago.edu
U. of Chicago Academic Information Technologies

########################

The real LISTSERV (Revised LISTSERV) relies on Bitnet networking
transport protocols.

A complex Unix list processor was written, in a partial emulation of
the Bitnet LISTSERV. The "Listserv for Unix" system was renamed
"listproc" last summer, after threats from the original LISTSERV
author, because it differs in user interface and list owner interface
from LISTSERV, and was accused of misleading users who would confuse
it with the "real thing".

Majordomo was written, in Perl, because listproc (AKA Unix LISTSERV)
was too complex and did not do quite what was needed to manage a set of
Usenix SAGE mailing lists.

LISTSERV and ListProc want the whole world to be interconnected, i.e.
all mailing list server hosts can know about each other and exchange
info on remote lists; someday I imagine there'll be a DNS-like
namespace of mailing lists and server hosts out there somehow.

Majordomo, on the other hand, is a much smaller package, designed for
easier administration on an individual host, and I have even heard (on
the Majordomo-Users list) that some Majordomo hosts do NOT wish their
lists advertised publicly on the net.

We (U. of Chicago Academic Information Technologies) are planning to
go ahead and offer new campus list management service soon using
Majordomo, but we did have some requests from faculty to use listproc
(they asked for LISTSERV but since this is on Unix, they would have to
get listproc instead).

I tried briefly to configure and build listproc for a comparison test,
but gave up when it got weird, probably too soon, maybe I'll try again
when I have more time to play with compilers etc :-) Listproc
documentation etc. is a bit cryptic and not well thought out overall,
at least from the point of view of someone new to the concept trying
to understand all of its complex workings.  I have seen correspondence
from the Listproc author, on the listproc users' mailing list
archives, where he defends his documentation because it is in the
usual Unix style.  (maybe "damning by faint praise"? :-)

Majordomo is simpler and written in Perl scripts, so documentation is
more comprehensive, and is improving, as an active community of
developers is contributing to it.  It only took 2 days for the current
maintainers to put out small patches to fix some recently-discovered
potential security holes, and since it's Perl, no recompilation is
needed.

Listproc requires a server daemon to be alive, which forks off child
processes somewhat like lpd, and appears to be designed to do a lot of
complex, tricky things which requires a lot of C source code doing
networking stuff (multi-level automated archiving and indexing, with
retrieval via ftpmail, automatic digestification creation and
propagation, remote cooperation of "peer" list hosts, interactive
administration via TCP connections, operation over other transport and
delivery protocols besides TCP and SMTP, maintain its own message
queueing system independently of the system mail queues, ...), which
are perhaps overkill (for us, in a completely Internet TCP/SMTP
environment), perhaps not, this is what I'd like to hear more
discussion about.

Majordomo is more focused on the essentials of individual mailing list
management, and is implemented as Perl scripts, which are modular and
can be used in subsets, as they are individually invoked out of system
mail aliases. It lets the underlying system software do the networking
and message queueing stuff, so it doesn't have to deal with TCP
sockets etc. Majordomo's recently-added archiving, digestification,
etc. is simpler than listproc's, and is undergoing more improvements.

Apparently, Listproc's daemon with its own queueing system used to
give better performance, for high-traffic lists on heavily loaded
server hosts, than older versions of sendmail. But now, newer sendmail
versions have greatly improved efficiency so Majordomo with new
sendmail may be just as fast and load-capable as a Listproc system.
(comments welcomed on this point?)

With Listproc, if you can get it configured and running smoothly, you
can apparently join a growing inter-operating network of cooperating
"peer" list hosts, and even inter-operate with Bitnet LISTSERV list
hosts too. Thus your local users can easily find out about other lists
elsewhere, you can have local re-distributions for a larger global
list, etc. (but re-distributions can be a source of administrative
headache when global list owners try to track down mysterious errors,
or unsubscribe requests from people who aren't subscribed to the
global list.... :-).

One big flaw in Listproc's design, in my opinion (correct me if I'm
wrong!), is that it does funny things to the headers of outgoing
messages which are arguably "wrong" in the RFC 822 SMTP world (I've
seen arguments in the listproc users' archives), and for
incoming messages, it only uses the Unix From field (i.e. the SMTP
Envelope MAIL FROM, in the SMTP world) to determine the sender's
identity, for subscribing, unsubscribing, accepting or rejecting
messages, etc.

Majordomo on the other hand will use the RFC 822 headers (Gene
Spafford's Perl code for parsing mail headers), so it will recognize a
"Reply-To:" for example, and will allow you to subscribe your
canonical address, even if the return path of your message is
convoluted (although the list owner may need to approve your
subscription). You have various per-list configuration options, about
what appears in the various RFC 822/SMTP headers, concerning the
return address for errors, the default reply address (to the list, to
the original author, to the list owner/moderator, etc.)...

Both Listproc and Majordomo share concepts like moderated lists.
Listproc's moderated lists have a queue of incoming messages, and the
moderator has to approve or reject them by giving the message queue
numbers to the server, in order to clear the queue.

For a moderated list, Majordomo simply bounces messages to the
moderator and then forgets about them, so the moderator can easily
re-submit them with an approval password in a new header. Any message
arriving with the proper approval password header will be
automatically approved and propagated to the list.

An outfit called CREN, an offshoot of Educom, has taken over the
development of both the Bitnet LISTSERV, and the Unix Listproc, and is
planning to offer a commercial version of Listproc sometime later in
1994. They have a global vision building on the inter-operating "peer"
list host concept, integrating gopher, ftp, etc. (their vision
statement doesn't mention WWW but I assume that must be added soon
:-).

We are very interested to see if CREN's new Listproc version will come
with improved support, including better documentation, and we might
consider switching to it sometime in the future, but we are planning
to stick with Majordomo for now.


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 when you compiled the wrapper.


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.


Subject: I told majordomo where to archive the list, why isn't it working?
--------------------------------------------------------------------------
In message <9405102139.AA18528@csrp.tamu.edu>, neils@csrp.tamu.edu writes:
> I don't get it: is the list archive a file or a directory?  
> I chose directory and it doesn't work, though I'm not sure why.
> The relevant majordomo.cf entry looks like: 
> $filedir = "/usr/local/mail/majordomo/archive";
> $filedir_suffix = "";

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

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,

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.


Subject: Semi-automated handling of bounced mail
------------------------------------------------
>The documentation, I guess, isn't very clear on this, but how does one 
>implement the bounce list/bounce-remind program so that people that go 
>'boing' can be dealt with in a somewhat more automated manner?
>
>Uh . . . how exactly is this accomplished?

[From John Rouillard]
There is nothing special about this. Just create a mailing list called
bounces. I usually set mine up as an auto list just to make life
easier.

All that bounce 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.GOV
       bounces         passwd3         Majordomo@This.COM
       bounces         passwd4         Majordomo@Other.GOV


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


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.


Subject: A list is visible via lists, but can't subscribe
---------------------------------------------------------
>Hi, I just tried to set up a mailing list using majordomo. My list show up
>when I send the lists command but when I try to subscribe, I get back the
>message 'unknown list'.

[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 _files_ all need to be "majordomo-users*".


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)


Subject: Why aren't my digests going out?
-----------------------------------------

[from John Rouillard]
>I'm not sure how to set up the digest feature of majordomo 1.92 to send
>digests out.  Currently, it is digesting incoming mail, but that's all it's
>doing.  

  "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. There are some patches for 1.92 that will allow other ways
of specifying automatic digest sending. The patch is in the contrib
directory.

