Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Majordomo Frequently Asked Questions


[ Usenet FAQs | Web FAQs | Documents | RFC Index | Business Photos and Profiles ]
Version: $Id: majordomo-faq.html,v 1.242 2001/08/12 02:21:12 barr Exp barr $
URL: http://www.visi.com/~barr/majordomo-faq.html
Archive-Name: mail/majordomo-faq
Posting-Frequency: monthly

See reader questions & answers on this topic! - Help others by sharing your knowledge
   Note: Be sure to read the updated Section 2.1 below which explains how
   to address local security issues in majordomo if you're not running
   majordomo on a host with restricted logins.
   
   Table of Contents:
    1. What is Majordomo and how can I get it?
          + 1.1 - What is Majordomo?
          + 1.2 - Where do I get Majordomo?
          + 1.3 - How do I install it?
          + 1.4 - How do I upgrade from an earlier release?
          + 1.5 - Where do I report bugs or get help with Majordomo?
          + 1.6 - Which is better, Majordomo or LISTSERV?
          + 1.7 - How can I access Majordomo via the Web?
          + 1.8 - Is Majordomo Y2K (Year 2000) compliant?
    2. Problems setting up Majordomo
          + 2.1 - What are the proper permissions and ownership of all
            Majordomo files and directories?
          + 2.2 - I get a MAJORDOMO ABORT with "chown(...): Not owner" or
            ".. Operation not permitted"
          + 2.3 - I get "sh: wrapper: cannot execute" or "wrapper:
            permission denied"
          + 2.4 - I get "Unknown mailer error" when majordomo runs
          + 2.5 - I get an error "insecure usage" from the wrapper
          + 2.6 - I get "majordomo: No such file or directory" from the
            wrapper
          + 2.7 - I get an error "Can't locate majordomo.pl"
          + 2.8 - I told my majordomo.cf where to archive the list, why
            isn't it working?
          + 2.9 - config-test can't seem to find ctime.pl or resend can't
            find getopts.pl
          + 2.10 - A list is visible via lists, but can't subscribe or
            'get' files
          + 2.11 - I get "sh: wrapper not available for sendmail
            programs"
          + 2.12 - I get "aliasing/forwarding loop broken"
    3. Setting up mailing lists and aliases
          + 3.1 - How do I direct bounces to the right address?
          + 3.2 - Semi-automated handling of bounced mail
          + 3.3 - What's this Owner-List and List-Owner stuff? Why both?
          + 3.4 - How should I configure resend for Reply-To headers?
          + 3.5 - How can I hide lists so they can't be viewed by
            'lists'?
          + 3.6 - How can I restrict a list such that only subscribers
            can send mail to the list?
          + 3.7 - Can I have the list owner or approval person be
            changeable without intervention from the Majordomo owner?
          + 3.8 - What are all these different passwords?
          + 3.9 - How do I tell majordomo to handle "get"-ing of binary
            files?
          + 3.10 - How do I set up a moderated list? How do I approve
            messages?
          + 3.11 - How do I set up a digested version of a list?
          + 3.12 - How do I setup virtual majordomo domains?
          + 3.13 - How can I stop people from using my mailing list to
            spam my subscribers?
    4. Mailer and list administration problems
          + 4.1 - Address with blanks are being treated separately
          + 4.2 - Why aren't my digests going out?
          + 4.3 - Why do I get duplicate mail sent to the list?
          + 4.4 - How do I gate my list to and/or from a newsgroup?
          + 4.5 - How can I improve Majordomo's performance?
          + 4.6 - How can I handle X.400 addresses?
          + 4.7 - Why is the Subject of my messages missing?
          + 4.8 - I'm getting mail from majordomo with "BOUNCE:" what do
            I do? How do I stop this?
          + 4.9 - My list configuration doesn't seem to be working.
          + 4.10 - How do I set it up so that the originator of a message
            doesn't get a copy of his/her own message back?
          + 4.11 - With Smail or Exim, users subscribing to a list
            sometimes get mail sent before they subscribed
          + 4.12 - Majordomo doesn't seem to work with sendmail 8.9
          + 4.13 - I can't get Majordomo to work with RedHat Linux
       
   This FAQ is Copyright 1996 by David Barr and The Ohio State
   University. This document may be reproduced, so long as it is kept in
   its entirety and in its original format.
   
   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.visi.com/~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_Questions

   If you have any questions or submissions regarding this FAQ, send them
   to barr@visi.com (David Barr).
     _________________________________________________________________
   
Section 1: What is Majordomo and how can I get it?

  1.1 - 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 maintenance. Once a list is set up,
   virtually all operations can be performed remotely, requiring no
   intervention upon the postmaster of the list site.
   
   See the main Majordomo web page at:
   http://www.greatcircle.com/majordomo/
   
   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 is
   recommended that you use the latest release of Perl that you can get.
   You can find it at http://www.perl.com/perl/. You must upgrade to
   version 1.94.3 in order for it to work with Perl 5.004, due to changes
   in regular expressions. Unfortunately, Majordomo does NOT work with
   Perl 5.005_01, due to a bug in Perl with respect to regular
   expressions. Use Perl 5.005_02 (or greater). While Majordomo is still
   compatible with Perl 4.036, future versions will likely be Perl 5
   only.
   
   RedHat 5.2 is unfortunately shipping a prerelease version of Perl
   ("5.004m4") with some of their Linux distributions. This version is
   buggy and won't work with Majordomo (you will get "Unknown mailer
   error 9" errors). Download an install the 5.004 or 5.005 RPM instead,
   or download and updated RPM from updates.redhat.com. Many people have
   been having problems with Majordomo on DEC OSF/1 AXP systems.
   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 haven't been
   recent reports in this area, so it's assumed that later versions also
   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 could be made to
   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. There is no known
   port of Majordomo to Windows NT, Win95 or Mac. For more information,
   see the comp.os.msdos.mail-news FAQ. At last check there was a port of
   an old version (1.93) to MS-DOS/Waffle, and an old version (1.93)
   ported to OS/2. These probably aren't all that helpful for anyone
   porting Majordomo to NT.
   
   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.
     * Supports confirmation of subscriptions (to protect against forged
       subscription requests).
     * List filters
       
   See other references throughout this FAQ for some further notes on
   using these packages.
   
  1.2 - Where do I get Majordomo?
  
   Via the Web at:
   http://www.greatcircle.com/majordomo/ Via anonymous FTP at:
   ftp://ftp.greatcircle.com/pub/majordomo/
   ftp://ftp.sgi.com/other/majordomo/
   ftp://ftp.sgi.com/other/majordomo/
   
   The current version is 1.94.5, released Jan 18 2000. It is a
   collection of bugfixes and minor changes. Be sure to read the INSTALL
   file carefully so you don't leave yourself vulnerable to a security
   hole in the "wrapper" program.
   
   If you don't have Perl, you can get it from:
   
   http://www.perl.com/perl/
   
   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).
   
   Majordomo 2 is currently being developed by Jason Tibbits. Currently
   it's "alpha" quality. Join the majordomo-workers list (see below) if
   you want to use this release. You can find out how to get Majordomo 2,
   as well as information about this release at
   http://www.hpc.uh.edu/majordomo/
   
  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 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, or download it from the
   Majordomo distribution.
   
   If you have permission problems unpacking the distribution, try using
   the 'o' flag to tar to ignore user/group information.
   
   Although Majordomo is written in Perl, it does have one component
   written in C that must be compiled. This 'wrapper' program runs
   "setuid" and ensures that all Majordomo functions operate with the
   proper permissions. You will need root access to install this program
   with the correct privileges.
   
   Majordomo interfaces to the mail system (sendmail, exim, etc) through
   aliases. Adding aliases is generally a root-bound process. However, on
   some systems the process can be delegated to a separate file under
   your control.
   
   Once you get past the above two requirements, it is possible to
   maintain Majordomo lists without root access. At best, your local
   sysadmin would only be bothered twice -- once for the installation,
   and once for designating a separate alias file for your use.
   
   Majordomo 1.x is designed to work with sendmail, however will work
   with other UNIX-based mailers. For more information on setting up
   Majordomo with other mailers, see the following pages:
     * qmail - ftp://ftp.eyrie.org/pub/software/majordomo/mjqmail
     * exim - http://www.netmaster.ca/exim/majordomo.html
     * Netscape Messaging Server 2.x and 3.x -
       http://interstroom.nl/docs/nsmajordomo
     * Cyrus IMAP - see "Sendmail can't mail to a file or pipe..." at
       http://andrew2.andrew.cmu.edu/cyrus/imapd/install-FAQ.html#sendmai
       l. This is necessary because Majordomo works by delivering mail
       via pipe.
       
  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 when upgrading to 1.94 that you update your $mailer and
   $bounce_mailer variables in your majordomo.cf! There are 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
   accidentally delete your message. I'm sorry, I don't have time to do
   consulting on Majordomo. I am not a Majordomo help service. I, along
   with many others, do answer questions on the mailing lists. Let me say
   that about 90% of the answers I get are from the documentation or this
   FAQ. Many of the rest are answered by reading the source. It's really
   not that hard to figure out. The remainder of the questions I get are
   usually sendmail questions, which really should be asked in
   comp.mail.sendmail.
   
   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.
   It's a good idea to search or browse the list archives below for the
   last couple months since many of the same questions are asked (and
   answered) regularly. 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, qmail, 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 the
   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 it is probably not the most
   recent version.
   
   There is an FTP site for unofficial patches. See
   http://sol.ccsf.cc.ca.us/ftp/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 judgment 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://docuspace.uchicago.edu/dpc/general/g_maj-adm.html.
   
   Look for a great book out now from O'Reilly and Associates called
   "Managing Mailing Lists", by Alan Schwartz. You can read my review of
   the book at http://www.visi.com/~barr/managing-maillist-review.html. I
   was one of the book's technical reviewers. You can order the book at a
   discount (currently 20%) from amazon.com via the web:
     * http://www.amazon.com/exec/obidos/ASIN/156592259X/greatcircleassoc
       
   Besides getting you the book at a discounted price, using this link
   earns Great Circle Associates a small commission, which helps pay for
   their support of the majordomo and list-managers mailing lists, as
   well as distributing majordomo on their FTP site.
   
  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. http://www.faqs.org/faqs/mail/list-admin/software-faq. 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. Some are
   management interfaces for list maintenance, and some are interfaces
   for list archives (some do searching too).
     * LWGate - http://www.netspace.org/~dwb/lwgate/
     * Regan's - http://cornvalley.peak.org/Majordomo/
     * MajorCool - http://www.conveyanced.com/MajorCool/
     * MailServ - http://www.csicop.org/~fitz/www/mailserv/
     * ListTool - http://www.listtool.com/
     * Wilma (a list archive interface) - http://www.mnot.net/wilma/
     * ListQuest ( a list archive and search interface) -
       http://lq.corenetworks.com/
       
  1.8 - Is Majordomo Y2K (Year 2000) compliant?
  
   The current release of Majordomo has no known year 2000 issues. Older
   versions had problems only if you used the "archive" program to
   maintain list archives, since it used only a 2-digit year. If you use
   the new 4-digit year flags to archive you should not have any year
   2000 problems.
   
   That being said, as you can see by reading the Majordomo source,
   except for the "archive" program majordomo doesn't directly deal with
   dates so it's extremely unlikely there are any year 2000 issues. Even
   places where it does use dates (archive) it doesn't do any date
   comparisons, which is the crux of all non-cosmetic year 2000 bugs. At
   worst "archive" would overwrite your 100-year-old mailing list
   archives. I really really doubt Majordomo will still be used for 100
   years.
     _________________________________________________________________
   
