Version: $Id: majordomo-faq.html,v 1.244 2001/10/20 02:25:38 barr Exp barr $ URL: http://www.visi.com/~barr/majordomo-faq.html Archive-Name: mail/majordomo-faq Posting-Frequency: monthlyNote: 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:
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_QuestionsIf you have any questions or submissions regarding this FAQ, send them to barr@nospam.visi.com (David Barr).
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.
See other references throughout this FAQ for some further notes on using these packages.
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:
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 "beta" 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/
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:
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.
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/. Unfortunately they seem to have stopped archiving around Nov 1998
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.
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.
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.
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.
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).
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.
See Section 2.1 and especially the paragraph on wrapper security for the correct permissions on all majordomo directories and programs.
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.
Your alias should say for example:
majordomo: |"/path/to/majordomo/wrapper majordomo"
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.
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.
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.
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.
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.COMA 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.
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".
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.
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 unknownSendmail 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.
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.
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.
Create separate list directories for each virtual domain.
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 userDon'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/majordomo/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/local/majordomo/majordomo-domain1.cf" #Domain 2 ListTwo: "|/usr/local/majordomo/wrapper resend -l Listtwo -C /usr/local/majordomo/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/local/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-requestin the source and change it to:
From: $list-request\@$whereamiDon'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.
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:
mylist:mylist-nomailThen, 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.
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.
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.
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 ]
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.
if (!$main'no_x400at) { if (!$main'no_true_x400) {
This is fixed in Majordomo 1.94.1 and higher.
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.
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.
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.
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.
One solution is to add:
O DontBlameSendmail=groupwritabledirpathsafein 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.
$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/.