Technical Support: Managing Majordomo Lists

Majordomo makes day-to-day operation of a mailing list easier, but there are still things to do. If your mailing lists are open (anyone can subscribe) and unmoderated (anyone can post), you'll get fewer messages, but you should still expect some.

When mail (a subscription, unsubscription, or an article intended for a moderated list) needs approval, majordomo sends the message to the list owner(s). Any list owner (and in fact, anyone who knows the list password) can send an approval message back to Majordomo to approve the request.

A "list owner" is the person (or people) listed on the "listname-approval" alias in your system aliases file. (For sendmail, that filename is usually /usr/lib/aliases or /etc/aliases.)

Note that Majordomo lets you put different people on the "listname-approval" and "listname-owner" aliases. If you split those duties between two different people, keep that in mind as you read the sections below. I've assumed that all list messages needing action go to a single "list owner."

 

Topics in this document:

A List Owner's Account

All a list owner needs is to be able to send and receive e-mail. The owner doesn't need to have login access to the system where the list is handled.

The list owner doesn't even need to be on a UNIX system, although majordomo comes with some UNIX scripts that make life easier for the list owner.

Majordomo Commands for List Owners

The requests for users can also be used by list owners. But there are three more password-protected commands just for list owners. These aren't mentioned in Majordomo's help file. If the owner doesn't have an account on the machine where Majordomo runs, these commands allow routine housekeeping via e-mail:

Approving Subscriptions and Moderating with "approve"

The list owner will receive three types of mail messages from Majordomo: Majordomo includes "approve", a Perl script for making these chores easier. For subscription requests, "approve" sends an e-mail message back to "majordomo" indicating that the subscription should be accepted. For messages submitted to moderated lists, "approve" adds an "Approved:" header and re-sends the message to the list. The next two sections show how to do these things manually in case the list owner is on a system where "approve" (or Perl) can't run. They also show the e-mail messages that fly back and forth.

"approve" can be run either on the machine where majordomo is running or on a remote machine where the list owner is managing the list by e-mail. The "approve" script assumes that the Perl interpreter is in /usr/local/bin/perl. If Perl is somewhere else, the first line of the "approve" script should be edited to the path for that system: 

   #! /usr/local/bin/perl
"approve" uses a file named ".majordomo" (the name starts with a dot) in the owner's home directory. It has an entry for each of the owner's lists: the list name, list password and e-mail address of its Majordomo server. There's a tab character (NOT space characters) between the three fields in each line. For example, this is the ".majordomo" file for the owner of the "donut-makers" and "mud-wrestlers" mailing lists: 
   donut-makers    !BooM!  majordomo@bakers.org
   mud-wrestlers   GoJoan  majordomo@foo.bar.com
For security, it's a good idea to protect the file from other users. Use a command like "chmod 600 .majordomo".

To approve a request, feed the original approval-request message from Majordomo to the "approve" script. Messages can be saved in separate files, one per message, and named on the command line: 

   % approve file1 file2 etc.
Messages can also be fed to the standard input of "approve". For example, in MH mail, where the "show" command displays a message: 
   % scan 32
     32+ 09/05 Majordomo@bakers.o APPROVE donut-makers<<-- postmaster@yu
   % show | approve
Or in "mush", the Mail User's Shell: 
      ...
   > 32   Majordomo@bakers.org  Sep  5, (29/804) "APPROVE donut-makers"
      ...
   Msg 32 of 78: pipe approve
The command in the Berkeley "mail" program is simply a vertical bar (|). (For other mailers, check your documentation or help screen.)

Approving Subscriptions without "approve"

It's possible that a list owner may be using a PC or some other system where the "approve" script won't work. In that case, everything that "approve" does can be done manually. This section and the next may also be useful for those who want to know what "approve" does in more detail.

If someone sends a non-routine subscription to "majordomo", the server sends a message to the list owner. There are two kinds of non-routine subscription. One is when the person sends a subscribe/unsubscribe command with a different e-mail address than their own. The other is if the list is "closed"--that is, when the owner must approve all new subscriptions.

For example, the system postmaster at a bakery might want to set up a list exploder (see Chapter 2) for the "donut-makers" mailing list. She adds an exploder named donut-makers-dist@yummybake.com and sends this mail to the Majordomo server: 

   From: postmaster@yummybake.com
   To: majordomo@bakers.org

   subscribe donut-makers donut-makers-dist@yummybake.com
When Majordomo gets the message, it sees that the subscription address isn't the same as the sender's address. So it sends the following mail message to the list owner: 
   From Owner-Majordomo@bakers.org Sun Sep  5 08:56:09 1993
   To: donut-makers-approval
   From: Majordomo@bakers.org
   Subject: APPROVE donut-makers
   Reply-To: Majordomo@bakers.org

   --
   postmaster@yummybake.com requests that you approve the following:

       subscribe donut-makers donut-makers-dist@yummybake.com

   If you approve, please send a message such as the following back to
   Majordomo@bakers.org (with the appropriate PASSWORD filled in, of course):

       approve PASSWORD subscribe donut-makers donut-makers-dist@yummybake.com

   If you disapprove, do nothing.  Thanks!

   Majordomo@bakers.org
If an owner doesn't want to apprive the subscription request, I suggest that he not just "do nothing." If a subscription is rejected, it's a good idea to reply and explain why. Otherwise, the subscriber will probably write to ask because she already got a message like this: 
   From Owner-Majordomo@bakers.org Sun Sep  5 08:56:09 1993
   To: postmaster@yummybake.com
   From: Majordomo@bakers.org
   Subject: Majordomo results
   Reply-To: Majordomo@bakers.org

   --
   >>>> subscribe donut-makers donut-makers-dist@yummybake.com
   Your request to Majordomo@bakers.org:

           subscribe donut-makers donut-makers-dist@yummybake.com

   has been forwarded to the owner of the "donut-makers" list for approval. 
   This could be for any of several reasons:
       You might have asked to subscribe to a "closed" list, where all new
           additions must be approved by the list owner. 
       You might have asked to subscribe or unsubscribe an address other than
           the one that appears in the headers of your mail message.
   When the list owner approves your request, you will be notified.

   If you have any questions about the policy of the list owner, please
   contact "sample-approval@bakers.org".  Thanks!

   Majordomo@bakers.org
As the message to the list owner explained, the owner can approve the subscription by mailing an "approve" command to the majordomo server: 
   From: owner-name@owner-address
   To: Majordomo@bakers.org

   approve !BooM! subscribe donut-makers donut-makers-dist@yummybake.com
(where "!BooM!" is the list password).

Moderating Lists without approve

This section describes how to moderate messages manually if you can't use "approve". It also shows the messages that get passed between the list owner and Majordomo.

Here's a message that the "donut-makers" list owner just received: 

   Date: Sun, 5 Sep 93 22:17:34 PDT
   To: Donut-makers-Owner@bakers.org
   From: Donut-makers-Owner@bakers.org
   Subject: BOUNCE Donut-makers@bakers.org: Approval required

   >From elliek@hearthbake.com  Sun Sep  5 22:17:29 1993
   Date: Sun, 5 Sep 93 22:17:29 PDT
   From: elliek@hearthbake.com (Ellie Katella)
   To: donut-makers@bakers.org
   Subject: jelly donuts

   What's your favorite recipe for jelly donuts?  Thanks.
If the owner doesn't want to approve the message, it's courteous to mail a note to the original sender and explain why. (Maybe Ellie should read the "donut-makers" "Frequently-Asked Questions" list.)

There are a few ways to tell Majordomo (actually, the "resend" script) to send an approved message. The easiest is the "approve" script. Otherwise, the owner should send mail to the list address (in this case, to Donut-makers@bakers.org). The owner adds a line like this to the approved message header--or on the line before the approved message: 

   Approved: password
There are two ways to do that:

Bounced Mail and the Bounces List

