Оцените этот текст:




В redhat 5.2 сменилась версия перла, и масса ошибок в регулярных выражениях,
которыми набит majordom, полезли наружу.

Основное, что там надо править - применения ключа "g" - global - на $ или ^.
например s/\n$//g;

Все подобные дырки надо вычистить во всех перловых файлах majordomo




subscribe_policy    = auto+confirm
unsubscribe_policy  = auto
strip               = yes
reply_to            = $SENDER
sender              = null
index_access        = closed
get_access          = list
info_access         = open
maxlength           = 400000
moderate            = yes



subscribe_policy    = auto+confirm
unsubscribe_policy  = auto
strip               = yes
reply_to            = $SENDER
index_access        = closed
get_access          = list
info_access         = open
maxlength           = 400000
moderate            = no





Subject: Majordomo Frequently Asked Questions
Date: 5 Nov 1997 10:03:03 -0500
Expires: 9 Dec 1997 15:03:01 GMT

Version: $Id: majordomo-faq.html,v 1.145 1997/10/24 14:09:28 barr Exp barr $
Archive-Name: mail/list-admin/majordomo-faq
Posting-Frequency: monthly

Note: This FAQ has been recently updated to be exclusively for
Majordomo 1.94 and up.

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.6 - How can I access Majordomo via the Web?
 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"
       + 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
 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?
       + 3.11 - How do I set up a digested version of a list?
       + 3.12 - How do I setup virtual majordomo domains?
 4. Miscellaneous mailer and other 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?

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.cis.ohio-state.edu/~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@cis.ohio-state.edu (David Barr).
  _________________________________________________________________





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.

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,
which can be found 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. While Majordomo is still compatible with Perl
4.036, future versions will likely be Perl 5 only.

Many people have been having problems with DEC OSF/1 AXP systems with
Majordomo. 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 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 will probably
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.

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



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.4. It includes a security fix found in
1.94.3 and prior.

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 comes with a rather extensive INSTALL file. Read this file
completely. There's also a README file which also 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.

If you have permission problems unpacking the distribution, try using
the 'o' flag to tar to ignore user/group information.



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 in upgrading to 1.94 that you update your $mailer and
$bounce_mailer variables in your majordomo.cf! There are also 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.



Please DO NOT ask the FAQ maintainer for help on Majordomo. I will
probably accidently delete your message. Let me say that about 90% of
the answers I give are from the documentation or this FAQ. Most of the
rest are answered by reading the source. It's really not that hard to
figure out.

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 an browse the list archives below for the
last couple months since many of the same questions are asked (and
answered) over and over again. 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 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 don't expect it to be up-to-date. It's
probably not.

There is an FTP site for unofficial patches. See
ftp://sol.ccsf.cc.ca.us/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 judgement before (and after) you
apply them.

Nick Perry also has various patches for 1.94.3 at
ftp://ftp.amulation.com/pub/majordomo_patches/. They are patches which
add various functions to majordomo.

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/g_maj-adm.html.



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. ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq
You can also request a copy via email, by sending the text "get
mlm-software faq" in the body of a mail message to
LISTSERV@listserv.net. Contact naleks@library.ummed.edu (Norm Aleks)
for more information.



There are various Web interfaces to Majordomo available.
  * LWGate - http://www.netspace.org/users/dwb/lwgate.html
  * Regan's - http://www.peak.org/peak_info/mlists/Majordomo.html
  * MajorCool - http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/
  * MailServ - http://iquest.com/~fitz/www/mailserv/
  * Pandora - http://www.ed.umuc.edu/products/pandora.html
  * Maitre-d - http://www.outer.net/wps/content2.htm#ch12
  * Gutierrez' - http://gaia.gutierrez.com/majordomo/
  * Marcos' - http://www.inf.utfsm.cl/~marcos/majordomo/www.html

Section 2: Problems setting up Majordomo



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

 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). 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" writeable
(770 or 775). 2.2 - I get a MAJORDOMO ABORT with "chown(...): Not
owner" 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. You should have seen an error if you ran
"./wrapper config-test". If not, it's a bug in config-test and should
be fixed.



This is a bug in the 1.94 Makefile. You'll see this in new installs of
Majordomo, if you don't use a majordomo group of 'daemon'. The
majordomo $homedir needs to have permission of at least 751 (or 755),
not 750. Otherwise, sendmail won't have permission to execute the
wrapper. You'll need to do a 'chmod 755 $homedir' after you install
majordomo. Make sure 'wrapper' also has world execute permission. Some
people also have put the user 'daemon' in the 'majordom' group. This
works too.



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



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:

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



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.



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



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



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)



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





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

However if you choose not to use 'resend', you will have to do without
much of majordomo's other features like moderating, administrivia
checks, and others.



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



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



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/FAQ/reply-to-harmful.html

If you are using resend, use the 'reply_to' configuration variable in
the list .config file.



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.


  the list?

See the restrict_post variable 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. The "@filename" directive seems to have fallen into
undocumentation for some reason. This should be fixed in future
releases.

Another more direct approach is to simply disable EXPN or VRFY
altogether. See the documentation for your mailer on how to do this.
However this doesn't prevent local reading if the aliases file.

Sendmail 8.x will unfortunately log your -outgoing alias in the
"Received:" lines. To get around 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,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 commma). Otherwise sendmail
will set the envelope address of outgoing mail to contain your secret
outgoing alias.

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.


  intervention from the Majordomo owner?

Sure! Just make owner-listname and/or listname-approval be another
majordomo list. (probably hidden, for simplicity's sake)



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.



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.



First, you need to tell Majordomo that the list is moderated. In the
configuration file for the list, you set "moderated = 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 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 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.)



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



[From Alan Millar, 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.

Alias entry:

  majordomo-domain2: |/your/wrapper majordomo -C /your/domain2.cf

Virtual domain stuff:

  majordomo@domain2 = majordomo-domain2
  majordomo-owner@domain2 = whoever

I use the sendmail virtual domain examples right off the Sendmail FAQ.
Works for me.

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 virutal
aliases.
  _________________________________________________________________





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.



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



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

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 ]



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 entires for your newsfeeds/sys
file and aliases entries. The newsgate package includes news2mail and
mail2news.



 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 to 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 like ZMailer has met with varying success. qmail has been
used with majordomo, and performance there I'm told generally far
exceeds that of sendmail. qmail also is written in a far more secure
way than sendmail. See http://www.qmail.org.

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
configuration file if you don't upgrade to 1.3.

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



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.



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

Last-modified: Wed, 31 Mar 1999 18:18:29 GMT

Оцените этот текст: