In general, messages should be sent in the body of the message, not in the subject. But this customized listserver handles both ways.
To create a new list, send the name of your new list to email@example.com. Make sure it has a different name than your userid.
For the purposes of this manual, suppose you gave your list the wonderfully inventive name your-list.
To subscribe, send the message
to firstname.lastname@example.org or to email@example.com. All further references to firstname.lastname@example.org can be replaced by email@example.com if you wish.
To unsubscribe, send the message
Messages sent to firstname.lastname@example.org will be posted to the entire list. Of course, we can also arrange for your-list@your-domain to work as well.
approve pswd subscribe your-list email@example.com
This will subscribe yourself to the list or anyone else you wished. Pswd is your password. Try this out since we haven't yet subscribed you to your own list.
approve pswd unsubscribe your-list firstname.lastname@example.org
This unsubscribes the person whose e-mail address is given.
To create digests, ask us to activate the digest feature for your list.
How do I control how often they are created?
You could use cron to create periodic digest with a command like the following:
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.
This would mean that you would be changing the text:
maxlength = 40000
in the list configuration for the digest. (Send
config your-list pswd
to majordomo to get the configuration which you can edit and send back. This is the same procedure as mentioned in 3.2.5.)
You can combine the two methods, for example to send out at least one digest per day but more if that one would be over a certain size.
Send to majordomo:
newinfo your-list-name pswd Blah, blah, blah.
This will add a welcome to the message everyone sees when they subscribe. It will also be used if a customer requests info on a list. Note the blank line between welcome and Blah, blah, blah. Also note that you can not include any other commands with this command. Of course, the info message can be many lines.
passwd your-list-name old-password new-password
Will change your master password from the old-password to the new-password.
approve pswd who your-list-name
Posting a message with the following text at the beginning will work.
Approved: passwd From: email@example.com (The UFO Project) To: firstname.lastname@example.org Subject: UFO Oracle - Project Bluebook Message begins here. (Note the blank space -- the first blank line in the message.)
Send the command config your-list-name pswd to get a copy of your self-documenting configuration file.
You will find the area that contains the reply-to field.
Update this field and then send the command newconfigyour-list-name pswd followed by your new configuration file.
Even with this quite simple interface, people will still screw up. We have modified this listserver so that it can handle SUBSCRIBE your-list-name E-MAIL ADDRESS as well and it can accept commands in either the subject area or body of the message. We wouldn't recommend telling subscribers about these extra features, but they reduce the amount of screwups you have to deal with.
If you are unhappy with this standard format in any way or would like the listserver's input or output features modified in any way, let us know.
Sending the command HELP to email@example.com will get you a general help file. You can also type man majordomo at the shell prompt to get very detailed information about this listserver.
This page maintained by ADMCITY
Version: $Id: majordomo-faq.html,v 1.40 1995/02/11 20:09:22 barr Exp barr $ Archive-Name: mail/list-admin/majordomo-faq Posting-Frequency: monthly Table of Contents: 1. What is Majordomo and how can I get it? + What is Majordomo? + Where do I get it? + How do I install it? + How do I upgrade from an earlier release? + Where do I report bugs or get help with Majordomo? + Which is better, Majordomo or LISTSERV? 2. Problems setting up Majordomo + What are the proper permissions and ownership of all Majordomo files and directories? + I get "Unknown mailer error" when majordomo runs + I get "Permission denied at ..." when majordomo runs + I get "shlock: open(">/some/path/...") when majordomo runs + A file is visible via index, but can't 'get' it + Majordomo seems to be taking many minutes to process commands + I get an error "insecure usage" from the wrapper + I get "majordomo: No such file or directory" from the wrapper + I get an error "Can't locate majordomo.pl" + I told my majordomo.cf where to archive the list, why isn't it working? + I'm accumulating lots of files called /tmp/resend.*.in and .out, + A list is visible via lists, but can't subscribe or 'get' files + I get "Out of Memory" when upgrading to 1.93 + I get lots of warnings and errors when trying to compile 1.93's wrapper 3. Setting up mailing lists and aliases + How do I direct bounces to the right address? + Semi-automated handling of bounced mail + What's this Owner-List and List-Owner stuff? Why both? + How should I configure resend for Reply-To headers? + How can I hide lists so they can't be viewed by 'lists'? + How can I restrict a list such that only subscribers can send mail to the list? + Can I have the list owner or approval person be changeable without intervention from the Majordomo owner? + What about all of these passwords starting in version 1.90? + How do I tell majordomo to handle "get"-ing of binary files? + How do I set up a moderated list? + How do I set up a digested version of a list? 4. Miscellaneous mailer and other problems + Address with blanks are being treated separately + Why aren't my digests going out? + Why do I get duplicate mail sent to the list? This FAQ is Copyright 1994 by David Barr and The Pennsylvania State University. This document may be reproduced, so long as it is kept in its entirety and in its original format. Credits: 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 firstname.lastname@example.org (Fen Labalme) for getting an HTML version started. You can get this FAQ by sending an e-mail message to email@example.com with "get file majordomo-faq" in the _body_ of the message. You can get an HTML version on the World Wide Web at http://www.math.psu.edu/barr/majordomo-faq.html. If you have any questions or submissions regarding this FAQ, send them to firstname.lastname@example.org (David Barr). _________________________________________________________________ Section 1: What is Majordomo and how can I get it? WHAT IS MAJORDOMO? Majordomo is a program which automates the management of Internet mailing lists. Commands are sent to Majordomo via electronic mail to handle all aspects of list maintainance. Once a list is set up, virtually all operations can be performed remotely, requiring no intervention upon the postmaster of the list site. _ majordomo - n: a person who speaks, makes arrangements, or takes charge for another. From latin "major domus" - "master of the house". _ Majordomo is written in Perl (at least 4.035, preferably 4.036). It is also known to work under Perl 5, if you edit majordomo and resend and look for instances of the "@" character inside text strings "@" Change the "@" to "\@". This only happened with recent versions of Perl 5. The same fix is also required if you want to run Majordomo under OSF/1 on the DEC AXP systems with Perl 4 or 5. [from Jim Reisert] Majordomo controls a list of addresses for some mail transport system (like sendmail or smail) to handle. Majordomo itself performs no mail delivery (though it has scripts to format and archive messages). Here's a short list of some of the features of Majordomo. * supports various types of lists, including moderated ones. * List options can be set easily through a configuration file, editable remotely. * Supports archival and remote retrieval of messages. * Supports digests. * Written in Perl, - easily customizable and expandable. * Modular in design. * Includes support for FTPMAIL. WHERE DO I GET IT? Via anonymous FTP at: ftp://ftp.greatcircle.com/pub/majordomo/ If you don't have Perl, you can get it from: ftp://prep.ai.mit.edu/pub/gnu/perl-4.036.tar.gz The FTPMAIL package can be found in ftp://src.doc.ic.ac.uk/packages/ftpmail or any comp.sources.misc archive (volume 37). HOW DO I INSTALL IT? Majordomo comes with a rather extensive README. Read this file completely. This FAQ is meant to be a supplement to Majordomo's documentation, not a replacement for it. If you have any questions that this FAQ doesn't cover, chances are that it is covered in the README or other documentation in the Majordomo distribution. HOW DO I UPGRADE FROM AN EARLIER RELEASE? Be sure to browse the "Changes" and "Changelog" files to get an idea what has changed. There currently is no canned set of instructions for upgrading from an earlier release. The most straightforward method is to simply install the current release in a different directory, (with the same list/archive/digest directories) and change the mail aliases for each list to use the new Majordomo scripts as soon as you feel comfortable with the new setup. WHERE DO I REPORT BUGS OR GET HELP WITH MAJORDOMO? If you need help, there is a mailing list email@example.com, which is frequented by lots of users of Majordomo. Please don't send questions to me. Report bugs to firstname.lastname@example.org. 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, etc) and version you are using, especially if you can't get Majordomo to work at all. But first, you must have thoroughly read the documentation to Majordomo and this FAQ. WHICH IS BETTER, MAJORDOMO OR LISTSERV? For a good comparison of various mailing list managers (MLM's) there's a good review by Norm Aleks. Send mail to "email@example.com" with the body "get file mlm-software-faq" in the _body_ of the message. This eventually will probably become its own FAQ. Contact firstname.lastname@example.org (Norm Aleks) for more information. Section 2: Problems setting up Majordomo WHAT ARE THE PROPER PERMISSIONS AND OWNERSHIP OF ALL MAJORDOMO FILES AND DIRECTORIES? 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. That's due to improve in future releases. Majordomo works by using a small C "wrapper" which works by allowing Majordomo 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) Because Majordomo does not run with any "special" priviliges, 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 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. If things don't work right, then try POSIX. If you are on a non-POSIX system, the wrapper must be both suid _and_ sgid (mode 6755) to whatever you defined your majordomo user and group to be. It must not be setuid root! _OR_ On a POSIX system the wrapper must be setuid root, and double-check that W_UID and W_GID are the uid and gid of the majordomo user and group. Don't set W_UID to be 0! Then compile the wrapper and install it. Do not install the wrapper on an NFS filesystem with the "nosuid" option set. This will prevent the wrapper from working. Majordomo files All files that majordomo creates will be mode 660, user "majordomo", group "majordomo" if it is running correctly. 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. (the 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 crititcal, but the must all be readable to the majordomo user/group. All Majordomo programs (majordomo, resend, etc.) must have the execute bit set. Majordomo directories All directories under Majordomo's control ($homedir, $listdir, $digest_work_dir, $filedir, as defined in your majordomo.cf) must be mode 770 (or 775). 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 group-"majordom" writeable. I GET "UNKNOWN MAILER ERROR" WHEN MAJORDOMO RUNS 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 always see some sort of error message. For information purposes, here are the current return codes from the wrapper: * 1: Usage error * 2: Insecure usage (argument to wrapper can't contain a '/') * 3: malloc() failed (out of memory) * 4: set[ug]id() failed, compile with POSIX instead of BSD flags * 5: execve() failed * >5: return code from perl I GET "PERMISSION DENIED AT ..." WHEN MAJORDOMO RUNS I GET "SHLOCK: OPEN(">/SOME/PATH/..." WHEN MAJORDOMO RUNS A FILE IS VISIBLE VIA INDEX, BUT CAN'T 'GET' IT MAJORDOMO SEEMS TO BE TAKING MANY MINUTES TO PROCESS COMMANDS These are all symptoms of a permission or ownership problem. See the previous question. The directory specified of any "shlock" errors indicates a problem with that directory. A "get" problem means the ownership or permission of archive directory for that list is wrong. I GET AN ERROR "INSECURE USAGE" FROM THE WRAPPER The argument to ".../wrapper" should be simply "majordomo", not The full path to majordomo or resend. "wrapper" has where to look compiled in to it (the "W_BIN" setting in the Makefile) for security reasons, and will not let you specify another directory. Your alias should say: |"/path/to/majordomo/wrapper majordomo" I GET "MAJORDOMO: NO SUCH FILE OR DIRECTORY" FROM THE WRAPPER Make sure that the #! statement at the beginning of all the Majordomo Perl executables contain the correct path to the perl program. (the default is /usr/local/bin/perl) Make sure also that majordomo and all the related scripts are in the W_BIN directory as defined in the Makefile when you compiled the wrapper. I GET AN ERROR "CAN'T LOCATE MAJORDOMO.PL" [from Brent Chapman] Majordomo adds "$homedir" from the majordomo.cf file to the @INC array before it goes looking for "majordomo.pl". Since it's not finding it, I'd guess you have one of two problems: 1) $homedir is set improperly (or not set at all; there is no default) in your majordomo.cf file. 2) majordomo.pl is not in $homedir, or is not readable. [from John P. Rouillard] 3) Note that the new majordomo.cf file checks to see if the environment variable $HOME is set first, and uses that for $homedir. Since the wrapper always sets HOME to the correct directory, you get a nice default, unless you are running a previously built wrapper, in which case you may get the wrong directory. [from Andreas Fenner] 4) I had the same problem when I installed majordomo (1.62). My Problem was a missing ";" in the majordomo.cf file - just in the line before setting homedir .... My hint for you: Check your perl-files carefully. I 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/ for files that it should allow to be gotten using the get command. Majordomo comes with three different archive programs that run under wrapper, that do various types of archiving. Look in the contrib directory. I'M ACCUMULATING LOTS OF FILES CALLED /TMP/RESEND.*.IN AND .OUT WHAT ARE THESE AND HOW CAN I GET RID OF THEM? This is a known bug in Majordomo 1.92. There was a typo in resend on line 347. Change the double-quotes to angle-brackets. (just like the other calls to unlink()) A LIST IS VISIBLE VIA LISTS, BUT CAN'T SUBSCRIBE OR 'GET' FILES [From Brent Chapman] I'll bet your list name has capital letters in it... Majordomo smashes all list names to all-lower-case before attempting to use the list name as part of a filename. So, while it's OK to advertise (for instance) "Majordomo-Users" and have the headers say "Majordomo-Users", the files and archive directory all need to be "majordomo-users*". I GET "OUT OF MEMORY" WHEN UPGRADING TO 1.93 [summary of report from Matthew A. Braithwaite] There appears to be a bug in error reporting in Majordomo 1.93. Under certain circumstanses, if the directory containing your Log file is not writeable by majordomo then it will get caught in an infinite recursion, eventually allocating all the memory in the system. The fix is to make sure that the directory containing your Log file is user and group writeable, and user and group owned by your majordomo user and group. I GET LOTS OF WARNINGS AND ERRORS WHEN TRYING TO COMPILE 1.93'S WRAPPER You're probably trying to compile the wrapper using the default Makefile on a non-POSIX system (like SunOS 4.x). As it says in the Makefile, SunOS isn't POSIX -- you need to use the BSD rules. You may still get one warning when compiling with BSD under SunOS, just ignore it. _________________________________________________________________ Section 3: Setting up mailing lists and aliases HOW DO I DIRECT BOUNCES TO THE RIGHT ADDRESS? This was somewhat of a RTFM question. The answer is to use 'resend' to your advantage. The following is an example of a sendmail alias that I was using: sample: :include:/usr/local/mail/lists/sample Whereas this example (from the 'sample.aliases' file distributed with Majordomo) fixes the problem. sample: "|/usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Sample -f Owner-Sample -h GreatCircle.COM -s sample-outgoing" sample-outgoing: :include:/usr/local/mail/lists/sample owner-sample: joe See the 'resend.README' file for more info on resend's options. What this does is force outgoing mail to have the out-of-band envelope FROM be "Owner-Sample@GreatCircle.COM", and thus all bounces will be redirected to that address. (Users often see this mirrored in the message body as the "From " or "Return-Path:" header). 'resend' also inserts a "Sender:" line with the same address to help people identify where it came from, but that header is not used for the bounce address. If you are using sendmail v8.x, you don't have to use 'resend' to do the same thing. You simply have to define an alias like this: owner-sample: joe, Note the trailing comma is necessary to prevent sendmail from resolving the alias first before putting it in the header. Without the comma, it will put "joe" in the envelope from instead of "owner-sample". Either address will work, of course, but the generic address is preferred should the owner ever change. SEMI-AUTOMATED HANDLING OF BOUNCED MAIL [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 email@example.com" will mail the following message to Majordomo@This.COM: approve passwd1 unsubscribe this-list firstname.lastname@example.org approve passwd3 subscribe bounces email@example.com (930401 this-list) while a command of "bounce other-list firstname.lastname@example.org" will mail the following message to Majordomo@Other.COM: approve passwd2 unsubscribe other-list email@example.com approve passwd4 subscribe bounces firstname.lastname@example.org (930401 this-list) Note that the date and the list the user was bounced from are included as a comment in the address used for the "subscribe bounces" command. WHAT'S THIS OWNER-LIST AND LIST-OWNER STUFF? WHY BOTH? [From David Barr] The "standard" is spelled out in RFC 1211 - "Problems with the Maintenance of Large Mailing Lists". It's here where the "owner-listname" and "listname-request" concepts got their start. (well it was before this, but this is where it was first spelled out) Personally, I don't use "listname-owner" anywhere. You don't really have to put both, since the "owner" alias is usually only for bounces, which you add automatically anyway with resend's "-f" flag, or having Sendmail v8.x's "owner-listname" alias. (while I'm on the subject) The "-approval" is a Majordomo-ism, and is only necessary if you want bounces and approval notices to go to different mailboxes. (though you'll have to edit some code in majordomo and request-answer if you want to get rid of the -approval alias, since it's currently hardwired in) So, to answer your question, I'd say "no". You don't have to have both. You should just have "owner-list". HOW SHOULD I CONFIGURE RESEND FOR REPLY-TO HEADERS? Whether you should have a "Reply-To:" or not depends on the charter of your list and the nature of its users. If the list is a discussion list and you generally want replies to go back to the list, you can include one. Some people don't like being told what to do, and prefer to be able to choose whether to send a private reply or a reply to the list just by using the right function on their mail agent. Take note that if you do use a "Reply-To:", then some mail agents make it much harder for a person on the list to send a private reply. If you are using resend, use the '-r ' flag to set the Reply-To field to the list, or use the 'reply_to' config keyword for 1.9x or greater. HOW CAN I HIDE LISTS SO THEY CAN'T BE VIEWED BY 'LISTS'? That is what advertise and noadvertise are for. The two keywords take regular expressions that are matched against the from address of the sender. A list display follows the rules: 1. If the from address is on the list, it is shown. 2. If the from address matches a regexp in noadvertise (e.g. /.*/) the list is not shown. 3. If the advertise list is empty, the list is shown unless 2 applies. 4. If the advertise list is non-empty, the from address must match an address in advertise. Otherwise the list is not shown. Rule 2 applies, so you could allow all hosts in umb.edu except hosts in cs.umb.edu. HOW CAN I RESTRICT A LIST SUCH THAT ONLY SUBSCRIBERS CAN SEND MAIL TO THE LIST? For pre-1.9x versions of majordomo, see the -I option to resend. For 1.9x this is the restrict_post keyword in the config file. Just set it to the filename that holds the list of subscribers. Unfortunately this means you probably will need help from the Majordomo maintainer in setting it if you don't have access to the host machine. This is due to be improved in a future release of Majordomo. However, there is a problem with either of these methods. 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. Next, you need to make it such that people can't find out what your -outgoing alias is. You can use the "@filename" directive in resend to move the command-line options of resend into a file readable only by the majordomo user/group. 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, or even locally by looking at the aliases file or NIS map. Another more direct approach is to simply disable EXPN or VRFY altogether. See the documentation for your mailer on how to do this. Finally it should be noted that it is impossible with any method to prevent people from forging mail as someone on the list, and sending to the list that way. CAN I HAVE THE LIST OWNER OR APPROVAL PERSON BE CHANGEABLE WITHOUT INTERVENTION FROM THE MAJORDOMO OWNER? Sure! Just make owner-listname and/or listname-approval be another majordomo list. (probably hidden, for simplicity's sake) WHAT ABOUT ALL OF THESE PASSWORDS STARTING IN VERSION 1.90? Think of three separate passwords: 1. A master password that can be used by both resend and majordomo contained in [listname].passwd. To be used by the master list manager when using writeconfig commands etc. This allows someone who handles a number of mailing lists all using the same password. 2. A password for the manager of this one list. The admin_passwd can be used by subsidiary majordomo list maintainers. 3. A password for those concerned with the list content (approve_passwd) This way the administration and moderation functions can be split. The original reason for maintaining [listname].passwd was to allow a new config file to be put in if the config file was trashed and the admin_password was obliterated, and may still be useful to allow a single password to be used for admin functions by the majordomo admin or some other "superadmin". 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. 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). HOW DO I SET UP A MODERATED LIST? First, you need to tell Majordomo that the list is moderated. In the configuration file for the list, you set "moderated = yes". 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 does this for you. 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 re-mail the original message to the list, except by adding the line "Approved: _approval-password_" to the very first line of the body. HOW DO I SET UP A DIGESTED VERSION OF A LIST? [ Modified from explanation given by email@example.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 add a crontab for majrodom, to push out a digest at set intervals regardless of the number of queued messages. Of course you can do this from any account not just majordom, as long as the password is correct. See the question Why aren't my digests going out?". _________________________________________________________________ Section 4: Miscellaneous mailer problems ADDRESS WITH BLANKS ARE BEING TREATED SEPARATELY If a subscriber to the list is John Doe
it gets treated these as the three addresses: John Doe [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 comment at the end of each address it writes to the list file. You can also add the $listname.strip option so that none of the addresses are angle-bracketed. (the "strip" config option for 1.90) WHY AREN'T MY DIGESTS GOING OUT? >I'm not sure how to set up the digest feature of majordomo 1.92 >to send digests out. Currently, it is digesting incoming mail, >but that's all it's doing. [from John Rouillard] echo mkdigest [digest-name] [digest-password] | mail majordomo@... This will force a digest to be created. Or you can set the max size in the digest list config file down low, and force automatic generation. There are some patches for 1.92 that will allow other ways of specifying automatic digest sending. The patch is in the contrib directory. WHY DO I GET DUPLICATE MAIL SENT TO THE LIST? I've 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 ofen 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). [ Please let me know if you have any more information --ed ]
# The configuration file for a majordomo mailing list. # Comments start with the first # on a line, and continue to the end # of the line. There is no way to escape the # character. The file # uses either a key = value for simple (i.e. a single) values, or uses # a here document # key << END # value 1 # value 2 # [ more values 1 per line] # END # for installing multiple values in array types. Note that the here # document delimiter (END in the example above) must be the same at the end # of the list of entries as it is after the << characters. # Within a here document, the # sign is NOT a comment character. # A blank line is allowed only as the last line in the here document. # # The values can have multiple forms: # # absolute_dir -- A root anchored (i.e begins with a /) directory # absolute_file -- A root anchored (i.e begins with a /) file # bool -- choose from: yes, no, y, n # enum -- One of a list of possible values # integer -- an integer (string made up of the digits 0-9, # no decimal point) # float -- a floating point number with decimal point. # regexp -- A perl style regular expression with # leading and trailing /'s. # restrict_post -- a series of space or : separated file names in which # to look up the senders address # (restrict-post should go away to be replaced by an # array of files) # string -- any text up until a \n stripped of # leading and trailing whitespace # word -- any text with no embedded whitespace # # A blank value is also accepted, and will undefine the corresponding keyword. # The character Control-A may not be used in the file. # # A trailing _array on any of the above types means that that keyword # will allow more than one value. # # Within a here document for a string_array, the '-' sign takes on a special # significance. # # To embed a blank line in the here document, put a '-' as the first # and ONLY character on the line. # # To preserve whitespace at the beginning of a line, put a - on the # line before the whitespace to be preserved # # To put a literal '-' at the beginning of a line, double it. # # # The default if the keyword is not supplied is given in ()'s while the # type of value is given in , the subsystem the keyword is used in is # listed in <>'s. (undef) as default value means that the keyword is not # defined or used. # admin_passwd [word] (neo-talk.admin)
# (Default is specified in the file .passwd) The password # for handling administrative tasks on the list. admin_passwd = neo-talk.admin # administrivia [bool] (yes) # Look for administrative requests (e.g. subscribe/unsubscribe) and # forward them to the list maintainer instead of the list. administrivia = yes # advertise [regexp_array] (undef) # If the requestor email address matches one of these regexps, then # the list will be listed in the output of a lists command. Failure to # match any regexp excludes the list from the output. The regexps # under noadvertise overide these regexps. advertise << END END # approve_passwd [word] (neo-talk.pass) # Password to be used in the approved header to allow posting to # moderated list, or to bypass resend checks. approve_passwd = neo-talk.pass # archive_dir [absolute_dir] (undef) # The directory where the mailing list archive is kept. This item does # not currently work. Leave it blank. archive_dir = # comments [string_array] (undef) # Comment string that will be retained across config file rewrites. comments << END END # date_info [bool] (yes) # Put the last updated date for the info file at the top of the info # file rather than having it appended with an info command. This is # useful if the file is being looked at by some means other than # majordomo (e.g. finger). date_info = yes # debug [bool] (no) # Don't actually forward message, just go though the motions. debug = no # description [string] (undef) # Used as description for mailing list when replying to the lists # command. There is no quoting mechanism, and there is only room for # 50 or so characters. description = # digest_archive [absolute_dir] (undef) # The directory where the digest archive is kept. This item does not # currently work. Leave it blank. digest_archive = # digest_issue [integer] (1) # The issue number of the next issue digest_issue = 1 # digest_name [string] (neo-talk) # The subject line for the digest. This string has the volume and # issue appended to it. digest_name = neo-talk # digest_rm_footer [word] (undef) # The value is the name of the list that applies the header and # footers to the messages that are received by digest. This allows the # list supplied headers and footers to be stripped before the messages # are included in the digest. This keyword is currently non operative. digest_rm_footer = # digest_rm_fronter [word] (undef) # Works just like digest_rm_footer, except it removes the front # material. Just like digest_rm_footer, it is also non-operative. digest_rm_fronter = # digest_volume [integer] (1) # The current volume number digest_volume = 1 # digest_work_dir [absolute_dir] (undef) # The directory used as scratch space for digest. Don't change this # unless you know what you are doing digest_work_dir = # maxlength [integer] (40000) # The maximum size of an unapproved message in characters. When used # with digest, a new digest will be automatically generated if the # size of the digest exceeds this number of characters. maxlength = 40000 # message_footer [string_array] (undef) # Text to be appended at the end of all messages posted to the list. # The text is expanded before being used. The following expansion # tokens are defined: $LIST - the name of the current list, $SENDER - # the sender as taken from the from line, $VERSION, the version of # majordomo. If used in a digest, no expansion tokens are provided message_footer << END END # message_fronter [string_array] (undef) # Text to be prepended to the beginning of all messages posted to the # list. The text is expanded before being used. The following # expansion tokens are defined: $LIST - the name of the current list, # $SENDER - the sender as taken from the from line, $VERSION, the # version of majordomo. If used in a digest, only the expansion token # _SUBJECTS_ is available, and it expands to the list of message # subjects in the digest message_fronter << END END # message_headers [string_array] (undef) # These headers will be appended to the headers of the posted message. # The text is expanded before being used. The following expansion # tokens are defined: $LIST - the name of the current list, $SENDER - # the sender as taken from the from line, $VERSION, the version of # majordomo. message_headers << END END # moderate [bool] (no) # If yes, all postings to the list must be approved by the moderator. moderate = no # mungedomain [bool] (no) # If set to yes, a different method is used to determine a matching # address. When set to yes, addresses of the form firstname.lastname@example.org # are considered equivalent to addresses of the form email@example.com. # This allows a user to subscribe to a list using the domain address # rather than the address assigned to a particular machine in the # domain. This keyword affects the interpretation of addresses for # subscribe, unsubscribe, and all private options. mungedomain = no # noadvertise [regexp_array] (undef) # If the requestor name matches one of these regexps, then the list # will not be listed in the output of a lists command. Noadvertise # overrides advertise. noadvertise << END END # precedence [word] (bulk) # Put a precedence header with value into the outgoing # message. precedence = bulk # private_get [bool] (yes) # If set to yes, then the requestor must be on the mailing list in # order to get files. private_get = yes # private_index [bool] (no) # If set to yes, then the requestor must be on the mailing list in # order to get a file index. private_index = yes # private_info [bool] (no) # If set to yes, then the requestor must be on the mailing list to use # the info
command. private_info = no # private_which [bool] (no)
# If set to yes, then the requestor must be on the mailing list in # order to get which info from that list. private_which = yes # private_who [bool] (no) # If set to yes, then the requestor must be on mailing the list in # order to use the who command. private_who = yes # purge_received [bool] (no) # Remove all received lines before resending the message. purge_received = no # reply_to [word] () # Put a reply-to header with value into the outgoing message. # If the token $SENDER is used, then the address of the sender is used # as the value of the reply-to header. This is the value of the reply- # to header for digest lists. reply_to = # resend_host [word] (undef) # The host name that is appended to all address strings specified for # resend. resend_host = # restrict_post [restrict_post] (undef) # If defined only address listed in one of the files (colon or space # separated) can post to the mailing list. This is less useful than it # seems it should be since there is no way to create these files if # you do not have access to the machine running resend. This mechanism # will be replaced in a future version of majordomo/resend. restrict_post = # sender [word] (owner-neo-talk) # The envelope and sender address for the resent mail. This string has # "@" and the value of resend_host appended to it to make a complete # address. For majordomo, it provides the sender address for the # welcome mail message generated as part of the subscribe command. sender = owner-neo-talk # strip [bool] (yes) # When adding address to the list, strip off all comments etc, and put # just the raw address in the list file. In addition to the keyword, # if the file .strip exists, it is the same as specifying a # yes value. That yes value is overridden by the value of this # keyword. strip = yes # subject_prefix [word] (undef) # This word will be prefixed to the subject line, if it is not already # in the subject. The text is expanded before being used. The # following expansion tokens are defined: $LIST - the name of the # current list, $SENDER - the sender as taken from the from line, # $VERSION, the version of majordomo. subject_prefix = # subscribe_policy [enum] (open) /open;closed;auto/ # One of 3 possible values: open, closed, auto. Open allows people to # subscribe themselves to the list. Auto allows anybody to subscribe # anybody to the list without maintainer approval. The existence of # the file .auto is the same as specifying the value auto. # Closed requires maintainer approval for all subscribe requests to # the list. In addition to the keyword, if the file .closed # exists, it is the same as specifying the value closed. The value of # this keyword overrides the value supplied by any existent files. subscribe_policy = auto
Return To Menu