Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso/answers/mail/majordomo-faq

Internet Message Format | 1994-09-29 | 31KB

Path: bloom-beacon.mit.edu!hookup!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!news.pop.psu.edu!not-for-mail
From: [e-mail] (David Barr)
Newsgroups: comp.mail.misc,comp.mail.sendmail,comp.mail.smail,comp.answers,news.answers
Subject: Majordomo Frequently Asked Questions
Supersedes: <[e-mail]>
Followup-To: comp.mail.misc
Date: 29 Sep 1994 10:03:10 -0400
Organization: Penn State Population Research Institute
Lines: 747
Approved: [e-mail]
Expires: 2 Nov 1994 14:03:01 GMT
Message-ID: <[e-mail]>
NNTP-Posting-Host: bosnia.pop.psu.edu
Summary: This is a list of frequently asked questions about Majordomo,
    a Perl-based package for managing mailing lists
Xref: bloom-beacon.mit.edu comp.mail.misc:9630 comp.mail.sendmail:9533 comp.mail.smail:635 comp.answers:7490 news.answers:26463


Version: $Id: majordomo-faq.html,v 1.18 1994/09/25 21:18:18 barr Exp barr $
Archive-Name: mail/majordomo-faq
Posting-Frequency: monthly

   Table of Contents:
    1. What is Majordomo and how can I get it?
          + What is Majordomo?
          + Where do I get it?
          + How do I install it?
          + How do I upgrade from an earlier release?
          + Where do I report bugs in Majordomo?
          + Which is better, Majordomo or LISTSERV?
    2. Problems setting up Majordomo
          + I get an error "insecure usage" from the wrapper
          + I get "majordomo: No such file or directory" from the wrapper
          + I get an error "Can't locate majordomo.pl"
          + I get "Permission denied at ..." when majordomo runs
          + I told majordomo where to archive the list, why isn't it
            working?
          + Majordomo seems to be taking many minutes to process commands
          + I'm accumulating lots of files called /tmp/resend.*.in and
            .out,
    3. Setting up mailing lists and aliases
          + Handling bounced mail
          + Semi-automated handling of bounced mail
          + What's this Owner-List and List-Owner stuff? Why both?
          + How should I configure resend for Reply-To headers?
          + How can I hide lists so they can't be viewed by 'lists'?
          + Can I have the list owner or approval person be changeable
            without intervention from the Majordomo owner?
          + What about all of these passwords starting in version 1.90?
          + How do I tell majordomo to handle "get"-ing of binary files?
          + A list is visible via lists, but can't subscribe or 'get'
            files
    4. Miscellaneous mailer and other problems
          + Address with blanks are being treated separately
          + Why aren't my digests going out?

   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. Thanks to [e-mail]
   (Fen Labalme) for getting an HTML version started.

   You can get this FAQ by sending an e-mail message to
   [e-mail] with "get file majordomo-faq" in the body of
   the message. You can get an HTML version on the World Wide Web at
   http://www.pop.psu.edu/~barr/majordomo-faq.html. If you have any
   questions or submissions regarding this FAQ, send them to
   [e-mail] (David Barr).


     _________________________________________________________________



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



  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.





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



  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.



  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.



  WHERE DO I REPORT BUGS IN MAJORDOMO?

   Send them to [e-mail]. Be sure 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 documentation to Majordomo and this FAQ.



  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.
   [ This section is currently under revision --Dave ]

   Chris Koenigsberg: [e-mail], [e-mail]
   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



  I GET AN ERROR "INSECURE USAGE" FROM THE WRAPPER

   The argument to ".../wrapper" should be simply "majordomo", not The
   full path to majordomo or resend. "wrapper" has where to look compiled
   in to it (the "W_BIN" setting in the Makefile) for security reasons,
   and will not let you specify another directory.

   Your alias should say:


        |"/path/to/majordomo/wrapper majordomo"





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



  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.



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



  I TOLD MAJORDOMO WHERE TO ARCHIVE THE LIST, WHY ISN'T IT WORKING?



> 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/

   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.



  MAJORDOMO SEEMS TO BE TAKING MANY MINUTES TO PROCESS COMMANDS



> Commands are being processed at the rate of about one every 10 minutes.
> What's going wrong, why is Majordomo so slow?

   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.


   Check the permissions on the log file and all the directories where
   majordomo files are located. Double-check the permission on the
   wrapper.

   If you are on a non-POSIX system, it must be both suid and sgid (mode
   6755) to whatever you defined your majordomo user and group to be. It
   must not be setuid root!

   OR

   In a POSIX system the wrapper must be setuid root, and double-check
   that W_UID and W_GID are of the majordomo user and group. Don't set
   W_UID to be 0!



  I'M ACCUMULATING LOTS OF FILES CALLED /TMP/RESEND.*.IN AND .OUT WHAT ARE
  THESE AND HOW CAN I GET RID OF THEM?

   This is a known bug in Majordomo 1.92. There was a typo on line 347.
   Make this change to resend:

347c347
     unlink();


     _________________________________________________________________





Section 3: Setting up mailing lists and aliases



  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 "[e-mail]", 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.



  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 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         [e-mail]
   other-list      passwd2         [e-mail]
   bounces         passwd3         [e-mail]
   bounces         passwd4         [e-mail]

   A command of "bounce this-list [e-mail]" will mail the following
   message to [e-mail]:

   approve passwd1 unsubscribe this-list [e-mail]
   approve passwd3 subscribe bounces [e-mail] (930401 this-list)

   while a command of "bounce other-list [e-mail]" will mail the
   following message to [e-mail]:

   approve passwd2 unsubscribe other-list [e-mail]
   approve passwd4 subscribe bounces [e-mail] (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.



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



  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.

   If you are using resend, use the '-r ' flag to set the Reply-To field
   to the list, or use the 'reply_to' config keyword for 1.9x or greater.




  HOW CAN I HIDE LISTS SO THEY CAN'T BE VIEWED BY 'LISTS'?

   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.





  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)



  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.




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



  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 files and archive directory all need to be
   "majordomo-users*".
     _________________________________________________________________





Section 4: Miscellaneous mailer problems



  ADDRESS WITH BLANKS ARE BEING TREATED SEPARATELY



> Does anyone else have the problem:
>
> If a subscriber to the list is
>       John Doe
>
> Majordomo or sendmail treats this as 3 addresses:
>       John
>       Doe
>
>
> 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)



  WHY AREN'T MY DIGESTS GOING OUT?



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

   [from John Rouillard]

  echo mkdigest   | 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.