List owners will get familiar with messages like these: 
   Return-Path: 

   Date: Sun, 10 Oct 93 13:24:11 EDT
   From: MAILER-DAEMON@mukluk.ice.ca (Mail Delivery Subsystem)
   Subject: Returned mail: Cannot send message for 3 days
   Message-Id: <9310101724.AA20948@mukluk.ice.ca>
   To: listown@online.ora.com

      ----- Transcript of session follows -----
   421 tuna.ice.ca: Host tuna.ice.ca is down

      ----- Unsent message follows -----
   Received: from online.ora.com by mukluk.ice.ca (4.1/4.7)
           id 
 for shh@tuna.ice.ca; Thu, 7 Oct 93 13:05:22 EDT
   Received: by online.ora.com (5.65c/Spike-2.1)
           id AA13466; Thu, 7 Oct 1993 10:13:03 -0400
   Date: Thu, 7 Oct 1993 10:13:03 -0400
       ...
If your lists will be busy, you'll probably want to set up a special list named "bounces". It's a list for subscribers of other lists whose mail starts bouncing. The address of the subscriber is removed from the list they used to belong to and added to the "bounces" list. A cron job runs the "bounce-remind" script every night to send mail to all the people with bad addresses. The mail's "From:" address and envelope sender are set to "nobody", a user on your system whose mail goes to /dev/null. (The /dev/null file is actually a "black hole." Text written there disappears; it's thrown away.)

If the mail gets through to a subscriber, the subscriber will find out what has happened and how to fix it. If the problem isn't fixed after a while (usually, a month or so), the list owner can review the "bounces" subscriber list and remove the hopeless cases.

To set up the "bounces" list:

  1. Make sure that the "nobody" user exists on your system. There should also be a mail alias for "nobody" pointing to /dev/null: 
          nobody: /dev/null
    If your system doesn't have that user and can't create it, you can get by. Make a mail alias that has an obvious name ("trashcan", "dustbin", "nothing", etc.) pointing to /dev/null; use it in the setup below.

     

  2. Follow the steps in the section "Creating a New List" to make the "bounces" list. Here's the main entry for "resend": 
          bounces: "|/usr/local/majordomo/wrapper resend -p junk
          -l Bounces -f nobody -h foo.com.au -s bounces-outgoing"
    The priority "junk" helps stop mail bounces.

     

  3. Check the "bounce-remind" script to be sure that the path to the Perl interpreter on the first line is correct. Take a quick look through the script.

     

  4. Make a crontab entry to run "bounce-remind" once a night.

     

  5. Help list owners set up their accounts with the "bounce" script. Remember that the owners' ".majordomo" files need an entry for the "bounces" list as well as the other lists.

Bounced messages come in so many different formats that it's hard to completely automate subscriptions to the "bounces" list. (In fact, in some cases, the addressee of the bounced mail won't even be shown in the message!) If the list owner's system can run a Perl script, the "bounces" script makes the job easy. The script works differently than "approve". The script doesn't read a message from a file or standard input. Instead, it reads its command line arguments: 

   % bounce listname user@xyz.com
That command would unsubscribe the address user@xyz.com from the "listname" list and add them to the "bounces" list. An owner who can't run the "bounce" script can send mail to Majordomo with two commands like these: 
   approve passwdA unsubscribe listname user@xyz.com
   approve passwdB subscribe bounces user@xyz.com (931005 listname)
The first command unsubscribes the user from the current list. The second one subscribes the user to the "bounces" list, with a comment that shows the date and the name of the list they used to belong to.

The Majordomo Log File

Majordomo keeps a log file. The file's pathname is set in the $log variable in your majordomo.cf file. It's a good idea to read the file every day or two.