Section 2: Problems setting up Majordomo

  2.1 - What are the proper permissions and ownership of all Majordomo files
  and directories?
  
   If you are running Majordomo on a host which allows logins by
   untrusted users, see the paragraph Wrapper security!" below.
   
   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
   it 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.3 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 (See the paragraph in Section 2.1
   called Wrapper security!). 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' to 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) privileges,
   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.
   
    The wrapper
    
   The wrapper is compiled in one of two ways, by uncommenting the
   correct section in the Makefile for your type of system. If you are
   unsure if your system is POSIX or not, I would suggest you assume that
   your system is not. (The default is POSIX) If things don't work right
   (for example you get symptoms of permission problems or you get an
   error from the wrapper saying to recompile using POSIX flags), then
   try POSIX.
   
   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.
   
    Wrapper security!
    
   If you are running Majordomo on a host which allows untrusted logins,
   you will need to restrict who can run the "wrapper" program. By
   default (as explained above) the wrapper can be run by "anyone" (that
   is, it has other execute permission). Because the wrapper program runs
   programs as majordomo, and because majordomo programs (such as
   "resend") allow loading of arbitrary configuration files (which are
   simply perl scripts), it's trivially possible to run arbitrary
   commands as the majordomo user. Again, this is an issue only to local
   users on the system -- if you don't have untrusted local users (i.e.
   only administrators can log into your mail server), then this is not
   an issue to worry about.
   
   To close down this hole, change the permissions of the Majordomo home
   directory to mode 750. (this is what is recommended in the INSTALL
   file) This will prevent the access by local users to the setuid
   wrapper script (which lives inside this directory). To make this work,
   you must make sure the group ownership of the home directory is the
   same as the gid your mailer runs as (for sendmail, this is "daemon").
   Otherwise, sendmail will be unable to read your list subscription
   files (the files that you :include: in your alias file).
   
   Closing down the majordomo home directory has the added benefit that
   local users will be unable to read your list subscription files,
   bypassing any privacy restrictions you may have set in majordomo.
   
   The downside of closing the majordomo home directory is that it makes
   it harder to do local administration, and also to properly run
   "./wrapper config-test" to check your configuration (since you need to
   run it as a non-root, non-majordom user, and such a user won't have
   access to the home directory).
   
    Majordomo files
    
   All files that majordomo creates will be mode 660, user "majordom",
   group "majordom" if it is running correctly (see $config_umask in the
   majordomo.cf). The "Log" file that Majordomo writes logging
   information to must have this same permission and ownership. Make sure
   any files you create by hand (.config, subscription lists) have this
   same permission and ownership. (they can also be mode 664 if you don't
   need the contents to be private to others) The permissions/ownership
   of the Majordomo programs and related files themselves aren't as
   critical, but the must all be readable to the "majordom" user/group.
   All Majordomo programs (majordomo, resend, etc.) must have the execute
   bit set. All Majordomo programs must have the correct path to Perl in
   the #! line in the beginning of the script. The 'make install' process
   should do this all automatically for you.
   
    Majordomo directories
    
   All directories under Majordomo's control ($homedir, $listdir,
   $digest_work_dir, $filedir, as defined in your majordomo.cf) must be
   at least mode 750 (or 755 if you don't use "daemon" as your majordomo
   group -- see 2.3below.). They should be user and group owned by
   "majordom". If want to allow a local user to be able to directly
   modify files or for example copy files into a list's archive
   directory, you may make the directory or file owned by that user.
   However directories and files must be then group-"majordom" writable
   (770 or 775).
   
  2.2 - I get a MAJORDOMO ABORT with "chown(...): Not owner" or ".. Operation
  not permitted"
  
   Most likely your wrapper is not installed correctly. Re-check the
   Makefile and see if the wrapper was compiled with the right UID and
   GID. See the README and the above section on how to set the
   permissions correctly. Make sure after you fix the wrapper that you
   remove (or rename) any "listname.new" or "L.listname" files found in
   your lists directory. These will likely have the wrong ownerships, and
   will cause you problems.
   
   You should have seen an error if you ran "./wrapper config-test" as a
   non-root, non-majordom user. If not, it's a bug in config-test and
   should be fixed.
   
  2.3 - I get "sh: wrapper: cannot execute" or "wrapper: permission denied"
  
   Your mailer doesn't have permission to execute the wrapper. Usually
   this is the result of too-strict permissions on either the Majordomo
   home directory or the wrapper executable.
   
   See Section 2.1 and especially the paragraph on wrapper security for
   the correct permissions on all majordomo directories and programs.
   
  2.4 - I get "Unknown mailer error" when majordomo runs
  
   First, see Question 4.13 if you are running RedHat 5.2 and are getting
   "Unknown mailer error 9".
   
   If something is wrong with your setup, the wrapper will often exit
   with various return codes depending on what the problem is. In order
   to really understand what is going on, look at the session transcript
   further down in the bounce message to see the error which is returned
   from the wrapper or from Majordomo. You should usually see some sort
   of error message. If you just get a return code, check the Majordomo
   README for further explanation on sendmail return codes. If you get
   "Unknown mailer error XX" where XX is less than 255, look for the
   error in /usr/include/errno.h . Otherwise, see the README.
   
   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.5 - 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:
   
   majordomo: |"/path/to/majordomo/wrapper majordomo"
   
  2.6 - 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.7 - 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.8 - 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 retrieved 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.9 - 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.10 - 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.
   
  2.11 - I get "sh: wrapper not available for sendmail programs"
  
   You're on a system which uses smrsh. (sendmail restricted shell). You
   have to configure smrsh to allow it to execute the wrapper. Normally
   this is done by creating a symlink in /var/adm/sm.bin (in some it's
   /etc/smrsh) to Majordomo's wrapper program.
   
  2.12 - I get "aliasing/forwarding loop broken"
  
   [ Reported by Wade Williams ]
   Some people have noted sendmail will generate a bounce message if you
   send to a list, but the list file is empty (there are no subscribers).
   Add a subscriber to the list and the error should go away.
   
   You will also get this error if the permissions on the list file for
   that list in the lists directory are too strict. If the list directory
   or list file is not readable by sendmail, you will also get the error
   "Cannot open /path/to/lists/listname: Permission denied". See Section
   2.1 above for the full discussion of how to correctly set permissions
   on directories and files within Majordomo.
     _________________________________________________________________
   
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. (This address is what gets copied into 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 in the bounce process.
   
   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
   most 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 bounce you 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.COM

   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.
   
  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/pw/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:
   
    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.
       
  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, which is just simply the
   name of the list. ("restrict-post = listname"). However, there is an
   issue to keep in mind. 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. (That means
   don't use something easy to guess like "-outgoing" or "-list"). Next,
   you need to make it such that people can't find out what your
   -outgoing alias is.
   
   You can use the "@filename" directive of resend. Put the all the
   normal command-line options of resend into a file readable only by the
   majordomo user/group. Then the alias for the list simply becomes
   ".../resend @/path/to/filename". 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. This doesn't prevent a user reading the local /etc/aliases
   file (if they can), however.
   
   Another approach is to simply disable EXPN or VRFY altogether. See the
   documentation for your mailer on how to do this. In sendmail this is
   done by adding "noexpn" to the "O PrivacyOptions=" line in your
   sendmail.cf (multiple options are separated with a comma). However
   this doesn't prevent a local user reading the aliases file. This isn't
   generally a problem if your mail server is restricted to staff only
   users.
   
   Unfortunately, Sendmail 8.x will log your -outgoing alias in the
   "Received:" lines. To prevent 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-seekrit,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 comma). Otherwise sendmail
   will set the envelope address of outgoing mail to contain your secret
   outgoing alias. Again if you're using the @filename directive, the
   entire command line is simply put into the specified file (starting
   with "-h foo.org ...".
   
   Here's another creative idea from matt@primefactor.com (Matt Perry):
   
   I've had a report that this no longer works with sendmail 8.9.1, but
   that it does work with 8.9.3.
   
   Sendmail allows you to rewrite incoming and outgoing addresses. The
   one that handles incoming is virtualusertable.text. For a list called
   test with the test-outgoing alias, I put the following into my
   virtualusertable.text file and remade the db with the appropriate
   command:
   
test-outgoing@mydomain.com      error:nouser User unknown

   Sendmail can still get to the alias and expand it into the list of
   recipients. However, any mail that appears at port 25 marked for
   test-outgoing@mydomain.com will bounce back with "User unknown".
   
   Finally it should be noted that it is impossible with any of these
   methods above to prevent people from forging mail as someone who is
   subscribed to the list, and sending to the list that way. Of course a
   spammer can also subscribe to the list legitimately and then send
   spam. The restrict_post option blocks the vast majority of problems,
   however.
   
  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:
    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.
       This is also a "backup password" in case the .config file gets
       corrupted.
    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".
   
   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? How do I approve messages?
  
   First, you need to tell Majordomo that the list is moderated. In the
   configuration file for the list, you set "moderate = 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, automates
   this for you. Whenever you get a message which needs approval, from
   your mail reader pipe the message through "approve". The password for
   each list needs to be put in your .majordomo file. Read the "approve"
   script for more information.
   
   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.). Don't forget to
   edit out the headers which were added by the bounce process.
   
   For example:
   
To: your-list@example.com
Subject: doesn't matter

Approved: your-approval-password
Received: by some.site.org....
Received: by another.site.org....
From: joe@another.com (Joe User)
Subject: this list is great!
To: your-list@example.com

Hey, this list is great, and the moderator sure is sexy!

Joe

   It's also possible, if your mailer allows it, to approve a message
   another way by just inserting an Approved: header in the original body
   and passing the original message on without adding your own header.
   This is in a sense "forging" mail, so many mailers either won't allow
   it or will insert some sort of authentication warning. This form is
   used most often by moderators when they send mail to the list and
   don't want to go and approve their own message again. Here's an
   example:
To: your-list@example.com
Approved: your-approval-password
Subject: Thanks!

I like this list too, but sorry, I'm married!  :-)

-- your moderator

   Note that this requires a mail-user-agent (MUA) that allows one to add
   headers to a message. If your MUA doesn't let you do this, you'll need
   to use the first method.
   
   Note that in either case the "Approved:" line will be stripped out by
   Majordomo before it gets sent to the list, so the list members won't
   see your list password.
   
  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)]
     * Create aliases for the mailing list and the digest. See section
       2.2 of the README for an example.
     * create an alias for the majordom(o) user, so that his cron
       generated mail comes to me, rather than just piling up in
       /usr/local/mail/majordom.
     * create the list's and the digest's files, (widget, widget-digest,
       widget.config, widget-digest.config, etc.). Edit the
       widget-digest.config file and make sure all the digest options are
       set to your tastes.
     * create the digest directory and archive directory. See FAQ section
       2 on how to set permissions on all majordomo files and
       directories. You must have archives if you have digests so the
       digester can make the digest. You can purge the archive after the
       digest is generated.
     * Add yourself to both the mailing list and its digest so you can
       monitor what happens...at least for a while (not a bad idea to
       create a dummy user, and subscribe him to both the mailing list
       and its digest. This preserves a record of messages for debugging.
       Don't forget to remove this account and unsubscribe it after
       debugging.)
     * Optionally you may use cron to send a mkdigest to push out a
       digest at set intervals regardless of the number of queued
       messages. See the question Why aren't my digests going out?".
       
  3.12 - How do I setup virtual majordomo domains?
  
   [From Alan Millar, Anthony Baratta, 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.
   
   Create separate list directories for each virtual
   domain.http://www.sendmail.org/virtual-hosting.html
   first. See also the Sendmail FAQ there.
   
   Virtual domain stuff (in your virtusertable):
   
#Domain 1
majordomo@domain1.com          majordomo-1
majordomo-owner@domain1.com    user
ListOne@domain1.com            ListOne
ListOne-owner@domain1.com      user
owner-ListOne@domain1.com      user
ListOne-request@domain1.com    ListOne-request
@domain1.com                   user

#Domain 2
majordomo@domain2.com          majordomo-2
majordomo-owner@domain2.com    user
ListTwo@domain2.com            ListTwo
ListTwo-owner@domain2.com      user
owner-ListTwo@domain2.com      user
ListOne-request@domain2.com    ListTwo-request
@domain2.com                   user

   Don't forget to run 'makemap hash /etc/virtusertable <
   /etc/virtusertable'. Substitute "hash" for whatever database you wish
   to use (some vendor sendmail's don't support hash, but do support
   dbm).
   
   It's suggested to have separate alias files for each virtual domain.
   You can configure sendmail to have multiple alias files.
   
   Here's how the aliases will look:
#MajorDomo Aliases
## System Info
majordomo-1:  "|/usr/local/majordomo/wrapper majordomo -C /usr/local/majordomo/
majordomo-1.cf"
majordomo-2:  "|/usr/local/majordomo/wrapper majordomo -C /usr/local/majordomo/
majordomo-2.cf"

#Domain 1
ListOne:   "|/usr/local/majordomo/wrapper resend -l ListOne -C /usr/local/major
domo/majordomo-domain1.cf ListOne-OutGoing"
ListOne-OutGoing: :include:/usr/local/majordomo/lists-domain1/listone
ListOne-request: "|/usr/local/majordomo/wrapper majordomo -l ListOne -C /usr/lo
cal/majordomo/majordomo-domain1.cf"

#Domain 2
ListTwo:   "|/usr/local/majordomo/wrapper resend -l Listtwo -C /usr/local/major
domo/majordomo-domain2.cf ListTwo-OutGoing"
ListTwo-OutGoing: :include:/usr/local/majordomo/lists-domain1/listtwo
ListTwo-request: "|/usr/local/majordomo/wrapper majordomo -l ListTwo -C /usr/lo
cal/majordomo/majordomo-domain2.cf"

   You'll need to modify request-answer slightly if you want the virtual
   host to be used there in replies. Look for:
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 virtual
   aliases.
   
   Check out http://o2.towery.com/~ernestm/admin/majordomo/majorvirt.html
   also for good instructions on configuring virtual domains with
   Majordomo.
   
  3.13 - How can I stop people from using my mailing list to spam my
  subscribers?
  
   [From mcr@solidum.com (Michael Richardson) ]
   There are two approaches to solving spam. They are complementary.
   
   The most general solution is to make sure that your list host will not
   accept spam. See http://spam.abuse.net/ for extensive recipes on this.
   
   The majordomo specific way is to use the "restrict_post" mechanism to
   disallow posts from addresses that are not on the list. Please see
   section 3.6 for some of the pitfalls of using restrict_post. They all
   apply. My experience is that spammers have not yet learnt about the
   "-outgoing" alias, and the techniques in section 3.6 would apply when
   they do.
   
   The major objection to using restrict_post to deflect spam is that it
   may deflect posts from legitimate people -- people who've subscribed
   with one address but are posting from another address. It may also
   restrict cross-posts from other lists, or from people who read the
   list via news.
   
   The solution to the above objections is twofold:
    1. the moderator must forward legitimate posts. This can be a pain,
       but it does work.
    2. the restrict_post header can be extended.
       
   The typical way to do #2 is to set restrict_post to:
mylist:mylist-nomail

   Then, create a configuration file and password for "mylist-nomail",
   but DO NOT create any aliases. (If you use something like
   mj_build_aliases, then don't set the owner)
   
   The moderator, or subscribers may then subscribe themselves to this
   second list. Subscribers to the -nomail list will then be allowed to
   post to the first list, but won't receive duplicate copies of the
   first list.
     _________________________________________________________________
   
Section 4: Mailer and list administration problems

  4.1 - Address with blanks are being treated separately
  
   If a subscriber to the list is
   John Doe < jdoe@node.com>
   
   it gets treated these as the three addresses:
   John
   Doe
   < jdoe@node.com>
   
   [From Alan Millar]
   Majordomo does not treat these as three addresses. Apparently your
   mailer 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 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.
   
  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 often than US addresses) that
   we were always duplicating. Infinitely (until I killed the original
   submitter).
   
   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.
   [ 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 entries 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 towards 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 has met with varying success.
   Exim can also be used (see http://www.exim.org/). qmail has been used
   with majordomo, and performance with either Exim or qmail I'm told
   generally will well exceed that of sendmail. At least qmail also is
   written in a far more secure way than sendmail (some would say
   paranoid). See http://www.qmail.org. The qmail site includes at least
   one way to get majordomo to work with qmail. Note that it is possible
   to get majordomo working under qmail without using the 'wrapper',
   which is a nice idea. Some majordomo-under-qmail solutions just
   involve qmail's sendmail emulation feature. For more info, see the
   Using Majordomo with qmail FAQ, written by Russ Allbery.
   
   If you are using Exim instead of sendmail there are more things you
   can do. Instead of concealing the -outgoing addresses, it is possible
   to configure Exim so that those addresses are only usable by the local
   majordomo user. A description of how to do that can be found at
   http://www.netmaster.ca/exim/majordomo.html as well as other
   information about configuring majordomo with Exim.
   
   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):
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 list
   configuration file if you don't upgrade to 1.3 or higher.
   
   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
   advantage of TLB is its greater configuration flexibility, and also
   the fact that it's possible with TLB to eliminate the -outgoing
   address, making configuration easier and lists more secure.
   
   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.
   
    Majordomo command processing
    
   Most of the improvements in this 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 and higher.
   
  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.
   
   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:.
   
   See section Question 3.10 on how to approve messages to moderated
   lists.
   
   This is also explained in Doc/list-owner-info, which should be sent to
   all list owners and moderators.
   
  4.8 - I'm getting mail from majordomo with "BOUNCE:" what do I do? How do I
  stop this?
  
   Whenever majordomo encounters mail to the list which it sees a problem
   with, it forwards it to person at the approval address to deal with
   manually. There are lots of reasons Majordomo does this. Majordomo
   will tell you why in the Subject of the message. Here's a list of the
   most common bounce reasons:
   
   An "Admin request" bounce means that the list is configured to filter
   out what it thinks are "administrivia" messages, and it thought that
   message was one. These are messages such as "subscribe" or
   "unsubscribe" or "help", which get sent to the list instead of
   majordomo. Lists generally have this turned on by default. If you
   don't like it, set "administrivia=no" in the list config file. If that
   doesn't work, check your aliases to make sure the "-s" option to
   resend isn't being used on that list.
   
   An "Approval required" bounce means that the list is moderated, and
   the message needs to be approved. (see section 3.10 of this FAQ)
   
   A "Message too long" bounce means that the message was longer than the
   "maxlength" setting in the list config file.
   
   If you get any of these bounces messages and you think the mail is OK
   to send to the list, you'll need to approve it. See the file
   Doc/list-owner-info on the correct procedure(s) for approving mail
   with Majordomo. It's also covered in section 3.10 of this FAQ.
   
  4.9 - My list configuration doesn't seem to be working.
  
   If you changed your list configuration and the list doesn't seem to be
   behaving any differently, make sure that the list is being sent
   through "resend". See the installation documentation and section 3.1
   of this FAQ on how to set up the aliases for the list correctly to
   pipe mail through "resend".
   
   Other things to check would be that the arguments to "resend" are only
   "-h", and "-l" (and perhaps "-C" if you use virtual domains). resend
   used to be configured with other command line flags to do things such
   as have moderated lists. However these flags override any config file
   settings, so remove them if they are present. All configuration should
   be done now through the config file.
   
  4.10 - How do I set it up so that the originator of a message doesn't get a
  copy of his/her own message back?
  
   You can't. Sorry. The "metoo" setting in sendmail has no effect after
   a message is piped through an external program. Unless you're willing
   to give up piping messages through "resend", there's no way to stop
   this.
   
  4.11 - With Smail or Exim, users subscribing to a list sometimes get mail
  sent before they subscribed
  
   [from Lazlo Nibble and Philip Hazel]
   This is due to the way Smail and Exim deliver mail. With sendmail, it
   expands its delivery list when the mail first arrives. If the list
   gets changed, the message will still get delivered to the original
   recipient list, since the original list is never referred to again. As
   sendmail delivers mail, it removes addresses from its expanded list as
   they get delivered.
   
   However Smail and Exim don't expand the list when the message is first
   queued. Instead as they go through the queue of pending messages to
   deliver, and maintain state on what addresses they have successfully
   delivered mail to and compare that with the current list contents. As
   long as the message is queued waiting for one or more addresses in the
   list, it will get sent to any new recipients whenever the queue gets
   processed next. This is rather unexpected for those used to sendmail's
   behavior.
   
   The advantage of smail and exim's approach is that if an address in
   your list is unreachable (or has a bad .forward file), you can change
   the list contents (or the .forward file) and the message will be
   delivered to the new address when the queue next gets processed. It
   won't deliver to the old, bad address.
   
   There really isn't an easy solution to this, but it's really not a
   serious problem.
   
  4.12 - Majordomo doesn't seem to work with sendmail 8.9
  
   The new security features of sendmail don't allow :include:
   directories to be group writable. Unfortunately, by default these
   directories are group writable with Majordomo. If you have this
   problem you will see errors from sendmail like "Cannot open
   /path/name: Group writable directory" and "aliasing/forwarding loop
   broken".
   
   One solution is to add:
   
O DontBlameSendmail=groupwritabledirpathsafe

   in your sendmail.cf and restart sendmail.
   
   The other method (and generally the recommended one) is to remove the
   group-write bit on the lists directory and any list files. Make sure
   also any parent directories to not have the group or other write bit
   set. If Majordomo is working correctly having group write permission
   is not necessary. However, some people find it convenient to have
   group-write access so users can be put in the majordomo group and not
   need root access all the time to work on majordomo.
   
  4.13 - I can't get Majordomo to work with RedHat Linux
  
   If you are trying to use the Majordomo RPM, it is broken. The
   majordomo.cf which comes with the RPM has the line
$whereami = `hostname`;

   This is broken for two reasons. First, the hostname may not
   necessarily be a fully-qualified domain name, and thus this won't
   generate a valid Internet email address. Secondly, using `hostname`
   generates a linefeed character at the end, which totally screws things
   up, and you end up getting blank lines in headers (and you'll start to
   see headers appear in the body of the message).
   
   The solution is to edit the line and put in your correct host name or
   mail domain.
   
   A bug report has been filed with RedHat.
   
   RedHat 5.2 also ships with an interim (buggy) release of Perl, which
   does not work with Majordomo. (you will get "Unknown mailer error 9"
   errors). Download and install the updated Perl RPM from
   ftp://updates.redhat.com/.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
barr@visi-dot-com.invalid (David Barr)





Last Update March 27 2014 @ 02:11 PM