When Majordomo is busy (such as after you've added a new list), you may want to run "tail -f" to watch messages as they're being added to the log. Clean it out periodically. I've found it useful to keep compressed copies of old log files for reference.

The log file won't give you much help with security problems. (As Brent has made clear, security wasn't one of Majordomo's main goals.) Transactions are logged with the "Reply-to:" or "From:" address in the mail message header. For example, you can send a message like this: 

   Reply-to: John Doe 

   From: Your-real-name 

   To: majordomo@bakers.org

   passwd donut-makers oldpassword newpassword
This is what will be logged (and it will be "FAILED" only if the old password was incorrect): 
   Sep 05 21:06:31 bakers majordomo[27604] {johndoe@nowhere.org}
            FAILED passwd donut-makers OLD NEW
There's no trace of the original sender or any way to see the "OLD" password he tried. One way to track messages like these is by reading your system MTA log file. Another is by making duplicates of all mail sent to "majordomo". For instance, the following alias would send a copy of all majordomo requests to "owner-majordomo": 
   majordomo: owner-majordomo, "|/usr/local/majordomo/wrapper majordomo"
Of course, on a busy system, the person who is "owner-majordomo" will get a lot of mail; a mail filter program like "procmail" can store that mail and help to sort out the messages you might really want to see. (You can get "procmail", by Stephen R. van den Berg, from many anonymous FTP sites.) Instead of a mailbox address, you can also give the absolute pathname of a log file. Note that, in many cases, the file will need to be world-writable (mode 622 or 666).

Managing the Archives

An archive is a file containing messages that previously appeared on the mailing list. You can create an archive simply by putting an entry in the system MTA alias file as described in the section "Creating a New List".

A list's archive will keep growing forever until you truncate or split it. It's a good idea to split the file once in a while. Otherwise, people who "get" it can receive a HUGE mail message. (Worse, some mailer may truncate the file or refuse to send it.)

Majordomo doesn't come with fancy archive management tools. The Majordomo distribution comes with a Perl script named "split_archive.pl"--it's in the "Tools" subdirectory. It splits an archive file into separate files, one per message, named 0001, 0002, and so on.

You can also put any ASCII file in the archive, and set up a directory hierarchy. But you need to do this by hand. For example, if you want majordomo to mail files that contain non-text characters, you'll need to pre-process the files with a utility like "uuencode" or "btoa".

If your site has an anonymous FTP area, you can set Majordomo to store your archives there. You can also configure the majordomo.cf file to handle "get" commands by mailing requests to an ftpmail server. (See the section "Installing Majordomo".) To do that, define the variables $ftpmail_address (and, optionally $ftpmail_location--the default is the local host) in the majordomo.cf file. The ftpmail setup assumes that the FTP archive is structured the same way as your local archive directory. It uses the pathname $filedir/listname$filedir_suffix for the archive directory, then issues an FTP "get" command for the file specified.

Disabling Majordomo Temporarily

Once Majordomo is running on your system, how do you do maintenance? It's always active because mail aliases will start the program anytime. If you make a mistake in your maintenance, mail can start to bounce. One way is to shut off your system's sendmail daemon, but that affects all mail on your system.

An easier way is to make a small "stub" shell script named "majordomo.hold": 

   #! /bin/sh
   exit 75
Make that file executable with "chmod 755 majordomo.hold". Then quickly (so there's less chance of causing incoming mail to bounce) swap the "majordomo" Perl script and your "majordomo.hold" script: 
   % mv majordomo majordomo.tmp && mv majordomo.hold majordomo
(The shell's "&&" operator lets you type both command lines before executing either of them. It does the second "mv" command only if the first one succeeds.) When mail comes in, sendmail will run your little script, which will return an exit status of 75. This special status makes sendmail defer (queue) the incoming message and try to deliver it to "majordomo:" again later. When you're done with your maintenance, swap the script with the real "majordomo" script and mail will be processed again. (Special exit statuses like 75 are listed in the file /usr/include/sysexits.h.)

The same thing works with "resend"; disabling it will disable all of the lists.

Note that your sendmail may convert pathnames of commands run by deferred messages to all lower-case letters. This problem may only bite you after you defer messages. For example, if your "resend" alias starts like this: 

   sample: "|/usr/local/majordomo/wrapper resend
       -A -a /usr/local/majordomo/lists/Sample.passwd
The "L" and "S" in that pathname may be changed to "l" and "s" when the message is deferred. If they are, "resend" won't be able to find the password file. The fix for this problem is to either change your sendmail.cf file or make all your file and directory names with only lower-case letters.