a
This commit is contained in:
1350
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/FAQ
vendored
Normal file
1350
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/FAQ
vendored
Normal file
File diff suppressed because it is too large
Load Diff
40
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/README
vendored
Normal file
40
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/README
vendored
Normal file
@@ -0,0 +1,40 @@
|
||||
FAQ
|
||||
The Majordomo FAQ, originally written by Vincent
|
||||
D. Skahan, now maintained by barr@math.psu.edu (David Barr).
|
||||
|
||||
majordomo-faq.html
|
||||
An html version of the FAQ.
|
||||
|
||||
majordomo.lisa6.ps
|
||||
The original Majordomo paper from the USENIX LISA VI conference
|
||||
in October, 1992. While this paper is somewhat out of date
|
||||
(some of the details about how Majordomo works have changed,
|
||||
and many of the items mentioned as "to be implemented later"
|
||||
have since been implemented), it remains a valuable
|
||||
introduction to Majordomo's basic form and structure.
|
||||
|
||||
list-owner-info
|
||||
has information for list owner to get them started using
|
||||
majordomo and the config files.
|
||||
|
||||
|
||||
majordomo.ora
|
||||
This file is the chapter about Majordomo from the Nutshell Handbook
|
||||
"Managing Internet Information Services," written by Jerry Peek.
|
||||
The chapter is (c) Copyright 1994 by O'Reilly & Associates, Inc.,
|
||||
and was included in the Majordomo distribution by permission of the
|
||||
publisher.
|
||||
|
||||
This chapter is a good introduction to setting up the
|
||||
majordomo software, be warned that it does not cover much of
|
||||
the list operation details under 1.90 that deal with config
|
||||
files. Then again the config files are supposed to be self
|
||||
documenting. A newer version of this chapter that has been
|
||||
updated for 1.90 is in the works, and should make it into the
|
||||
"Managing Internet Information Services" book. This newer
|
||||
chapter should be available via ftp in due time. Stay tuned to
|
||||
the majordomo-announce or majordomo-users mailing list for
|
||||
details.
|
||||
|
||||
man
|
||||
Some man pages for majordomo and approve.
|
||||
110
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/README.digest
vendored
Normal file
110
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/README.digest
vendored
Normal file
@@ -0,0 +1,110 @@
|
||||
This digestifier follows RFC 934, so it should be compatible with
|
||||
almost any digest-digester that comes along.
|
||||
|
||||
This creates a properly formatted digest and mails it. It automatically
|
||||
increments the issue number, but not the volume number.
|
||||
|
||||
The digest script has two modes: receiving messages and creating a
|
||||
digest. It receives email messages via stdin and places them in
|
||||
a work directory. In digest-creation mode, it takes those messages
|
||||
from the work directory, assembles them into a digest in an archive
|
||||
directory, and mails the digest.
|
||||
|
||||
If there are no messages in the work directory, it exits saying,
|
||||
"No messages to process."
|
||||
|
||||
One of the digest's required configuration values is the size limit
|
||||
in characters. If you use digest's -r option to receive digests, a
|
||||
digest will automatically be sent whenever this limit is passed.
|
||||
|
||||
There are also two optional parameters that can cause digests to
|
||||
be created and sent: the digest length limit in lines, and the
|
||||
age in days of the oldest undigested message.
|
||||
|
||||
These values are checked every time a message is received (if
|
||||
you are using the -r option).
|
||||
|
||||
|
||||
There are two ways of setting up a digest: as a majordomo list,
|
||||
or as a standalone. All of the files in this directory (excepting
|
||||
the digest script) are for the standalone configuration. They are
|
||||
IGNORED by majordomo.
|
||||
|
||||
If you are setting up a majordomo digest list, ALL your configuration
|
||||
values come from majordomo.cf and the digest list's config file
|
||||
(whatever-digest.config), NOT from the files in this directory.
|
||||
|
||||
To set up a majordomo digest list, you need
|
||||
|
||||
- digest work directory for incoming messages.
|
||||
This must be under the root $digest_work_dir from majordomo.cf
|
||||
- digest archive directory for completed digests.
|
||||
This must be under the root $filedir from majordomo.cf,
|
||||
and the directory name must end in $filedir_suffix.
|
||||
- the majordomo digest list. This is just like an ordinary
|
||||
majordomo list, except that you need to set the various
|
||||
digest parameters in the list's configuration file
|
||||
($listdir/whatever-digest.config). They are well commented.
|
||||
Make sure that in the message_footer and message_fronter
|
||||
that you begin all lines that need to be blank with a '-',
|
||||
and if you want the line to begin with whitespace, precede
|
||||
the whitespace with a '-'.
|
||||
- aliases for the digest. There are examples in aliases.slice.
|
||||
|
||||
You can set up a cron job to make the digests go at regular intervals.
|
||||
If you take incoming messages with the -r option, digests will also
|
||||
be created whenever there are long enough messages, or whenever the first
|
||||
message is old enough. The -R option will prevent this from happening;
|
||||
it just accepts messages, so digests can be mailed whenever you or your
|
||||
cron job say. The -m option (which is used by majordomo's mkdigest
|
||||
command) will make a digest if there are ANY messages. The -p option
|
||||
will only make a digest if there are enough messages, or if the
|
||||
first message is old enough. Both the -m and -p options could cause
|
||||
more than one digest to be created and sent.
|
||||
|
||||
|
||||
If you only want to set up a majordomo digest, stop reading now,
|
||||
because the rest of this file is about the standalone configuration.
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
If you are setting up a standalone digest, ALL of your configuration
|
||||
values come from the digest configuration file. There is a sample
|
||||
config file in this directory (firewalls-digest.cf). The default
|
||||
name for the configuration file is ~/.digestrc, which could make
|
||||
it easy to pipe mail from your mail reader into the digest, if
|
||||
that's how you want to feed it.
|
||||
|
||||
To make a standalone digest, you need these things:
|
||||
|
||||
- digest work directory for incoming messages
|
||||
- digest archive directory for completed digests
|
||||
- a digest config file, ~/.digestrc by default (sample in
|
||||
firewalls-digest.cf)
|
||||
- a digest header file (sample is firewalls-digest.header)
|
||||
- a digest trailer file (sample is firewalls-digest.trailer)
|
||||
- a digest volume-number file (sample is firewalls-digest.vol)
|
||||
- a digest issue-number file (sample is firewalls-digest.num)
|
||||
- RFC-822 messages, stored one per file
|
||||
|
||||
The config file is commented, and the format should be obvious. The
|
||||
only two things to watch for in the header and trailer files are:
|
||||
|
||||
- a line containing _SUBJECTS_ in the header file will be
|
||||
replaced by lines consisting of all of the subjects in the
|
||||
included messages, in order, indented as far as _SUBJECTS_ is.
|
||||
|
||||
- lines beginning with "-" in these files will not be
|
||||
properly encapsulated, and will be interpreted by
|
||||
undigesting software as message breaks.
|
||||
|
||||
You need to pipe the incoming messages to "digest [-c config_file]"
|
||||
for example:
|
||||
|
||||
cat email_message | digest -c /usr/local/digest/banjo.cf
|
||||
|
||||
And you can use either the -m or -p option to build a digest:
|
||||
|
||||
digest -m -c /usr/local/digest/banjo.cf
|
||||
|
||||
for example.
|
||||
69
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/README.sequencer
vendored
Normal file
69
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/README.sequencer
vendored
Normal file
@@ -0,0 +1,69 @@
|
||||
sequencer - a majordomo module
|
||||
|
||||
Shane P. McCarron
|
||||
MACS, Inc.
|
||||
|
||||
Copyright MACS Inc, 1996
|
||||
|
||||
All rights to this package are hereby contributed to the community,
|
||||
and in particular to the MajorDomo development group, to do with as
|
||||
they see fit.
|
||||
|
||||
Introduction
|
||||
|
||||
Sequencer is a perl script based upon the resend script in the
|
||||
majordomo release 1.9.3. The script has been modified to (optionally)
|
||||
provide for sequence numbering of messages in their subject lines.
|
||||
This modification takes advantage of the 'subject-prefix'
|
||||
configuration variable already supported by majordomo, expanding it by
|
||||
including an additiona '$SEQNUM' expandable variable. Expansion of
|
||||
this variable is handled in the sequencer script so that the majordomo
|
||||
and config-parse.pl scripts did not have to be modified. Processing of
|
||||
$SEQNUM could be moved back into the config-parse.pl library if the
|
||||
development team believes this is useful.
|
||||
|
||||
|
||||
Documentation
|
||||
|
||||
Sequencing is invoked by calling the sequencer script
|
||||
with a '-n' (numbering) option. When this option is selected, the
|
||||
script uses a listname.seq file in the $filedir directory to determine
|
||||
the next message number. It uses the shlock.pl library to keep this file
|
||||
locked while the message is being processed (to prevent multiple use
|
||||
of the same sequence number, and skipping of sequence numbers when a
|
||||
message is bounced late in the script).
|
||||
|
||||
If there is a subject-prefix defined for the mailing list, and if
|
||||
there is a $SEQNUM in the defined subject-prefix, then the message's
|
||||
sequence number is placed in the subject line.
|
||||
|
||||
This script also provides for archiving the messages by sequence
|
||||
number. If the -N option is selected, then a copy of the message will
|
||||
be placed in the list's archive directory with the file name equal to
|
||||
the message's sequence number. In addition, if there is a file called
|
||||
INDEX in the archive directory, the message's date, time, author, and
|
||||
subject will be placed in that INDEX. Note that the -N option
|
||||
necessarily implies the -n option, since archiving without a valid
|
||||
sequnce number would be silly. Logically, -N is just a bigger
|
||||
version of -n.
|
||||
|
||||
This script also handles the absence of a subject. If there is no
|
||||
subject, the script creates a Subject: line with a subject of
|
||||
"Message for listname". This subject will also get a sequence number
|
||||
of the requirements specified above are satisfied.
|
||||
|
||||
Finally, the script increments the sequence number and updates the
|
||||
number in the listname.seq file, releasing the lock.
|
||||
|
||||
Conclusion
|
||||
|
||||
These extensions are pretty straightforward. I would recommend rolling
|
||||
them into the resend script. I would further recommend adding the
|
||||
$SEQNUM processing to the subject-prefix handler and getting the
|
||||
special case code out of the script. However, this could continue to
|
||||
exist as a standalone script. That is how I have done my
|
||||
implementation.
|
||||
|
||||
Also, I think it would be useful to include a man page for resend. If
|
||||
you don't have the time, I would be happy to try and put one together.
|
||||
However, I haven't written using the man macros in quite a while :-)
|
||||
18
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/digest.aliases
vendored
Normal file
18
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/digest.aliases
vendored
Normal file
@@ -0,0 +1,18 @@
|
||||
|
||||
firewalls: "|/usr/local/mail/majordomo/wrapper resend -l firewalls -h GreatCircle.COM firewalls-outgoing"
|
||||
firewalls-outgoing: :include:/usr/local/mail/lists/firewalls, firewalls-archive, firewalls-digestify
|
||||
firewalls-request: "|/usr/local/mail/majordomo/wrapper majordomo -l firewalls"
|
||||
firewalls-approval: brent
|
||||
owner-firewalls: brent
|
||||
owner-firewalls-outgoing: owner-firewalls
|
||||
|
||||
firewalls-archive: /usr/local/mail/archive/firewalls
|
||||
|
||||
firewalls-digestify: "|/usr/local/mail/majordomo/wrapper digest -r -C -l firewalls-digest firewalls-digest-outgoing"
|
||||
|
||||
firewalls-digest: firewalls
|
||||
firewalls-digest-outgoing: :include:/usr/local/mail/lists/firewalls-digest
|
||||
firewalls-digest-request: "|/usr/local/mail/majordomo/wrapper majordomo -l firewalls-digest"
|
||||
firewalls-digest-approval: brent
|
||||
owner-firewalls-digest-outgoing: owner-firewalls
|
||||
|
||||
51
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.cf
vendored
Normal file
51
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.cf
vendored
Normal file
@@ -0,0 +1,51 @@
|
||||
#Digest configuration file
|
||||
#
|
||||
|
||||
#name that appears in subject line and digest banner
|
||||
NAME=Firewalls Digest
|
||||
|
||||
#address reader send to to reply to the entire list
|
||||
REPLY-TO=Firewalls@GreatCircle.COM
|
||||
|
||||
#address error messages should go to
|
||||
ERRORS-TO=Firewalls-Digest-Owner@GreatCircle.COM
|
||||
|
||||
#address the digest itself appears to be sent to
|
||||
TO=Firewalls-Digest@GreatCircle.COM
|
||||
|
||||
#address the digest really is sent to
|
||||
REALLY-TO=Firewalls-Digest-Send@GreatCircle.COM
|
||||
|
||||
#address administrative nonsense should go to
|
||||
FROM=Firewalls-Digest-Owner@GreatCircle.COM
|
||||
|
||||
#file containing header text
|
||||
HEADER=/mycroft/brent/digest/firewalls-digest.header
|
||||
|
||||
#file containing trailer text
|
||||
TRAILER=/mycroft/brent/digest/firewalls-digest.trailer
|
||||
|
||||
#directory to store incoming messages
|
||||
#INCOMING=/usr/local/mail/digests/incoming/firewalls
|
||||
INCOMING=/mycroft/brent/digest/incoming
|
||||
|
||||
#file containing volume number
|
||||
VOL_FILE=/mycroft/brent/digest/firewalls-digest.vol
|
||||
|
||||
#file containing issue number
|
||||
NUM_FILE=/mycroft/brent/digest/firewalls-digest.num
|
||||
|
||||
#directory to archive outgoing issues
|
||||
ARCHIVE=/mycroft/brent/digest/archive
|
||||
|
||||
#directory containing shlock.pl and other stuff
|
||||
HOME=/mycroft/brent/digest
|
||||
|
||||
#how big do we let digests get before sending?
|
||||
DIGEST_SIZE=40000
|
||||
|
||||
#how many lines can a digest accumulate before we send it?
|
||||
DIGEST_LINES=
|
||||
|
||||
#what is the oldest message we will put in a digest?
|
||||
MAX_DAYS=
|
||||
6
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.header
vendored
Normal file
6
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.header
vendored
Normal file
@@ -0,0 +1,6 @@
|
||||
In this issue:
|
||||
|
||||
_SUBJECTS_
|
||||
|
||||
See the end of the digest for information on subscribing to the Firewalls
|
||||
or Firewalls-Digest mailing lists and on how to retrieve back issues.
|
||||
1
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.num
vendored
Normal file
1
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.num
vendored
Normal file
@@ -0,0 +1 @@
|
||||
13
|
||||
18
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.trailer
vendored
Normal file
18
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.trailer
vendored
Normal file
@@ -0,0 +1,18 @@
|
||||
To subscribe to Firewalls-Digest, send the command:
|
||||
|
||||
subscribe firewalls-digest
|
||||
|
||||
in the body of a message to "Majordomo@GreatCircle.COM". If you want
|
||||
to subscribe something other than the account the mail is coming from,
|
||||
such as a local redistribution list, then append that address to the
|
||||
"subscribe" command; for example, to subscribe "local-firewalls":
|
||||
|
||||
subscribe firewalls-digest local-firewalls@your.domain.net
|
||||
|
||||
A non-digest (direct mail) version of this list is also available; to
|
||||
subscribe to that instead, replace all instances of "firewalls-digest"
|
||||
in the commands above with "firewalls".
|
||||
|
||||
Back issues are available for anonymous FTP from FTP.GreatCircle.COM, in
|
||||
pub/firewalls/digest/vNN.nMMM (where "NN" is the volume number, and "MMM"
|
||||
is the issue number).
|
||||
1
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.vol
vendored
Normal file
1
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/firewalls-digest.vol
vendored
Normal file
@@ -0,0 +1 @@
|
||||
1
|
||||
588
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/list-owner-info
vendored
Normal file
588
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/list-owner-info
vendored
Normal file
@@ -0,0 +1,588 @@
|
||||
Majordomo address: # Majordomo@FooBar.COM
|
||||
Majordomo-Owner address:# Majordomo-Owner@FooBar.COM
|
||||
List Name: # ListName
|
||||
Is resend used: # yes
|
||||
Is the list archived: # no
|
||||
List posting address: # ListName@FooBar.COM
|
||||
List request address: # ListName-Request@FooBar.COM
|
||||
List password: # whatever
|
||||
Digest list name: # ListName-digest
|
||||
Digest list password: # whatever
|
||||
|
||||
Your mailing list has been established. It is being served by an
|
||||
automated mailing list manager that responds to commands emailed to
|
||||
the "Majordomo address" listed above. This message has all the details
|
||||
of how to manage your list remotely using Majordomo. If you have any
|
||||
questions, refer them to the Majordomo-Owner address listed above.
|
||||
|
||||
******
|
||||
There's a lot of info here, so please read this completely and
|
||||
carefully, and save it for future reference. If you have any questions,
|
||||
you should send them to the Majordomo-Owner address above.
|
||||
******
|
||||
|
||||
Your list-owner password is shown above. Keep track of this; you'll
|
||||
need it later. Instructions for changing your password are below.
|
||||
|
||||
As soon as possible, please issue a "newinfo" command for your
|
||||
list (see below) to create the file that someone will receive when
|
||||
they join or ask about your list.
|
||||
|
||||
You can issue a "who" command for your list to see who's already on your
|
||||
list. You may or may not already be subscribed to your own list.
|
||||
|
||||
================
|
||||
The Gory Details
|
||||
================
|
||||
|
||||
Your mailing list is managed by an automated mailing list management
|
||||
program called Majordomo. Majordomo should free you from dealing
|
||||
with most of the administrivia usually associated with running mailing
|
||||
lists (adding users, dropping users, etc.).
|
||||
|
||||
To submit something to your list, you (or anybody else) should simply
|
||||
mail it to the list posting address shown at the top of this file.
|
||||
|
||||
To be added to your list, a user simply sends a message to majordomo.
|
||||
There are two ways to do it:
|
||||
|
||||
address-- To: ListName-request@FooBar.COM
|
||||
message-- subscribe
|
||||
|
||||
OR
|
||||
|
||||
address-- To: majordomo@FooBar.COM
|
||||
message-- subscribe ListName
|
||||
|
||||
Majordomo understands several commands, and is not limited to a single
|
||||
command per message (it will process commands until reaching
|
||||
end-of-message or the command "end"). The command "help" will tell
|
||||
you about all the other commands.
|
||||
|
||||
Actually, it won't tell you about _all_ the other commands that
|
||||
Majordomo understands. There are several commands there for use by
|
||||
list owners such as yourself, which are not advertised to the public.
|
||||
All of these commands are password-protected on a list-by-list basis,
|
||||
but anyone with a valid list/password combination can invoke these
|
||||
commands. This is not exactly high-tech security, but it's more
|
||||
intended to keep annoyance to a minimum than to be foolproof.
|
||||
|
||||
The "documented" commands which Majordomo understands and which are
|
||||
for everyone to use are:
|
||||
|
||||
subscribe <list> [<address>]
|
||||
unsubscribe <list> [<address>]
|
||||
which [<address>]
|
||||
who <list>
|
||||
info <list>
|
||||
index <list>
|
||||
get <list>
|
||||
lists
|
||||
help
|
||||
end
|
||||
|
||||
You can get detailed explanations of all of these by asking for "help"
|
||||
from Majordomo (send a message containing just the word "help" as the
|
||||
message text to majordomo@FooBar.COM).
|
||||
|
||||
The "undocumented" commands for use by list owners are:
|
||||
|
||||
approve <passwd> {subscribe|unsubscribe} <list> [<address>]
|
||||
This is so that you can approve subscription or unsubscription
|
||||
actions that need approval by the list owner. Note that this
|
||||
is just a standard "subscribe" or "unsubscribe" command prefixed
|
||||
with "approve <password>" (where you substitute the password for
|
||||
your list, which is listed above, for "<password>").
|
||||
|
||||
approve <passwd> who <list>
|
||||
This allows you to get the list of addresses for your
|
||||
anonymous list. Without the password, even the list owner can
|
||||
not see who is on the list.
|
||||
|
||||
passwd <list> <old_passwd> <new_passwd>
|
||||
This is so you can change the password for your list, if you desire.
|
||||
|
||||
newintro <list> <password>
|
||||
This is so that you can replace the information file that people
|
||||
get when they do "intro <list>" or "subscribe <list>". It reads
|
||||
everything after the "newintro" command to end-of-message or the
|
||||
word "EOF" on a line by itself as the new intro for the list.
|
||||
|
||||
newinfo <list> <password>
|
||||
This replaces the information file that people get when they do
|
||||
"info <list>". (This file is also sent by "subscribe <list>" if
|
||||
the intro file doesn't exist.) This reads everything after the
|
||||
"newinfo" command to end-of-message or the word "EOF" on a line
|
||||
by itself as the new info for the list.
|
||||
|
||||
config <list> <password>
|
||||
Retrieves a self-documenting configuration file for
|
||||
the list <list>. The <password> can be the password
|
||||
contained in the file <list>.passwd or the
|
||||
admin_password in the configuration file.
|
||||
|
||||
newconfig <list> <password>
|
||||
Validates and installs a new configuration file. It reads
|
||||
everything after the "newconfig" command to end-of-message or
|
||||
the word "EOF" on a line by itself as the new info for the
|
||||
list. The config file is expected to be a complete config
|
||||
file as returned by "config". Incremental changing of the
|
||||
config file is not yet supported. As soon as the config file
|
||||
is validated and installed its settings are available for
|
||||
use. This is useful to remember if you have multiple commands
|
||||
in your mail message since they will be subject to the
|
||||
settings of the new config file. If there is an error in the
|
||||
config file (incorrect value...), the config file will not be
|
||||
accepted and the error message identifying the problem line(s)
|
||||
will be returned to the sender. Note that only the error
|
||||
messages are returned to the sender not the entire config
|
||||
file, so it would be a good idea to keep a copy of your
|
||||
outgoing email message.
|
||||
|
||||
writeconfig <list> <password>
|
||||
Write a new config file in standard form. Writeconfig forces a
|
||||
rewrite of the config file with all default values in place (or
|
||||
current values if the config file already exists). It is
|
||||
useful to use after an upgrade of majordomo since it will add
|
||||
the new keywords for people to change. It also updates the
|
||||
documentation in the file if that has changed.
|
||||
|
||||
mkdigest <digest list name> <password>
|
||||
mkdigest <digest list name> <digest outgoing alias> <password>
|
||||
Generate a digest immediately without waiting to reach the
|
||||
maxlength given in the config file. The first form will cause the
|
||||
digest to be sent to an alias found by appending "-outgoing" to the
|
||||
digest list name. Because this can be a security concern, the
|
||||
second form allows specification of the name of the alias that the
|
||||
outgoing digest will be sent to.
|
||||
|
||||
|
||||
Configuring Your List
|
||||
=====================
|
||||
|
||||
You should retrieve the configuration file for your list. To do this,
|
||||
send an email message to the majordomo address listed at the top of
|
||||
this form. The contents of this message should be:
|
||||
|
||||
config <list> <List password>
|
||||
|
||||
Where <list> <List password> are given at the top of the form. You
|
||||
will receive a config file that can be used to change the operation of
|
||||
your list. If the information at the top of this form shows that
|
||||
resend is being used, you want to configure the majordomo and resend
|
||||
subsystems. Otherwise you only have to configure those items that are
|
||||
associated with the majordomo system.
|
||||
|
||||
The configuration file is meant to be self documenting. Once you have
|
||||
completed all of the changes to the config file, You should use the
|
||||
newconfig command (described above) to put a new configuration file in
|
||||
place.
|
||||
|
||||
If you have a digest version of your list, you should retrieve the
|
||||
config file for the digest as well using:
|
||||
|
||||
config <Digest List Name> <Digest list password>
|
||||
|
||||
and configure the parameters for the digest and majordomo subsystems.
|
||||
|
||||
|
||||
Regular Expressions
|
||||
===================
|
||||
|
||||
For some of the configuration options, a rudimentary knowledge of perl
|
||||
style regular expressions will help you run Majordomo through its
|
||||
tricks. A regular expression is a concise way of expressing a pattern
|
||||
in a series of characters. The full power of regular expressions can
|
||||
make some difficult tasks quite easy, but we will only brush the
|
||||
surface here.
|
||||
|
||||
The character / is used to mark the beginning and end of a regular
|
||||
expression. Letters and numbers stand for themselves. Many of the
|
||||
other characters are symbolic. Some commonly used ones are:
|
||||
|
||||
\@ the `@' found in nearly all addresses; it must be preceeded by a
|
||||
backslash in later versions of perl to avoid errors
|
||||
. (period) any character
|
||||
* previous character, zero or more times; note especially...
|
||||
.* any character, zero or more times
|
||||
+ previous character, one or more times; so for example...
|
||||
a+ letter "a", one or more times
|
||||
\ next character stands for itself; so for example...
|
||||
\. literally a period, not meaning "any character"
|
||||
^ beginning of the string; so for example...
|
||||
^a a string beginning with letter "a"
|
||||
$ end of the string; so for example...
|
||||
a$ a string ending with letter "a"
|
||||
|
||||
Example 1.
|
||||
/cs\.umb\.edu/
|
||||
|
||||
Notice the periods are preceded by a backslash to make them be
|
||||
literally periods. This matches any string containing cs.umb.edu
|
||||
such as:
|
||||
cs.umb.edu
|
||||
foo.cs.umb.edu
|
||||
user@foo.cs.umb.edu
|
||||
users%foo.cs.umb.edu@greatcircle.com
|
||||
|
||||
Example 2.
|
||||
/rouilj\@.*cs\.umb\.edu/
|
||||
|
||||
The `@' has special meaning to later versions of perl and must be prefixed
|
||||
with a backslash to avoid errors. The string ".*" means "any character,
|
||||
zero or more times". So this matches:
|
||||
rouilj@cs.umb.edu
|
||||
rouilj@terminus.cs.umb.edu
|
||||
arouilj@terminus.cs.umb.edu@greatcircle.com
|
||||
|
||||
but it doesn't match
|
||||
rouilj@umb.edu
|
||||
brent@cs.umb.edu
|
||||
|
||||
Example 3.
|
||||
/^rouilj\@.*cs\.umb\.edu$/
|
||||
|
||||
This is similar to Example 2, and matches the same first two strings:
|
||||
rouilj@cs.umb.edu
|
||||
rouilj@terminus.cs.umb.edu
|
||||
|
||||
but it doesn't match
|
||||
arouilj@terminus.cs.umb.edu@greatcircle.com
|
||||
|
||||
because the regular expression says the string has to begin with
|
||||
letter "r" and end with letter "u", by using the ^ and $ symbols, and
|
||||
neither of those is true for arouilj@terminus.cs.umb.edu@greatcircle.com.
|
||||
|
||||
Example 4.
|
||||
/.*/
|
||||
|
||||
This is the regular expression that matches anything.
|
||||
|
||||
Example 5.
|
||||
/.\*rouilj/
|
||||
|
||||
Here the * is preceded by a \, so it refers literally to an asterisk
|
||||
character and not the symbolic meaning "zero or more times". The . still
|
||||
has its symbolic meaning of "any one character", so it would match for
|
||||
example
|
||||
a*rouilj
|
||||
s*rouilj
|
||||
|
||||
It would not match this because the . by itself implies one character:
|
||||
*rouilj
|
||||
|
||||
Normally all matches are case sensitive; you can make any match case
|
||||
insensitive by appending an `i' to the end of the expression.
|
||||
|
||||
Example 6.
|
||||
/aol\.com/i
|
||||
|
||||
This would match aol.com, AOL.com, AoL.cOm, etc. Removing the `i':
|
||||
|
||||
/aol\.com/
|
||||
|
||||
would match aol.com but not AOL.com or any other capitalization.
|
||||
|
||||
|
||||
To be on the safe side put a \ in front of any characters in the
|
||||
regular expressions that are not numbers or letters. In order to put
|
||||
a / into the regular expression, the same rule holds: precede it
|
||||
with a \. Thus, with \ in front of the / and = characters, this
|
||||
/\/CO\=US/
|
||||
|
||||
matches /CO=US and may be a useful regular expression to those of you
|
||||
who need to deal with X.400 addresses that contain / characters.
|
||||
|
||||
|
||||
Approval
|
||||
========
|
||||
|
||||
When Majordomo requests your approval for something, it sends you a
|
||||
message that includes a template of the approval message; if you concur,
|
||||
you simply need to replace "PASSWORD" in the template with your list
|
||||
password, and send the template line back to Majordomo.
|
||||
|
||||
The requests for approval that Majordomo generates all start with
|
||||
"APPROVE" in the "Subject:" line.
|
||||
|
||||
You aren't limited to approving only things to Majordomo requests
|
||||
approval for. You can approve any "subscribe" or "unsubscribe" request,
|
||||
regardless of whether Majordomo has requested this approval, with an
|
||||
"approve" command. Thus, you can subscribe or unsubscribe people from
|
||||
your list without them having to send anything to Majordomo; just
|
||||
send an appropriate "approve PASSWORD subscribe LIST ADDRESS" or
|
||||
"approve PASSWORD unsubscribe LIST ADDRESS" command off to Majordomo.
|
||||
|
||||
If you use a mailer which is capable of sending a message to an external
|
||||
program, can run perl and can run sendmail or a program capable of behaving
|
||||
like it for the purposes of sending mail, then all you have to do is send
|
||||
the entire approval message (including all of the headers, which are very
|
||||
important and which are automatically removed by some mailers unless
|
||||
configured to do otherwise) to the approve script. Approve looks for a
|
||||
file called ".majordomo" in your home directory to find the approval
|
||||
password for your list. The format of this file is given in the following
|
||||
excerpt from the approve manual page:
|
||||
|
||||
approve assumes that the approve password for each list is
|
||||
the same as the approval password used by resend, and that
|
||||
this password is stored in a file called .majordomo in the
|
||||
user's home directory. The file has the following format:
|
||||
|
||||
this-list passwd1 Majordomo@This.COM
|
||||
other-list passwd2 Majordomo@Other.GOV
|
||||
|
||||
The first column specifies the name of the mailing list, the
|
||||
second column specifies the list-owner's password for the
|
||||
given list, and the third column specifies the e-mail
|
||||
address of the associated Majordomo server. It is assumed
|
||||
that the value in the third column is an Internet-style
|
||||
"something@somewhere" address, and that postings for "List"
|
||||
should be sent to "List@somewhere". Since this file only
|
||||
needs to be read by the user, it should be mode 600 to pro-
|
||||
tect the passwords.
|
||||
|
||||
If you have the necessary environment for running the approve script,
|
||||
contact the Majordomo owner at the site that serves your list and request
|
||||
it.
|
||||
|
||||
|
||||
Bounced Messages
|
||||
================
|
||||
|
||||
Majordomo may bounce certain messages that people attempt to post to your
|
||||
mailing list. These messages may be bounced because they appear to be
|
||||
administrative requests (i.e., someone mailed a request to subscribe or
|
||||
unsubscribe to the posting address rather than to Majordomo or to the
|
||||
-request address), because they are too long, because they match strings
|
||||
that you or the list server owner has defined as being "taboo", or for any
|
||||
of a number of other reasons, many of which may seem annoying but have been
|
||||
decided upon as being useful in stopping unwanted messages from making it
|
||||
onto your list. (These are often configurable, so if you find a check to
|
||||
be too restrictive you can generally turn it off.) Note also that the
|
||||
bounces mentioned here are not the same as the errors that will be returned
|
||||
by various mail servers when addresses or hosts are unreachable. Those are
|
||||
generally referred to as bounces, also; sorry for the confusion.
|
||||
|
||||
Majordomo will forward these messages to you in another message whose
|
||||
subject line begins with the word "BOUNCE"; the subject line will also
|
||||
indicate the name of the list the message was bounced from (in case you
|
||||
manage more than one list) and the reason the message was bounced.
|
||||
|
||||
If you decide that the message is OK and should not have been bounced, then
|
||||
you can cause Majordomo to post it anyway by sending the message back to
|
||||
the posting address (NOT to the Majordomo address) with a special
|
||||
"Approved: password" header. There are two ways to do this; the method you
|
||||
use depends on your having access to and the ability to run the approve
|
||||
script mentioned in the previous section. If you can run approve it is
|
||||
recommended that you do so, as this method is much less prone to errors and
|
||||
will reduce the time you spend moderating your list.
|
||||
|
||||
If you cannot run the approve script, you can manually approve the
|
||||
message. To do so, follow the following directions _exactly_:
|
||||
|
||||
1) Save the original message (the body of the message you received
|
||||
from Majordomo) in a file. The portion you need will consist of
|
||||
the headers of the original message, followed by a single blank
|
||||
line, followed by the text of the original message. You do not
|
||||
need to include any of the headers of the message which contained
|
||||
the original message. Here's a quick example:
|
||||
|
||||
From: majordomo@list.server \
|
||||
To: your-list-approval@list.server | Don't want these headers
|
||||
Subject: BOUNCE: taboo_header found /
|
||||
- Blank line
|
||||
>From list-member@her.site date \
|
||||
Received: some long routing info | Headers of original message;
|
||||
From: list-member@her.site | You want these. It's OK if you
|
||||
To: your-list@list.server | don't have the first line.
|
||||
Subject: Just a message /
|
||||
- Blank line, you _must_ have this!
|
||||
Hello. I'm just writing to \
|
||||
consume some bandwidth and | Message body; include all of
|
||||
take up space in your mail | this.
|
||||
spool! /
|
||||
|
||||
Basically you want everything after (and not including) the first
|
||||
blank line.
|
||||
|
||||
2) Edit the file to insert a line that says "Approved: password" (where
|
||||
"password" is the password for your list) at the top, before the
|
||||
original message, with absolutely no intervening space:
|
||||
|
||||
Approved: sekrit
|
||||
>From list-member@her.site date
|
||||
Received: some long routing info
|
||||
From: list-member@her.site
|
||||
To: your-list@list.server
|
||||
Subject: Just a message
|
||||
|
||||
Hello. I'm just writing to
|
||||
consume some bandwidth and
|
||||
take up space in your mail
|
||||
spool!
|
||||
|
||||
3) Send this edited file back to the posting address for your list (NOT
|
||||
to Majordomo). You should make sure that your mailer doesn't try
|
||||
to do anything like include your prepared mail as an attachment,
|
||||
encode it somehow, indent every line, or add anything extra to the
|
||||
beginning or end of the message. There are mailers that will do
|
||||
pretty horrible things to messages before they are sent; you should
|
||||
take care that you aren't using one or, if you are, you have it
|
||||
configured to pass your text on unadulterated.
|
||||
|
||||
This time around, Majordomo will notice the "Approved:" line and check it
|
||||
against your list password. If it matches, Majordomo will strip off the
|
||||
header of your message and the "Approved:" line (leaving just the original
|
||||
message), and send the original message on through.
|
||||
|
||||
Even your own messages bay be bounced to you for approval. To send out your
|
||||
own message without server checks (perhaps you know it contains something
|
||||
the list server will complain about) you can pre-approve the message one of
|
||||
the two following ways:
|
||||
|
||||
If you're using a mailer that can add additional headers, add one like the
|
||||
following:
|
||||
|
||||
Approved: sekrit
|
||||
|
||||
It's precise location within the headers is not important.
|
||||
|
||||
If your mailer does not allow you to add additional headers, you can add
|
||||
the line:
|
||||
|
||||
Approved: sekrit
|
||||
|
||||
as the first line of the message, followed by a blank line (which is
|
||||
required for your message to be sent properly) followed by the text of your
|
||||
message. The Approved: line and one following blank line will be deleted
|
||||
and the message will be passed without being checked. The blank line is
|
||||
important because it is used to differentiate between a pre-approval and the
|
||||
approval of a bounced message, outlined above.
|
||||
|
||||
|
||||
Moderation
|
||||
==========
|
||||
|
||||
If your list is moderated, (the moderate parameter in the config
|
||||
file is yes) then messages without an "Approved:" line are bounced,
|
||||
just as described above. To cause them to be posted to the list, you
|
||||
add a valid "Approved:" line and send them back, just as described
|
||||
above.
|
||||
|
||||
Again, the "approve" program automates all this if you wish to use it. You
|
||||
can also use the above pre-approval method to send your own messages
|
||||
without them being bounced back to you.
|
||||
|
||||
If you have any questions about all of this, send them to the Majordomo-Owner
|
||||
address shown at the top of this file.
|
||||
|
||||
|
||||
Restricting Posting
|
||||
===================
|
||||
|
||||
An easier alternative to moderation is to restrict who can post to the
|
||||
list, which can be done with the restrict_post configuration variable.
|
||||
The variable requires a file listing the people who can post.
|
||||
|
||||
The most common case is to limit posting to people who are subscribed
|
||||
to the list. This keeps out advertisements and other junk mail sent
|
||||
by non-subscribers. Since majordomo already has a file of subscribers,
|
||||
you don't need to create and maintain a file, so it's easy to set.
|
||||
|
||||
Change the restrict_post line to this, where <listname> is the name of
|
||||
your list:
|
||||
|
||||
restrict_post = <listname>
|
||||
|
||||
If you want to restrict posting to any other set of people, you'll
|
||||
need to ask majordomo-owner for help. Unfortunately there's no way to
|
||||
tell majordomo about keeping another file of people who are allowed to
|
||||
post, so a file would have to be set in place "by hand". Some future
|
||||
release of majordomo may provide a way to do this automatically.
|
||||
|
||||
|
||||
Archive
|
||||
=======
|
||||
|
||||
Archiving has to be set or unset by the system administrators reached
|
||||
at majordomo-owner@FooBar.COM. It is not the default but must be
|
||||
requested. Here is what can be done.
|
||||
|
||||
Archive files can be split by years, months, or days. This means all
|
||||
mail to the list for one of those periods of time will be collected
|
||||
into one archive file. People who want to get archived mail will need
|
||||
to get one such file as a unit.
|
||||
|
||||
We are running an indexer program nightly. It produces two index files
|
||||
that subscribers can get: CONTENTS lists what subject lines are in each
|
||||
archive file; TOPICS lists what archive files contain each subject.
|
||||
|
||||
Subscribers use the "get" command to see files in the archives. Examples:
|
||||
get ListName CONTENTS # gets the CONTENTS file
|
||||
get ListName ListName.9507 # gets the July 1995 archive file
|
||||
|
||||
Access to archives is controlled by the get_access variable in the
|
||||
config file. The default "list" means they must be subscribers to get
|
||||
archived files.
|
||||
|
||||
Subscribers can also get a list of filenames and dates in the archive
|
||||
by sending an "index" command. Example:
|
||||
index ListName
|
||||
|
||||
This is controlled by the config file variable index_access similarly.
|
||||
|
||||
Notes on archiving.
|
||||
|
||||
- It's possible for the archive to contain files besides the indexes
|
||||
and the archive files of messages. However, majordomo offers no
|
||||
method for you to put them there. In an unusual case you can ask
|
||||
majordomo-owner to put a file there for you.
|
||||
|
||||
- Archiving could be accomplished by directing a copy of messages to
|
||||
some other place besides the majordomo archive. Ask, if you have
|
||||
something in mind.
|
||||
|
||||
|
||||
Digest
|
||||
=======
|
||||
|
||||
A digest version of a list is a way to reduce the number of messages sent
|
||||
from Majordomo to subscribers. Normally, each message to the list is
|
||||
remailed to all the subscribers, but with a digest, several messages are
|
||||
collected into a batch and then sent together as one message. This does
|
||||
not reduce the total size too much, although there are fewer mail header
|
||||
lines-- the main purpose is to reduce the number of separate messages.
|
||||
This actually helps the mail systems at both ends, and may help subscribers
|
||||
reduce clutter in their mailboxes.
|
||||
|
||||
A Majordomo digest is actually a separate mailing list. The digest of
|
||||
ListName would normally be called ListName-digest.
|
||||
|
||||
People subscribe independently to ListName and ListName-digest.
|
||||
Very likely no one would want to be on both lists. To change between
|
||||
ListName and ListName-digest, a subscriber needs to unsubscribe
|
||||
from one list and subscribe to the other. This can be done with one
|
||||
message to majordomo@FooBar.COM with two command lines in it, e.g.:
|
||||
unsubscribe ListName
|
||||
subscribe ListName-digest
|
||||
|
||||
Remember that ListName-digest will have its own information file and
|
||||
configuration file. Change them, if you want to, when you change the
|
||||
same files for ListName.
|
||||
|
||||
Majordomo will send a digest automatically when the size of the digest
|
||||
exceeds the size given as max_length in the configuration file of the
|
||||
digest list. The default max_length is 40 K. Thus the interval
|
||||
between digests can vary, but they will be of a predictable size.
|
||||
|
||||
The listowner can also tell Majordomo to make a digest (meaning, compile
|
||||
and send out a digest) by sending the command mkdigest at any time:
|
||||
mkdigest ListName-digest password
|
||||
|
||||
A daily digest (or for some other time period) could be achieved by
|
||||
setting the max_length high enough so as not to be reached normally in
|
||||
a day, and then setting up a job to run daily that sends mail to
|
||||
Majordomo with the mkdigest command. On a unix system, give the
|
||||
commands "man crontab" and "man 5 crontab" at the shell for an
|
||||
explanation of such jobs, or ask majordomo-owner for help.
|
||||
|
||||
1456
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo-faq.html
vendored
Normal file
1456
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo-faq.html
vendored
Normal file
File diff suppressed because it is too large
Load Diff
1350
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo-faq.txt
vendored
Normal file
1350
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo-faq.txt
vendored
Normal file
File diff suppressed because it is too large
Load Diff
8203
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo.lisa6.ps
vendored
Normal file
8203
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo.lisa6.ps
vendored
Normal file
File diff suppressed because it is too large
Load Diff
1718
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo.ora
vendored
Normal file
1718
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/majordomo.ora
vendored
Normal file
File diff suppressed because it is too large
Load Diff
137
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/approve.1
vendored
Normal file
137
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/approve.1
vendored
Normal file
@@ -0,0 +1,137 @@
|
||||
'\" t
|
||||
.TH APPROVE 1
|
||||
.SH NAME
|
||||
approve \- approve a Majordomo request
|
||||
.SH SYNOPSIS
|
||||
.B approve [filename]
|
||||
.SH "DESCRIPTION"
|
||||
.B approve
|
||||
automates the task of replying to an approval request from Majordomo. Input
|
||||
is the e-mail message containing Majordomo's request, read from
|
||||
.IR filename ,
|
||||
or read from standard input if no filename is specified.
|
||||
.PP
|
||||
.B approve
|
||||
currently understands two types of requests; those requesting
|
||||
subscription to a
|
||||
.I closed
|
||||
list, and those which bounced due to a lack of permission to post to a
|
||||
moderated, or
|
||||
.IR private ,
|
||||
mailing list.
|
||||
.B approve
|
||||
reads the body of the message from Majordomo to determine the appropriate
|
||||
action. Assuming a message containing a subscription request like the
|
||||
following:
|
||||
.sp 1
|
||||
.RS 3
|
||||
From: Majordomo@This.COM
|
||||
.sp 0
|
||||
To: this-list-approval@This.COM
|
||||
.sp 1
|
||||
Joe User <User@Fubar.COM> requests you approve the following:
|
||||
.sp 1
|
||||
.RS 3
|
||||
subscribe this-list Joe User <User@Fubar.COM>
|
||||
.RE
|
||||
.sp 1
|
||||
If you approve, send a line such as the following to Majordomo@This.COM:
|
||||
.sp 1
|
||||
.RS 3
|
||||
approve PASSWD subscribe this-list Joe User <User@Fubar.COM>
|
||||
.RE
|
||||
.RE
|
||||
.sp 1
|
||||
then running
|
||||
.B approve
|
||||
on the message by saving it in a file, e.g.,
|
||||
.sp 1
|
||||
.RS 3
|
||||
approve /tmp/request
|
||||
.RE
|
||||
.sp 1
|
||||
or
|
||||
.sp 1
|
||||
.RS 3
|
||||
approve < /tmp/request
|
||||
.RE
|
||||
.sp 1
|
||||
will result in the following reply to Majordomo:
|
||||
.sp 1
|
||||
.RS 3
|
||||
To: Majordomo@This.COM
|
||||
.sp 1
|
||||
approve PASSWD subscribe this-list User@Fubar.COM (Joe User)
|
||||
.sp 1
|
||||
.RE
|
||||
If
|
||||
.B approve
|
||||
is on the user's path, then it's possible to execute it via a shell escape,
|
||||
piping the current message to
|
||||
.B approve
|
||||
from a mail program, e.g.,
|
||||
.sp
|
||||
.RS 3
|
||||
!approve
|
||||
.RE
|
||||
.sp
|
||||
would
|
||||
.I approve
|
||||
the current message in /usr/ucb/Mail.
|
||||
.PP
|
||||
If, in the latter case, the "Subject:" line of the request from Majordomo is
|
||||
"BOUNCE <list>: <reason>", the message is treated as a posting rejected by
|
||||
.B resend
|
||||
for some reason, and is reformatted with appropriate "Approved:" headers to
|
||||
cause it to succeed, and then it is resubmitted to Majordomo for posting.
|
||||
This provides an easy mechanism for the moderator of a mailing list to
|
||||
approve postings to the list.
|
||||
.SH CONFIGURATION
|
||||
.B approve
|
||||
assumes that the
|
||||
.I approve
|
||||
password for each list is the same as the
|
||||
.I approval
|
||||
password used by
|
||||
.BR resend ,
|
||||
and that this password is stored
|
||||
in a file called
|
||||
.I .majordomo
|
||||
in the user's home directory. The file has the following format:
|
||||
.RS 5
|
||||
.TS
|
||||
l l l .
|
||||
.sp
|
||||
this-list passwd1 Majordomo@This.COM
|
||||
other-list passwd2 Majordomo@Other.GOV
|
||||
.sp
|
||||
.TE
|
||||
.RE
|
||||
The first column specifies the name of the mailing list, the second column
|
||||
specifies the list-owner's password for the given list, and the third column
|
||||
specifies the e-mail address of the associated Majordomo server. It is
|
||||
assumed that the value in the third column is an Internet-style
|
||||
"something@somewhere" address, and that postings for "List" should be sent
|
||||
to "List@somewhere". Since this file
|
||||
.B only
|
||||
needs to be read by the user, it should be mode 600 to protect the
|
||||
passwords.
|
||||
.SH FILES
|
||||
~/.majordomo
|
||||
.sp 0
|
||||
/usr/local/lib/mail/majordomo/
|
||||
.SH SEE ALSO
|
||||
majordomo(8),perl(1),resend(1).
|
||||
.SH BUGS
|
||||
There is no direct support for MH(1), so MH users will have to run
|
||||
.B approve
|
||||
directly on the message file in their inbox.
|
||||
.sp
|
||||
The
|
||||
.I .majordomo
|
||||
file requires an at-sign, "@", in the address of the Majordomo server, even
|
||||
if it colocated on the same system as the list-owner.
|
||||
.SH AUTHORS
|
||||
Majordomo and most of the ancillary perl code was written by Brent Chapman,
|
||||
<brent@GreatCircle.COM>.
|
||||
This man page was written by Jim Duncan, <jim@math.psu.edu>.
|
||||
132
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/approve.man
vendored
Normal file
132
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/approve.man
vendored
Normal file
@@ -0,0 +1,132 @@
|
||||
|
||||
|
||||
|
||||
APPROVE(1) USER COMMANDS APPROVE(1)
|
||||
|
||||
|
||||
|
||||
NAME
|
||||
approve - approve a Majordomo request
|
||||
|
||||
SYNOPSIS
|
||||
approve [filename]
|
||||
|
||||
DESCRIPTION
|
||||
approve automates the task of replying to an approval
|
||||
request from Majordomo. Input is the e-mail message con-
|
||||
taining Majordomo's request, read from _f_i_l_e_n_a_m_e, or read
|
||||
from standard input if no filename is specified.
|
||||
|
||||
approve currently understands two types of requests; those
|
||||
requesting subscription to a _c_l_o_s_e_d list, and those which
|
||||
bounced due to a lack of permission to post to a moderated,
|
||||
or _p_r_i_v_a_t_e, mailing list. approve reads the body of the
|
||||
message from Majordomo to determine the appropriate action.
|
||||
Assuming a message containing a subscription request like
|
||||
the following:
|
||||
|
||||
From: Majordomo@This.COM
|
||||
To: this-list-approval@This.COM
|
||||
|
||||
Joe User <User@Fubar.COM> requests you approve the fol-
|
||||
lowing:
|
||||
|
||||
subscribe this-list Joe User <User@Fubar.COM>
|
||||
|
||||
If you approve, send a line such as the following to
|
||||
Majordomo@This.COM:
|
||||
|
||||
approve PASSWD subscribe this-list Joe User
|
||||
<User@Fubar.COM>
|
||||
|
||||
then running approve on the message by saving it in a file,
|
||||
e.g.,
|
||||
|
||||
approve /tmp/request
|
||||
|
||||
or
|
||||
|
||||
approve < /tmp/request
|
||||
|
||||
will result in the following reply to Majordomo:
|
||||
|
||||
To: Majordomo@This.COM
|
||||
|
||||
approve PASSWD subscribe this-list User@Fubar.COM (Joe
|
||||
User)
|
||||
|
||||
If approve is on the user's path, then it's possible to exe-
|
||||
cute it via a shell escape, piping the current message to
|
||||
|
||||
|
||||
|
||||
Sun Release 4.1 Last change: 1
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
APPROVE(1) USER COMMANDS APPROVE(1)
|
||||
|
||||
|
||||
|
||||
approve from a mail program, e.g.,
|
||||
|
||||
!approve
|
||||
|
||||
would _a_p_p_r_o_v_e the current message in /usr/ucb/Mail.
|
||||
|
||||
If, in the latter case, the "Subject:" line of the request
|
||||
from Majordomo is "BOUNCE <list>: <reason>", the message is
|
||||
treated as a posting rejected by resend for some reason, and
|
||||
is reformatted with appropriate "Approved:" headers to cause
|
||||
it to succeed, and then it is resubmitted to Majordomo for
|
||||
posting. This provides an easy mechanism for the moderator
|
||||
of a mailing list to approve postings to the list.
|
||||
|
||||
CONFIGURATION
|
||||
approve assumes that the _a_p_p_r_o_v_e password for each list is
|
||||
the same as the _a_p_p_r_o_v_a_l password used by resend, and that
|
||||
this password is stored in a file called ._m_a_j_o_r_d_o_m_o in the
|
||||
user's home directory. The file has the following format:
|
||||
|
||||
this-list passwd1 Majordomo@This.COM
|
||||
other-list passwd2 Majordomo@Other.GOV
|
||||
|
||||
The first column specifies the name of the mailing list, the
|
||||
second column specifies the list-owner's password for the
|
||||
given list, and the third column specifies the e-mail
|
||||
address of the associated Majordomo server. It is assumed
|
||||
that the value in the third column is an Internet-style
|
||||
"something@somewhere" address, and that postings for "List"
|
||||
should be sent to "List@somewhere". Since this file only
|
||||
needs to be read by the user, it should be mode 600 to pro-
|
||||
tect the passwords.
|
||||
|
||||
FILES
|
||||
~/.majordomo
|
||||
/usr/local/lib/mail/majordomo/
|
||||
|
||||
SEE ALSO
|
||||
majordomo(8),perl(1),resend(1).
|
||||
|
||||
BUGS
|
||||
There is no direct support for MH(1), so MH users will have
|
||||
to run approve directly on the message file in their inbox.
|
||||
|
||||
The ._m_a_j_o_r_d_o_m_o file requires an at-sign, "@", in the address
|
||||
of the Majordomo server, even if it colocated on the same
|
||||
system as the list-owner.
|
||||
|
||||
AUTHORS
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman, <brent@GreatCircle.COM>. This man page was
|
||||
written by Jim Duncan, <jim@math.psu.edu>.
|
||||
|
||||
|
||||
|
||||
Sun Release 4.1 Last change: 2
|
||||
|
||||
|
||||
|
||||
1
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce-remind.1
vendored
Normal file
1
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce-remind.1
vendored
Normal file
@@ -0,0 +1 @@
|
||||
.so man1/bounce.1
|
||||
198
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce-remind.man
vendored
Normal file
198
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce-remind.man
vendored
Normal file
@@ -0,0 +1,198 @@
|
||||
|
||||
|
||||
|
||||
bbbboooouuuunnnncccceeee((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV bbbboooouuuunnnncccceeee((((1111))))
|
||||
|
||||
|
||||
|
||||
NNNNAAAAMMMMEEEE
|
||||
bounce, bounce-remind - handle majordomo list subscribers
|
||||
whose mail is undeliverable
|
||||
|
||||
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
|
||||
bbbboooouuuunnnncccceeee [[[[----dddd]]]] [[[[----ffff _c_o_n_f_i_g-_f_i_l_e ]]]] [[[[----mmmmaaaajjjjoooorrrrddddoooommmmoooo _s_e_r_v_e_r-_a_d_d_r_e_s_s ]]]]
|
||||
[[[[----uuuunnnnssssuuuubbbb]]]] _m_a_j_o_r_d_o_m_o-_l_i_s_t _u_s_e_r-_a_d_d_r_e_s_s
|
||||
|
||||
bbbboooouuuunnnncccceeee [[[[----dddd]]]] [[[[----ffff _c_o_n_f_i_g-_f_i_l_e ]]]] [[[[----mmmmaaaajjjjoooorrrrddddoooommmmoooo _s_e_r_v_e_r-_a_d_d_r_e_s_s ]]]]
|
||||
----eeeexxxxppppiiiirrrreeee [[[[----mmmmaaaaxxxxaaaaggggeeee _d_a_y_s ]]]] _b_o_u_n_c_e-_a_d_d_r_e_s_s-_f_i_l_e
|
||||
|
||||
bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd
|
||||
|
||||
AAAAVVVVAAAAIIIILLLLAAAABBBBIIIILLLLIIIITTTTYYYY
|
||||
Provided with distributions of Majordomo.
|
||||
|
||||
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
|
||||
bbbboooouuuunnnncccceeee and bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd are perl scripts which help list
|
||||
owners handle subscribers whose mail is bouncing. Mail is
|
||||
"bounced" in this context when it is undeliverable because
|
||||
hosts or addresses are unreachable or because of other mail
|
||||
errors.
|
||||
|
||||
Mail is also "bounced" by the resend script for various
|
||||
administrative reasons; these bounces are described in
|
||||
aaaapppppppprrrroooovvvveeee(1).
|
||||
|
||||
When a list owner observes that an email address
|
||||
consistently causes mail errors, the owner may use bbbboooouuuunnnncccceeee to
|
||||
remove the address from the list and place the address on a
|
||||
special bbbboooouuuunnnncccceeeessss mailing list.
|
||||
|
||||
bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd,,,, which should be run nightly by ccccrrrroooonnnn(4M),
|
||||
sends a message to each of the user addresses on the bbbboooouuuunnnncccceeeessss
|
||||
list, on the chance that the mail error has been corrected.
|
||||
The message informs the addressee that their mail has been
|
||||
undeliverable and that they have been removed from one or
|
||||
more majordomo lists. It also instructs them how to
|
||||
unsubscribe from the bbbboooouuuunnnncccceeeessss list and re-subscribe to the
|
||||
list of their choice.
|
||||
|
||||
bbbboooouuuunnnncccceeee can also be used to expire addresses off the bbbboooouuuunnnncccceeeessss
|
||||
list after a predetermined number of days.
|
||||
|
||||
If bbbboooouuuunnnncccceeee is invoked under a name that contains ``unsub'' it
|
||||
will simply unsubscribe the offending address from the
|
||||
majordomo list; it will not place the address on the bbbboooouuuunnnncccceeeessss
|
||||
list.
|
||||
|
||||
OOOOPPPPTTTTIIIIOOOONNNNSSSS
|
||||
These options relate to bbbboooouuuunnnncccceeee;;;; bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd takes no
|
||||
arguments or options.
|
||||
|
||||
|
||||
|
||||
Page 1 (printed 9/24/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
bbbboooouuuunnnncccceeee((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV bbbboooouuuunnnncccceeee((((1111))))
|
||||
|
||||
|
||||
|
||||
----dddd Debug; print what would be done, but don't do it.
|
||||
|
||||
----ffff ccccoooonnnnffffiiiigggg----ffffiiiilllleeee
|
||||
Use the specified configuration file. The default
|
||||
is ~~~~////....mmmmaaaajjjjoooorrrrddddoooommmmoooo,,,, and the format for this file is
|
||||
described in the CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN section of the
|
||||
aaaapppppppprrrroooovvvveeee(1) man page. This file provides the
|
||||
list-owner's password for each list and the
|
||||
address of the corresponding Majordomo server.
|
||||
|
||||
----mmmmaaaajjjjoooorrrrddddoooommmmoooo sssseeeerrrrvvvveeeerrrr----aaaaddddddddrrrreeeessssssss
|
||||
Use this _s_e_r_v_e_r-_a_d_d_r_e_s_s for majordomo rather than
|
||||
the address from the configuration file.
|
||||
|
||||
----uuuunnnnssssuuuubbbb Unsubscribes the offending address from the
|
||||
majordomo list, without entering that address on
|
||||
the bbbboooouuuunnnncccceeeessss list. This is equivalent to invoking
|
||||
bbbboooouuuunnnncccceeee under a name containing ``unsub''.
|
||||
|
||||
----eeeexxxxppppiiiirrrreeee Expire entries from the specified bbbboooouuuunnnncccceeeessss list.
|
||||
|
||||
----mmmmaaaaxxxxaaaaggggeeee ddddaaaayyyyssss
|
||||
Expire entries older than ddddaaaayyyyssss.... The default is
|
||||
coded into the bbbboooouuuunnnncccceeee script as $$$$ddddeeeeffffaaaauuuulllltttt____mmmmaaaaxxxxaaaaggggeeee
|
||||
days. It is set to 21 days in the majordomo
|
||||
distribution.
|
||||
|
||||
OOOOPPPPEEEERRRRAAAANNNNDDDDSSSS
|
||||
mmmmaaaajjjjoooorrrrddddoooommmmoooo----lllliiiisssstttt
|
||||
The list from which the offending user-address
|
||||
should be removed.
|
||||
|
||||
uuuusssseeeerrrr----aaaaddddddddrrrreeeessssssss
|
||||
The address to which mail is currently
|
||||
undeliverable.
|
||||
|
||||
bbbboooouuuunnnncccceeee----aaaaddddddddrrrreeeessssssss----ffffiiiilllleeee
|
||||
The name of the file that contains the bbbboooouuuunnnncccceeeessss
|
||||
list.
|
||||
|
||||
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
|
||||
If bbbboooouuuunnnncccceeee is going to be used only to unsubscribe users, a
|
||||
link can be created whose name contains ``unsub'' so that
|
||||
users could be unsubscribed simply by typing
|
||||
|
||||
unsub firewalls-digest fury@world.std.com
|
||||
|
||||
for example.
|
||||
|
||||
In any case, a configuration file must exist and must
|
||||
contain the names of the owner's lists, along with their
|
||||
respective passwords and the email address of the associated
|
||||
|
||||
|
||||
|
||||
Page 2 (printed 9/24/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
bbbboooouuuunnnncccceeee((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV bbbboooouuuunnnncccceeee((((1111))))
|
||||
|
||||
|
||||
|
||||
Majordomo server. The format of this file is given in the
|
||||
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN section of the aaaapppppppprrrroooovvvveeee(1) man page. The
|
||||
default name for this file is ~~~~////....mmmmaaaajjjjoooorrrrddddoooommmmoooo,,,, and the same
|
||||
file can serve for both the aaaapppppppprrrroooovvvveeee and bbbboooouuuunnnncccceeee scripts.
|
||||
|
||||
The bbbboooouuuunnnncccceeeessss list, if it is used, must be created. It is
|
||||
like any other Majordomo list excepting that the priority of
|
||||
this list should be set to jjjjuuuunnnnkkkk and its owner and sender
|
||||
should be nnnnoooobbbbooooddddyyyy.... Of course, the ``nobody'' mail alias must
|
||||
exist; it is should be set to /dev/null. That is,
|
||||
|
||||
nobody: /dev/null
|
||||
|
||||
This will spare the human list owner as well as the
|
||||
postmaster from having to deal with mail bouncing from the
|
||||
bbbboooouuuunnnncccceeeessss list.
|
||||
|
||||
A ccccrrrroooonnnn(1M) job should be set up to run bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd every
|
||||
night. bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd must run on the same server as the
|
||||
bbbboooouuuunnnncccceeeessss list; it mails a message to everyone on the list
|
||||
advising them that they have been removed from one or more
|
||||
Majordomo lists and instructs them how to get off the
|
||||
bbbboooouuuunnnncccceeeessss list and back on the list of their choice.
|
||||
|
||||
bbbboooouuuunnnncccceeee can only expire addresses if it has a copy of the
|
||||
bbbboooouuuunnnncccceeeessss subscriber file, so this can either be run on the
|
||||
server occasionally by the Majordomo administrator or by a
|
||||
cron job. It can also be run remotely with a copy of the
|
||||
bbbboooouuuunnnncccceeeessss file retrived by the use of the ``who bounces''
|
||||
command to majordomo.
|
||||
|
||||
FFFFIIIILLLLEEEESSSS
|
||||
////eeeettttcccc////aaaalllliiiiaaaasssseeeessss
|
||||
////eeeettttcccc////mmmmaaaajjjjoooorrrrddddoooommmmoooo....ccccffff
|
||||
|
||||
SSSSEEEEEEEE AAAALLLLSSSSOOOO
|
||||
mmmmaaaajjjjoooorrrrddddoooommmmoooo((((8888)))),,,,aaaapppppppprrrroooovvvveeee((((1111))))
|
||||
|
||||
AAAAUUUUTTTTHHHHOOOORRRR
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman <brent@GreatCircle.COM>. Majordomo is
|
||||
available via anonymous FTP from FTP.GreatCircle.COM, in the
|
||||
directory pub/majordomo. This man page was written by Kevin
|
||||
Kelleher <fury@world.std.com>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Page 3 (printed 9/24/96)
|
||||
|
||||
|
||||
|
||||
221
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce.1
vendored
Normal file
221
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce.1
vendored
Normal file
@@ -0,0 +1,221 @@
|
||||
.TH bounce 1
|
||||
.SH NAME
|
||||
bounce, bounce-remind \- handle majordomo list subscribers whose mail is undeliverable
|
||||
.LP
|
||||
.SH SYNOPSIS
|
||||
.B bounce [\-d] [\-f
|
||||
.I config-file
|
||||
.B ] [\-majordomo
|
||||
.I server-address
|
||||
.B ] [\-unsub]
|
||||
.I majordomo-list user-address
|
||||
.LP
|
||||
.B bounce [\-d] [\-f
|
||||
.I config-file
|
||||
.B ] [\-majordomo
|
||||
.I server-address
|
||||
.B ] \-expire [\-maxage
|
||||
.I days
|
||||
.B ]
|
||||
.I bounce-address-file
|
||||
.LP
|
||||
.B bounce-remind
|
||||
.LP
|
||||
.SH AVAILABILITY
|
||||
Provided with distributions of Majordomo.
|
||||
.LP
|
||||
.SH DESCRIPTION
|
||||
.B bounce
|
||||
and
|
||||
.B bounce-remind
|
||||
are perl scripts which help list owners
|
||||
handle subscribers whose mail is bouncing. Mail is "bounced"
|
||||
in this context when it is undeliverable because hosts or
|
||||
addresses are unreachable or because of other mail errors.
|
||||
.LP
|
||||
Mail is also "bounced" by the resend script for various administrative
|
||||
reasons; these bounces are described in
|
||||
.BR approve (1).
|
||||
.LP
|
||||
When a list owner observes that an email address consistently causes
|
||||
mail errors, the owner may use
|
||||
.B bounce
|
||||
to remove the address from the list and place the address on a special
|
||||
.BR bounces
|
||||
mailing list.
|
||||
.LP
|
||||
.B bounce-remind,
|
||||
which should be run nightly by
|
||||
.BR cron (4M),
|
||||
sends a message to each of the user addresses on the
|
||||
.BR bounces
|
||||
list, on the chance that the mail error has been corrected.
|
||||
The message informs the addressee that their mail has been
|
||||
undeliverable and that they have been removed from one or
|
||||
more majordomo lists. It also instructs them how to unsubscribe
|
||||
from the
|
||||
.BR bounces
|
||||
list and re-subscribe to the list of their choice.
|
||||
.LP
|
||||
.B bounce
|
||||
can also be used to expire addresses off the
|
||||
.BR bounces
|
||||
list after a predetermined number of days.
|
||||
.LP
|
||||
If
|
||||
.B bounce
|
||||
is invoked under a name that contains ``unsub'' it will simply
|
||||
unsubscribe the offending address from the majordomo list; it
|
||||
will not place the address on the
|
||||
.BR bounces
|
||||
list.
|
||||
.LP
|
||||
.SH OPTIONS
|
||||
These options relate to
|
||||
.B bounce; bounce-remind
|
||||
takes no arguments or options.
|
||||
.LP
|
||||
.TP 10
|
||||
.B \-d
|
||||
Debug; print what would be done, but don't do it.
|
||||
.TP
|
||||
.B \-f config-file
|
||||
Use the specified configuration file. The default is
|
||||
.BR ~/.majordomo,
|
||||
and the format for this file is described in the
|
||||
.BR CONFIGURATION
|
||||
section of the
|
||||
.BR approve (1)
|
||||
man page. This file provides the list-owner's password for
|
||||
each list and the address of the corresponding Majordomo
|
||||
server.
|
||||
.TP
|
||||
.B \-majordomo server-address
|
||||
Use this
|
||||
.IR server-address
|
||||
for majordomo rather than the address from the configuration file.
|
||||
.TP
|
||||
.B \-unsub
|
||||
Unsubscribes the offending address from the majordomo list,
|
||||
without entering that address on the
|
||||
.BR bounces
|
||||
list. This is equivalent to invoking
|
||||
.BR bounce
|
||||
under a name containing ``unsub''.
|
||||
.TP
|
||||
.B \-expire
|
||||
Expire entries from the specified
|
||||
.BR bounces
|
||||
list.
|
||||
.TP
|
||||
.B \-maxage days
|
||||
Expire entries older than
|
||||
.BI days.
|
||||
The default is coded into the
|
||||
.BR bounce
|
||||
script as
|
||||
.BI $default_maxage
|
||||
days. It is set to 21 days in the majordomo distribution.
|
||||
.LP
|
||||
.SH OPERANDS
|
||||
.TP 10
|
||||
.B majordomo-list
|
||||
The list from which the offending user-address should be removed.
|
||||
.TP
|
||||
.B user-address
|
||||
The address to which mail is currently undeliverable.
|
||||
.TP
|
||||
.B bounce-address-file
|
||||
The name of the file that contains the
|
||||
.BR bounces
|
||||
list.
|
||||
.LP
|
||||
.SH CONFIGURATION
|
||||
If
|
||||
.B bounce
|
||||
is going to be used only to unsubscribe users, a link can be
|
||||
created whose name contains ``unsub'' so that users could be
|
||||
unsubscribed simply by typing
|
||||
.sp 1
|
||||
.RS 3
|
||||
unsub firewalls-digest fury@world.std.com
|
||||
.RE
|
||||
.sp 1
|
||||
for example.
|
||||
.LP
|
||||
In any case, a configuration file must exist and must contain
|
||||
the names of the owner's lists, along with their respective
|
||||
passwords and the email address of the associated Majordomo
|
||||
server. The format of this file is given in the
|
||||
.B CONFIGURATION
|
||||
section of the
|
||||
.BR approve (1)
|
||||
man page. The default name for this file is
|
||||
.BR ~/.majordomo,
|
||||
and the same file can serve for both the
|
||||
.B approve
|
||||
and
|
||||
.B bounce
|
||||
scripts.
|
||||
.LP
|
||||
The
|
||||
.B bounces
|
||||
list, if it is used, must be created. It is like any other
|
||||
Majordomo list excepting that the priority of this list
|
||||
should be set to
|
||||
.B junk
|
||||
and its owner and sender should be
|
||||
.B nobody.
|
||||
Of course, the ``nobody'' mail alias must exist; it is should
|
||||
be set to /dev/null. That is,
|
||||
.sp 1
|
||||
.RS 3
|
||||
nobody: /dev/null
|
||||
.RE
|
||||
.sp 1
|
||||
This will spare the human list owner as well as the postmaster
|
||||
from having to deal with mail bouncing from the
|
||||
.B bounces
|
||||
list.
|
||||
.LP
|
||||
A
|
||||
.BR cron (1M)
|
||||
job should be set up to run
|
||||
.B bounce-remind
|
||||
every night.
|
||||
.B bounce-remind
|
||||
must run on the same server as the
|
||||
.B bounces
|
||||
list; it mails a message to everyone on the list advising
|
||||
them that they have been removed from one or more Majordomo
|
||||
lists and instructs them how to get off the
|
||||
.B bounces
|
||||
list and back on the list of their choice.
|
||||
.LP
|
||||
.B bounce
|
||||
can only expire addresses if it has a copy of the
|
||||
.B bounces
|
||||
subscriber file, so this can either be run on the server
|
||||
occasionally by the Majordomo administrator or by a cron
|
||||
job. It can also be run remotely with a copy of the
|
||||
.B bounces
|
||||
file retrived by the use of the ``who bounces'' command
|
||||
to majordomo.
|
||||
.LP
|
||||
.SH FILES
|
||||
.PD 0
|
||||
.TP 20
|
||||
.B /etc/aliases
|
||||
.TP
|
||||
.B /etc/majordomo.cf
|
||||
.PD
|
||||
.LP
|
||||
.SH SEE ALSO
|
||||
.B majordomo(8),approve(1)
|
||||
.LP
|
||||
.SH AUTHOR
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman <brent@GreatCircle.COM>.
|
||||
Majordomo is available via anonymous FTP
|
||||
from FTP.GreatCircle.COM, in the directory pub/majordomo. This
|
||||
man page was written by Kevin Kelleher <fury@world.std.com>.
|
||||
198
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce.man
vendored
Normal file
198
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/bounce.man
vendored
Normal file
@@ -0,0 +1,198 @@
|
||||
|
||||
|
||||
|
||||
bbbboooouuuunnnncccceeee((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV bbbboooouuuunnnncccceeee((((1111))))
|
||||
|
||||
|
||||
|
||||
NNNNAAAAMMMMEEEE
|
||||
bounce, bounce-remind - handle majordomo list subscribers
|
||||
whose mail is undeliverable
|
||||
|
||||
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
|
||||
bbbboooouuuunnnncccceeee [[[[----dddd]]]] [[[[----ffff _c_o_n_f_i_g-_f_i_l_e ]]]] [[[[----mmmmaaaajjjjoooorrrrddddoooommmmoooo _s_e_r_v_e_r-_a_d_d_r_e_s_s ]]]]
|
||||
[[[[----uuuunnnnssssuuuubbbb]]]] _m_a_j_o_r_d_o_m_o-_l_i_s_t _u_s_e_r-_a_d_d_r_e_s_s
|
||||
|
||||
bbbboooouuuunnnncccceeee [[[[----dddd]]]] [[[[----ffff _c_o_n_f_i_g-_f_i_l_e ]]]] [[[[----mmmmaaaajjjjoooorrrrddddoooommmmoooo _s_e_r_v_e_r-_a_d_d_r_e_s_s ]]]]
|
||||
----eeeexxxxppppiiiirrrreeee [[[[----mmmmaaaaxxxxaaaaggggeeee _d_a_y_s ]]]] _b_o_u_n_c_e-_a_d_d_r_e_s_s-_f_i_l_e
|
||||
|
||||
bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd
|
||||
|
||||
AAAAVVVVAAAAIIIILLLLAAAABBBBIIIILLLLIIIITTTTYYYY
|
||||
Provided with distributions of Majordomo.
|
||||
|
||||
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
|
||||
bbbboooouuuunnnncccceeee and bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd are perl scripts which help list
|
||||
owners handle subscribers whose mail is bouncing. Mail is
|
||||
"bounced" in this context when it is undeliverable because
|
||||
hosts or addresses are unreachable or because of other mail
|
||||
errors.
|
||||
|
||||
Mail is also "bounced" by the resend script for various
|
||||
administrative reasons; these bounces are described in
|
||||
aaaapppppppprrrroooovvvveeee(1).
|
||||
|
||||
When a list owner observes that an email address
|
||||
consistently causes mail errors, the owner may use bbbboooouuuunnnncccceeee to
|
||||
remove the address from the list and place the address on a
|
||||
special bbbboooouuuunnnncccceeeessss mailing list.
|
||||
|
||||
bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd,,,, which should be run nightly by ccccrrrroooonnnn(4M),
|
||||
sends a message to each of the user addresses on the bbbboooouuuunnnncccceeeessss
|
||||
list, on the chance that the mail error has been corrected.
|
||||
The message informs the addressee that their mail has been
|
||||
undeliverable and that they have been removed from one or
|
||||
more majordomo lists. It also instructs them how to
|
||||
unsubscribe from the bbbboooouuuunnnncccceeeessss list and re-subscribe to the
|
||||
list of their choice.
|
||||
|
||||
bbbboooouuuunnnncccceeee can also be used to expire addresses off the bbbboooouuuunnnncccceeeessss
|
||||
list after a predetermined number of days.
|
||||
|
||||
If bbbboooouuuunnnncccceeee is invoked under a name that contains ``unsub'' it
|
||||
will simply unsubscribe the offending address from the
|
||||
majordomo list; it will not place the address on the bbbboooouuuunnnncccceeeessss
|
||||
list.
|
||||
|
||||
OOOOPPPPTTTTIIIIOOOONNNNSSSS
|
||||
These options relate to bbbboooouuuunnnncccceeee;;;; bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd takes no
|
||||
arguments or options.
|
||||
|
||||
|
||||
|
||||
Page 1 (printed 9/24/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
bbbboooouuuunnnncccceeee((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV bbbboooouuuunnnncccceeee((((1111))))
|
||||
|
||||
|
||||
|
||||
----dddd Debug; print what would be done, but don't do it.
|
||||
|
||||
----ffff ccccoooonnnnffffiiiigggg----ffffiiiilllleeee
|
||||
Use the specified configuration file. The default
|
||||
is ~~~~////....mmmmaaaajjjjoooorrrrddddoooommmmoooo,,,, and the format for this file is
|
||||
described in the CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN section of the
|
||||
aaaapppppppprrrroooovvvveeee(1) man page. This file provides the
|
||||
list-owner's password for each list and the
|
||||
address of the corresponding Majordomo server.
|
||||
|
||||
----mmmmaaaajjjjoooorrrrddddoooommmmoooo sssseeeerrrrvvvveeeerrrr----aaaaddddddddrrrreeeessssssss
|
||||
Use this _s_e_r_v_e_r-_a_d_d_r_e_s_s for majordomo rather than
|
||||
the address from the configuration file.
|
||||
|
||||
----uuuunnnnssssuuuubbbb Unsubscribes the offending address from the
|
||||
majordomo list, without entering that address on
|
||||
the bbbboooouuuunnnncccceeeessss list. This is equivalent to invoking
|
||||
bbbboooouuuunnnncccceeee under a name containing ``unsub''.
|
||||
|
||||
----eeeexxxxppppiiiirrrreeee Expire entries from the specified bbbboooouuuunnnncccceeeessss list.
|
||||
|
||||
----mmmmaaaaxxxxaaaaggggeeee ddddaaaayyyyssss
|
||||
Expire entries older than ddddaaaayyyyssss.... The default is
|
||||
coded into the bbbboooouuuunnnncccceeee script as $$$$ddddeeeeffffaaaauuuulllltttt____mmmmaaaaxxxxaaaaggggeeee
|
||||
days. It is set to 21 days in the majordomo
|
||||
distribution.
|
||||
|
||||
OOOOPPPPEEEERRRRAAAANNNNDDDDSSSS
|
||||
mmmmaaaajjjjoooorrrrddddoooommmmoooo----lllliiiisssstttt
|
||||
The list from which the offending user-address
|
||||
should be removed.
|
||||
|
||||
uuuusssseeeerrrr----aaaaddddddddrrrreeeessssssss
|
||||
The address to which mail is currently
|
||||
undeliverable.
|
||||
|
||||
bbbboooouuuunnnncccceeee----aaaaddddddddrrrreeeessssssss----ffffiiiilllleeee
|
||||
The name of the file that contains the bbbboooouuuunnnncccceeeessss
|
||||
list.
|
||||
|
||||
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
|
||||
If bbbboooouuuunnnncccceeee is going to be used only to unsubscribe users, a
|
||||
link can be created whose name contains ``unsub'' so that
|
||||
users could be unsubscribed simply by typing
|
||||
|
||||
unsub firewalls-digest fury@world.std.com
|
||||
|
||||
for example.
|
||||
|
||||
In any case, a configuration file must exist and must
|
||||
contain the names of the owner's lists, along with their
|
||||
respective passwords and the email address of the associated
|
||||
|
||||
|
||||
|
||||
Page 2 (printed 9/24/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
bbbboooouuuunnnncccceeee((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV bbbboooouuuunnnncccceeee((((1111))))
|
||||
|
||||
|
||||
|
||||
Majordomo server. The format of this file is given in the
|
||||
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN section of the aaaapppppppprrrroooovvvveeee(1) man page. The
|
||||
default name for this file is ~~~~////....mmmmaaaajjjjoooorrrrddddoooommmmoooo,,,, and the same
|
||||
file can serve for both the aaaapppppppprrrroooovvvveeee and bbbboooouuuunnnncccceeee scripts.
|
||||
|
||||
The bbbboooouuuunnnncccceeeessss list, if it is used, must be created. It is
|
||||
like any other Majordomo list excepting that the priority of
|
||||
this list should be set to jjjjuuuunnnnkkkk and its owner and sender
|
||||
should be nnnnoooobbbbooooddddyyyy.... Of course, the ``nobody'' mail alias must
|
||||
exist; it is should be set to /dev/null. That is,
|
||||
|
||||
nobody: /dev/null
|
||||
|
||||
This will spare the human list owner as well as the
|
||||
postmaster from having to deal with mail bouncing from the
|
||||
bbbboooouuuunnnncccceeeessss list.
|
||||
|
||||
A ccccrrrroooonnnn(1M) job should be set up to run bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd every
|
||||
night. bbbboooouuuunnnncccceeee----rrrreeeemmmmiiiinnnndddd must run on the same server as the
|
||||
bbbboooouuuunnnncccceeeessss list; it mails a message to everyone on the list
|
||||
advising them that they have been removed from one or more
|
||||
Majordomo lists and instructs them how to get off the
|
||||
bbbboooouuuunnnncccceeeessss list and back on the list of their choice.
|
||||
|
||||
bbbboooouuuunnnncccceeee can only expire addresses if it has a copy of the
|
||||
bbbboooouuuunnnncccceeeessss subscriber file, so this can either be run on the
|
||||
server occasionally by the Majordomo administrator or by a
|
||||
cron job. It can also be run remotely with a copy of the
|
||||
bbbboooouuuunnnncccceeeessss file retrived by the use of the ``who bounces''
|
||||
command to majordomo.
|
||||
|
||||
FFFFIIIILLLLEEEESSSS
|
||||
////eeeettttcccc////aaaalllliiiiaaaasssseeeessss
|
||||
////eeeettttcccc////mmmmaaaajjjjoooorrrrddddoooommmmoooo....ccccffff
|
||||
|
||||
SSSSEEEEEEEE AAAALLLLSSSSOOOO
|
||||
mmmmaaaajjjjoooorrrrddddoooommmmoooo((((8888)))),,,,aaaapppppppprrrroooovvvveeee((((1111))))
|
||||
|
||||
AAAAUUUUTTTTHHHHOOOORRRR
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman <brent@GreatCircle.COM>. Majordomo is
|
||||
available via anonymous FTP from FTP.GreatCircle.COM, in the
|
||||
directory pub/majordomo. This man page was written by Kevin
|
||||
Kelleher <fury@world.std.com>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Page 3 (printed 9/24/96)
|
||||
|
||||
|
||||
|
||||
357
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/digest.1
vendored
Normal file
357
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/digest.1
vendored
Normal file
@@ -0,0 +1,357 @@
|
||||
.TH digest 1
|
||||
.SH NAME
|
||||
digest \- receive a file for a digest, or create and mail a digest
|
||||
.LP
|
||||
.SH SYNOPSIS
|
||||
.B digest \-r|R|m|p \-C \-l
|
||||
.I majordomo-listname recipient
|
||||
.LP
|
||||
.B digest \-r|R|m|p
|
||||
[
|
||||
.B \-c
|
||||
.I configuration-file
|
||||
]
|
||||
.LP
|
||||
.SH AVAILABILITY
|
||||
Provided with distributions of Majordomo.
|
||||
.LP
|
||||
.SH DESCRIPTION
|
||||
The digest script is a perl script which automates the
|
||||
management of digests of electronic mail. It can be
|
||||
run in a standalone configuration or as part of Majordomo.
|
||||
.LP
|
||||
It requires two directories: a work directory and an
|
||||
archive directory. Incoming email messages are held
|
||||
in the work directory until they are collected into a
|
||||
digest. The digests are created and stored
|
||||
in the archive directory.
|
||||
.LP
|
||||
Incoming email messages are given
|
||||
numerical names starting with ``001'' and are numbered in
|
||||
order of arrival. The digests are named according to volume
|
||||
and number. For example, the filename ``v01.n028'' indicates
|
||||
volume 1, number 28 of the digest.
|
||||
.LP
|
||||
It should be noted that digest needs a configuration file
|
||||
to define all of its operating parameters. If no such
|
||||
file is specified, digest will use the
|
||||
.SB $HOME/.digestrc
|
||||
file.
|
||||
.LP
|
||||
Several aspects of digest configuration determine how and
|
||||
when a digest is created. A digest can be created at
|
||||
regular intervals (as long as there are incoming messages)
|
||||
or whenever certain configurable conditions are met. These
|
||||
conditions are: how large the digest can be (in characters),
|
||||
how long the digest can be (in lines), and how old the messages
|
||||
in the digest can be (in days).
|
||||
.LP
|
||||
.SH OPTIONS
|
||||
.TP 10
|
||||
.B \-r
|
||||
Receive an email message via standard input
|
||||
and place the file into the working directory.
|
||||
If any one of the conditions for digest creation
|
||||
are met, create and mail a digest. These conditions
|
||||
are the same as those described under option
|
||||
.BR \-p.
|
||||
.TP
|
||||
.B \-R
|
||||
Similar to
|
||||
.BR \-r,
|
||||
except that it will not create a digest. It simply
|
||||
places the message in the work directory and stops.
|
||||
.TP
|
||||
.B \-m
|
||||
If there are any numbered files in the working
|
||||
directory, create and mail a digest. Store the
|
||||
digest in the archive directory. This is the
|
||||
option used by majordomo's mkdigest command.
|
||||
.TP
|
||||
.B \-p
|
||||
Conditionally creates a digest. If any one of the
|
||||
conditions for digest creation are met, the digest
|
||||
is created and sent. There are three conditions,
|
||||
which are connected to three limits: the digest
|
||||
size in characters, the digest length in lines, and
|
||||
the age of the oldest message in days. If one of the
|
||||
files is older than the age limit, a digest is created.
|
||||
If the sum of the messages exceeds either of the size
|
||||
limits, a digest is created. The size limit in characters
|
||||
must be configured; the other two limits are optional.
|
||||
.TP
|
||||
.B \-c configuration-file
|
||||
Use the parameters defined in
|
||||
.IR configuration-file.
|
||||
.TP
|
||||
.B \-C
|
||||
Read the majordomo configuration file
|
||||
(either /etc/majordomo.cf or ~majordomo/majordomo.cf)
|
||||
and the configuration file for the Majordomo list specified in the
|
||||
.BR \-l
|
||||
option to define operational parameters. If both
|
||||
.BR \-C
|
||||
and
|
||||
.BR \-c
|
||||
options are specified (not recommended) only the
|
||||
.BR \-C
|
||||
option will be used.
|
||||
.TP
|
||||
.B \-l majordomo-listname
|
||||
This option is ignored if used without the
|
||||
.BR \-C
|
||||
option. Specifies the Majordomo email list.
|
||||
.LP
|
||||
.SH OPERANDS
|
||||
.TP 10
|
||||
.B recipient
|
||||
Email recipient of the digest. This operand is ignored if used
|
||||
without the
|
||||
.BR \-C
|
||||
option. It specifies one of the system mail
|
||||
aliases created for the Majordomo list named in the
|
||||
.BR \-l
|
||||
option.
|
||||
.LP
|
||||
.SH MAJORDOMO DIGEST CONFIGURATION
|
||||
When used as a part of Majordomo, digest takes these parameters
|
||||
from
|
||||
.B majordomo.cf
|
||||
(either /etc/majordomo.cf or ~majordomo/majordomo.cf):
|
||||
.LP
|
||||
.PD 0
|
||||
.B $listdir
|
||||
\- the location of the mailing lists
|
||||
.LP
|
||||
.B $digest_work_dir
|
||||
\- parent directory for the digests' work directories
|
||||
.LP
|
||||
.B $filedir
|
||||
\- parent directory for archive directories
|
||||
.LP
|
||||
.B $filedir_suffix
|
||||
\- an optional identifier (may be the null string)
|
||||
.PD
|
||||
.LP
|
||||
Incoming messages for
|
||||
.B $listname-digest
|
||||
will be held in
|
||||
.B $digest_work_dir/$listname-digest.
|
||||
.LP
|
||||
Digests will be stored in
|
||||
.B $filedir/$listname-digest$filedir_suffix.
|
||||
.LP
|
||||
The list's configuration file will be
|
||||
.B $listdir/$listname-digest.config.
|
||||
.LP
|
||||
Examples of these values are given in
|
||||
.SB EXAMPLES,
|
||||
below.
|
||||
.LP
|
||||
The list's configuration file contains several digest parameters that
|
||||
are not yet implemented and/or should NOT be changed from their defaults
|
||||
(blank):
|
||||
.B digest_archive, digest_rm_footer, digest_rm_fronter, digest_work_dir.
|
||||
.LP
|
||||
The parameters which specifically deal with digest creation
|
||||
and maintenance are:
|
||||
.LP
|
||||
.PD 0
|
||||
.B digest_name
|
||||
\- the title of the digest
|
||||
.LP
|
||||
.B digest_volume
|
||||
\- volume number
|
||||
.LP
|
||||
.B digest_issue
|
||||
\- issue number
|
||||
.LP
|
||||
.B digest_maxdays
|
||||
\- age limit in days for oldest message in the digest
|
||||
.LP
|
||||
.B digest_maxlines
|
||||
\- maximum number of lines in a digest
|
||||
.LP
|
||||
.B maxlength
|
||||
\- maximum number of characters in a digest
|
||||
.LP
|
||||
.B message_fronter
|
||||
\- text prepended to the digest
|
||||
.LP
|
||||
.B message_footer
|
||||
\- text appended to the digest
|
||||
.PD
|
||||
.LP
|
||||
The last three parameters are also used in the configuration of
|
||||
an ordinary (non-digest) Majordomo list.
|
||||
.LP
|
||||
Each digest begins with the a line containing the
|
||||
.B digest_name, current date, digest_volume and digest_issue.
|
||||
. The digest script will update the issue number in the configuration file.
|
||||
.LP
|
||||
A blank line follows, and then the text from the
|
||||
.B message_fronter,
|
||||
if any. The message fronter may contain the
|
||||
.SB _SUBJECT_
|
||||
token, which will be replaced by the subject lines from the messages
|
||||
in the digest.
|
||||
.LP
|
||||
The text in the
|
||||
.B message_footer,
|
||||
if any, will be appended to the digest.
|
||||
.LP
|
||||
To embed a blank line in the
|
||||
.B message_footer
|
||||
or
|
||||
.B message_fronter,
|
||||
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.
|
||||
.LP
|
||||
Both message_footer and message_fronter may also use the tokens
|
||||
.SB $LIST, $SENDER,
|
||||
and
|
||||
.SB $VERSION,
|
||||
which will be expanded to,
|
||||
respectively: the name of the current list, the sender as taken
|
||||
from the from line, and the current version of Majordomo.
|
||||
.LP
|
||||
Examples of the aliases usually used with the digest are
|
||||
given in
|
||||
.SB EXAMPLES,
|
||||
below.
|
||||
.LP
|
||||
The list owner can prompt Majordomo to build a digest by
|
||||
sending the command
|
||||
.LP
|
||||
mkdigest
|
||||
.I digest-name
|
||||
[
|
||||
.I outgoing-address
|
||||
]
|
||||
.I digest-password
|
||||
.LP
|
||||
to majordomo either via email or from cron. The cron
|
||||
command has the format:
|
||||
.LP
|
||||
echo mkdigest
|
||||
.I digest-name
|
||||
[
|
||||
.I outgoing-address
|
||||
]
|
||||
.I digest-password
|
||||
| mail majordomo@domain.com
|
||||
.LP
|
||||
.SH STANDALONE DIGEST CONFIGURATION
|
||||
The Majordomo distribution comes with a ``digest'' subdirectory.
|
||||
The sample configuration file is called firewalls-digest.cf.
|
||||
A file in this format must be used if digest is invoked in
|
||||
standalone configuration.
|
||||
.LP
|
||||
If no configuration file is specified when digest is invoked,
|
||||
it looks for a file named
|
||||
.SB $HOME/.digestrc
|
||||
that must be in the same format as the example file.
|
||||
.LP
|
||||
The configuration file defines the email addresses of the
|
||||
sender and recipient of the digest. It also locates the
|
||||
work and archive directories, the digest's size limit,
|
||||
and the names of the files that contain the digest's volume,
|
||||
number, header and footer.
|
||||
.LP
|
||||
The easiest way to configure a standalone digest is to copy
|
||||
the five files (firewalls-digest.*) and edit them to taste.
|
||||
.LP
|
||||
Incoming mail is piped to digest with the
|
||||
.B \-r
|
||||
option. This can be done from some mail-reading programs, through
|
||||
the command line, or via mail aliases similar to those
|
||||
found in
|
||||
.SB EXAMPLES,
|
||||
below.
|
||||
.LP
|
||||
.SH EXAMPLES
|
||||
.LP
|
||||
1. Example values from
|
||||
.B /etc/majordomo.cf:
|
||||
.LP
|
||||
.PD 0
|
||||
.B $listdir = ``usr/local/mail/lists'';
|
||||
.LP
|
||||
.B $digest_work_dir = ``usr/local/mail/digest'';
|
||||
.LP
|
||||
.B $filedir = ``listdir'';
|
||||
.LP
|
||||
.B $filedir_suffix ``archive'';
|
||||
.PD
|
||||
.LP
|
||||
If our digest's name is banjo-digest, the work directory will
|
||||
be /usr/local/mail/digest/banjo-digest; the archive directory
|
||||
will be /usr/local/mail/lists/banjo-digest.archive. Note
|
||||
that these are names of directories, not files.
|
||||
.LP
|
||||
2. Typical aliases for Majordomo digests:
|
||||
.LP
|
||||
Usually a Majordomo digest is associated to a regular (non-digest)
|
||||
list. The digest's name is the regular listname plus ``-digest''.
|
||||
The list ``banjo'' will have the digest ``banjo-digest''.
|
||||
.LP
|
||||
.PD 0
|
||||
.B banjo-digest-approval: kevink
|
||||
.LP
|
||||
.B banjo-digest-outgoing: :include:/usr/local/lists/banjo-digest
|
||||
.LP
|
||||
.B owner-banjo-digest-outgoing: kevink
|
||||
.LP
|
||||
.B banjo-digestify: ``|usr/majordomo/wrapper digest \-r
|
||||
.B \-C \-l banjo-digest banjo-digest-outgoing''
|
||||
.LP
|
||||
.B banjo-digest: banjo
|
||||
.PD
|
||||
.LP
|
||||
Note that mail to ``banjo-digest'' is routed to the regular list.
|
||||
The ``digestify'' alias must be added to the regular list's outgoing
|
||||
alias:
|
||||
.LP
|
||||
.B banjo-outgoing: :include:/usr/local/lists/banjo,banjo-digestify
|
||||
.LP
|
||||
.SH NOTES
|
||||
The volume number does not change automatically; it must be
|
||||
incremented manually.
|
||||
.LP
|
||||
For testing/debugging purposes there is a ``hidden'' option
|
||||
.B -d
|
||||
that creates the digest as /tmp/testdigest.nnn
|
||||
(where
|
||||
.I nnn
|
||||
is the current digest number). Since it is for testing and
|
||||
debugging purposes, it does not mail the digest, it does not
|
||||
place the digest in the archive directory, and it does not
|
||||
update the digest number.
|
||||
.LP
|
||||
.SH EXIT STATUS
|
||||
The following exit values are returned:
|
||||
.TP 10
|
||||
.B 0
|
||||
Successful completion.
|
||||
.TP
|
||||
.B >0
|
||||
An error occurred.
|
||||
.LP
|
||||
.SH FILES
|
||||
.PD 0
|
||||
.TP 20
|
||||
.B /etc/aliases
|
||||
.TP
|
||||
.B /etc/majordomo.cf
|
||||
.PD
|
||||
.LP
|
||||
.SH SEE ALSO
|
||||
.B majordomo(8)
|
||||
.LP
|
||||
.SH AUTHOR
|
||||
The digest script was written by Brent Chapman <brent@GreatCircle.COM>.
|
||||
It is available with distributions of Majordomo via anonymous FTP
|
||||
from FTP.GreatCircle.COM, in the directory pub/majordomo. This
|
||||
man page was written by Kevin Kelleher <fury@world.std.com>.
|
||||
396
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/digest.man
vendored
Normal file
396
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/digest.man
vendored
Normal file
@@ -0,0 +1,396 @@
|
||||
|
||||
|
||||
|
||||
ddddiiiiggggeeeesssstttt((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ddddiiiiggggeeeesssstttt((((1111))))
|
||||
|
||||
|
||||
|
||||
NNNNAAAAMMMMEEEE
|
||||
digest - receive a file for a digest, or create and mail a
|
||||
digest
|
||||
|
||||
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
|
||||
ddddiiiiggggeeeesssstttt ----rrrr||||RRRR||||mmmm||||pppp ----CCCC ----llll _m_a_j_o_r_d_o_m_o-_l_i_s_t_n_a_m_e _r_e_c_i_p_i_e_n_t
|
||||
|
||||
ddddiiiiggggeeeesssstttt ----rrrr||||RRRR||||mmmm||||pppp [ ----cccc _c_o_n_f_i_g_u_r_a_t_i_o_n-_f_i_l_e ]
|
||||
|
||||
AAAAVVVVAAAAIIIILLLLAAAABBBBIIIILLLLIIIITTTTYYYY
|
||||
Provided with distributions of Majordomo.
|
||||
|
||||
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
|
||||
The digest script is a perl script which automates the
|
||||
management of digests of electronic mail. It can be run in
|
||||
a standalone configuration or as part of Majordomo.
|
||||
|
||||
It requires two directories: a work directory and an archive
|
||||
directory. Incoming email messages are held in the work
|
||||
directory until they are collected into a digest. The
|
||||
digests are created and stored in the archive directory.
|
||||
|
||||
Incoming email messages are given numerical names starting
|
||||
with ``001'' and are numbered in order of arrival. The
|
||||
digests are named according to volume and number. For
|
||||
example, the filename ``v01.n028'' indicates volume 1,
|
||||
number 28 of the digest.
|
||||
|
||||
It should be noted that digest needs a configuration file to
|
||||
define all of its operating parameters. If no such file is
|
||||
specified, digest will use the file.
|
||||
|
||||
Several aspects of digest configuration determine how and
|
||||
when a digest is created. A digest can be created at
|
||||
regular intervals (as long as there are incoming messages)
|
||||
or whenever certain configurable conditions are met. These
|
||||
conditions are: how large the digest can be (in
|
||||
characters), how long the digest can be (in lines), and how
|
||||
old the messages in the digest can be (in days).
|
||||
|
||||
OOOOPPPPTTTTIIIIOOOONNNNSSSS
|
||||
----rrrr Receive an email message via standard input and
|
||||
place the file into the working directory. If any
|
||||
one of the conditions for digest creation are met,
|
||||
create and mail a digest. These conditions are
|
||||
the same as those described under option ----pppp....
|
||||
|
||||
----RRRR Similar to ----rrrr,,,, except that it will not create a
|
||||
digest. It simply places the message in the work
|
||||
directory and stops.
|
||||
|
||||
----mmmm If there are any numbered files in the working
|
||||
|
||||
|
||||
|
||||
Page 1 (printed 9/23/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ddddiiiiggggeeeesssstttt((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ddddiiiiggggeeeesssstttt((((1111))))
|
||||
|
||||
|
||||
|
||||
directory, create and mail a digest. Store the
|
||||
digest in the archive directory. This is the
|
||||
option used by majordomo's mkdigest command.
|
||||
|
||||
----pppp Conditionally creates a digest. If any one of the
|
||||
conditions for digest creation are met, the digest
|
||||
is created and sent. There are three conditions,
|
||||
which are connected to three limits: the digest
|
||||
size in characters, the digest length in lines,
|
||||
and the age of the oldest message in days. If one
|
||||
of the files is older than the age limit, a digest
|
||||
is created. If the sum of the messages exceeds
|
||||
either of the size limits, a digest is created.
|
||||
The size limit in characters must be configured;
|
||||
the other two limits are optional.
|
||||
|
||||
----cccc ccccoooonnnnffffiiiigggguuuurrrraaaattttiiiioooonnnn----ffffiiiilllleeee
|
||||
Use the parameters defined in _c_o_n_f_i_g_u_r_a_t_i_o_n-_f_i_l_e.
|
||||
|
||||
----CCCC Read the majordomo configuration file (either
|
||||
/etc/majordomo.cf or ~majordomo/majordomo.cf) and
|
||||
the configuration file for the Majordomo list
|
||||
specified in the ----llll option to define operational
|
||||
parameters. If both ----CCCC and ----cccc options are
|
||||
specified (not recommended) only the ----CCCC option
|
||||
will be used.
|
||||
|
||||
----llll mmmmaaaajjjjoooorrrrddddoooommmmoooo----lllliiiissssttttnnnnaaaammmmeeee
|
||||
This option is ignored if used without the ----CCCC
|
||||
option. Specifies the Majordomo email list.
|
||||
|
||||
OOOOPPPPEEEERRRRAAAANNNNDDDDSSSS
|
||||
rrrreeeecccciiiippppiiiieeeennnntttt Email recipient of the digest. This operand is
|
||||
ignored if used without the ----CCCC option. It
|
||||
specifies one of the system mail aliases created
|
||||
for the Majordomo list named in the ----llll option.
|
||||
|
||||
MMMMAAAAJJJJOOOORRRRDDDDOOOOMMMMOOOO DDDDIIIIGGGGEEEESSSSTTTT CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
|
||||
When used as a part of Majordomo, digest takes these
|
||||
parameters from mmmmaaaajjjjoooorrrrddddoooommmmoooo....ccccffff (either /etc/majordomo.cf or
|
||||
~majordomo/majordomo.cf):
|
||||
|
||||
$$$$lllliiiissssttttddddiiiirrrr - the location of the mailing lists
|
||||
$$$$ddddiiiiggggeeeesssstttt____wwwwoooorrrrkkkk____ddddiiiirrrr - parent directory for the digests' work
|
||||
directories
|
||||
$$$$ffffiiiilllleeeeddddiiiirrrr - parent directory for archive directories
|
||||
$$$$ffffiiiilllleeeeddddiiiirrrr____ssssuuuuffffffffiiiixxxx - an optional identifier (may be the null
|
||||
string)
|
||||
|
||||
Incoming messages for $$$$lllliiiissssttttnnnnaaaammmmeeee----ddddiiiiggggeeeesssstttt will be held in
|
||||
$$$$ddddiiiiggggeeeesssstttt____wwwwoooorrrrkkkk____ddddiiiirrrr////$$$$lllliiiissssttttnnnnaaaammmmeeee----ddddiiiiggggeeeesssstttt....
|
||||
|
||||
|
||||
|
||||
|
||||
Page 2 (printed 9/23/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ddddiiiiggggeeeesssstttt((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ddddiiiiggggeeeesssstttt((((1111))))
|
||||
|
||||
|
||||
|
||||
Digests will be stored in $$$$ffffiiiilllleeeeddddiiiirrrr////$$$$lllliiiissssttttnnnnaaaammmmeeee----
|
||||
ddddiiiiggggeeeesssstttt$$$$ffffiiiilllleeeeddddiiiirrrr____ssssuuuuffffffffiiiixxxx....
|
||||
|
||||
The list's configuration file will be $$$$lllliiiissssttttddddiiiirrrr////$$$$lllliiiissssttttnnnnaaaammmmeeee----
|
||||
ddddiiiiggggeeeesssstttt....ccccoooonnnnffffiiiigggg....
|
||||
|
||||
Examples of these values are given in below.
|
||||
|
||||
The list's configuration file contains several digest
|
||||
parameters that are not yet implemented and/or should NOT be
|
||||
changed from their defaults (blank): ddddiiiiggggeeeesssstttt____aaaarrrrcccchhhhiiiivvvveeee,,,,
|
||||
ddddiiiiggggeeeesssstttt____rrrrmmmm____ffffooooooootttteeeerrrr,,,, ddddiiiiggggeeeesssstttt____rrrrmmmm____ffffrrrroooonnnntttteeeerrrr,,,, ddddiiiiggggeeeesssstttt____wwwwoooorrrrkkkk____ddddiiiirrrr....
|
||||
|
||||
The parameters which specifically deal with digest creation
|
||||
and maintenance are:
|
||||
|
||||
ddddiiiiggggeeeesssstttt____nnnnaaaammmmeeee - the title of the digest
|
||||
ddddiiiiggggeeeesssstttt____vvvvoooolllluuuummmmeeee - volume number
|
||||
ddddiiiiggggeeeesssstttt____iiiissssssssuuuueeee - issue number
|
||||
ddddiiiiggggeeeesssstttt____mmmmaaaaxxxxddddaaaayyyyssss - age limit in days for oldest message in the
|
||||
digest
|
||||
ddddiiiiggggeeeesssstttt____mmmmaaaaxxxxlllliiiinnnneeeessss - maximum number of lines in a digest
|
||||
mmmmaaaaxxxxlllleeeennnnggggtttthhhh - maximum number of characters in a digest
|
||||
mmmmeeeessssssssaaaaggggeeee____ffffrrrroooonnnntttteeeerrrr - text prepended to the digest
|
||||
mmmmeeeessssssssaaaaggggeeee____ffffooooooootttteeeerrrr - text appended to the digest
|
||||
|
||||
The last three parameters are also used in the configuration
|
||||
of an ordinary (non-digest) Majordomo list.
|
||||
|
||||
Each digest begins with the a line containing the
|
||||
ddddiiiiggggeeeesssstttt____nnnnaaaammmmeeee,,,, ccccuuuurrrrrrrreeeennnntttt ddddaaaatttteeee,,,, ddddiiiiggggeeeesssstttt____vvvvoooolllluuuummmmeeee aaaannnndddd ddddiiiiggggeeeesssstttt____iiiissssssssuuuueeee....
|
||||
|
||||
A blank line follows, and then the text from the
|
||||
mmmmeeeessssssssaaaaggggeeee____ffffrrrroooonnnntttteeeerrrr,,,, if any. The message fronter may contain
|
||||
the token, which will be replaced by the subject lines from
|
||||
the messages in the digest.
|
||||
|
||||
The text in the mmmmeeeessssssssaaaaggggeeee____ffffooooooootttteeeerrrr,,,, if any, will be appended to
|
||||
the digest.
|
||||
|
||||
To embed a blank line in the mmmmeeeessssssssaaaaggggeeee____ffffooooooootttteeeerrrr or
|
||||
mmmmeeeessssssssaaaaggggeeee____ffffrrrroooonnnntttteeeerrrr,,,, 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.
|
||||
|
||||
Both message_footer and message_fronter may also use the
|
||||
tokens and which will be expanded to, respectively: the name
|
||||
of the current list, the sender as taken from the from line,
|
||||
and the current version of Majordomo.
|
||||
|
||||
|
||||
|
||||
|
||||
Page 3 (printed 9/23/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ddddiiiiggggeeeesssstttt((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ddddiiiiggggeeeesssstttt((((1111))))
|
||||
|
||||
|
||||
|
||||
Examples of the aliases usually used with the digest are
|
||||
given in below.
|
||||
|
||||
The list owner can prompt Majordomo to build a digest by
|
||||
sending the command
|
||||
|
||||
mkdigest _d_i_g_e_s_t-_n_a_m_e [ _d_i_g_e_s_t-_p_a_s_s_w_o_r_d ]
|
||||
|
||||
to majordomo either via email or from cron. The cron
|
||||
command has the format:
|
||||
|
||||
echo mkdigest _d_i_g_e_s_t-_n_a_m_e [ _d_i_g_e_s_t-_p_a_s_s_w_o_r_d ] | mail
|
||||
majordomo@domain.com
|
||||
|
||||
SSSSTTTTAAAANNNNDDDDAAAALLLLOOOONNNNEEEE DDDDIIIIGGGGEEEESSSSTTTT CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
|
||||
The Majordomo distribution comes with a ``digest''
|
||||
subdirectory. The sample configuration file is called
|
||||
firewalls-digest.cf. A file in this format must be used if
|
||||
digest is invoked in standalone configuration.
|
||||
|
||||
If no configuration file is specified when digest is
|
||||
invoked, it looks for a file named that must be in the same
|
||||
format as the example file.
|
||||
|
||||
The configuration file defines the email addresses of the
|
||||
sender and recipient of the digest. It also locates the work
|
||||
and archive directories, the digest's size limit, and the
|
||||
names of the files that contain the digest's volume, number,
|
||||
header and footer.
|
||||
|
||||
The easiest way to configure a standalone digest is to copy
|
||||
the five files (firewalls-digest.*) and edit them to taste.
|
||||
|
||||
Incoming mail is piped to digest with the ----rrrr option. This
|
||||
can be done from some mail-reading programs, through the
|
||||
command line, or via mail aliases similar to those found in
|
||||
below.
|
||||
|
||||
EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
|
||||
1. Example values from ////eeeettttcccc////mmmmaaaajjjjoooorrrrddddoooommmmoooo....ccccffff::::
|
||||
|
||||
$$$$lllliiiissssttttddddiiiirrrr ==== ````````uuuussssrrrr////llllooooccccaaaallll////mmmmaaaaiiiillll////lllliiiissssttttssss'''''''';;;;
|
||||
$$$$ddddiiiiggggeeeesssstttt____wwwwoooorrrrkkkk____ddddiiiirrrr ==== ````````uuuussssrrrr////llllooooccccaaaallll////mmmmaaaaiiiillll////ddddiiiiggggeeeesssstttt'''''''';;;;
|
||||
$$$$ffffiiiilllleeeeddddiiiirrrr ==== ````````lllliiiissssttttddddiiiirrrr'''''''';;;;
|
||||
$$$$ffffiiiilllleeeeddddiiiirrrr____ssssuuuuffffffffiiiixxxx ````````aaaarrrrcccchhhhiiiivvvveeee'''''''';;;;
|
||||
|
||||
If our digest's name is banjo-digest, the work directory
|
||||
will be /usr/local/mail/digest/banjo-digest; the archive
|
||||
directory will be /usr/local/mail/lists/banjo-
|
||||
digest.archive. Note that these are names of directories,
|
||||
not files.
|
||||
|
||||
|
||||
|
||||
|
||||
Page 4 (printed 9/23/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ddddiiiiggggeeeesssstttt((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ddddiiiiggggeeeesssstttt((((1111))))
|
||||
|
||||
|
||||
|
||||
2. Typical aliases for Majordomo digests:
|
||||
|
||||
Usually a Majordomo digest is associated to a regular (non-
|
||||
digest) list. The digest's name is the regular listname
|
||||
plus ``-digest''. The list ``banjo'' will have the digest
|
||||
``banjo-digest''.
|
||||
|
||||
bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeesssstttt----aaaapppppppprrrroooovvvvaaaallll:::: kkkkeeeevvvviiiinnnnkkkk
|
||||
bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeesssstttt----oooouuuuttttggggooooiiiinnnngggg:::: ::::iiiinnnncccclllluuuuddddeeee::::////uuuussssrrrr////llllooooccccaaaallll////lllliiiissssttttssss////bbbbaaaannnnjjjjoooo----
|
||||
ddddiiiiggggeeeesssstttt
|
||||
oooowwwwnnnneeeerrrr----bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeesssstttt----oooouuuuttttggggooooiiiinnnngggg:::: kkkkeeeevvvviiiinnnnkkkk
|
||||
bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeessssttttiiiiffffyyyy:::: ````````||||uuuussssrrrr////mmmmaaaajjjjoooorrrrddddoooommmmoooo////wwwwrrrraaaappppppppeeeerrrr ddddiiiiggggeeeesssstttt ----rrrr ----CCCC ----llll
|
||||
bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeesssstttt bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeesssstttt----oooouuuuttttggggooooiiiinnnngggg''''''''
|
||||
bbbbaaaannnnjjjjoooo----ddddiiiiggggeeeesssstttt:::: bbbbaaaannnnjjjjoooo
|
||||
|
||||
Note that mail to ``banjo-digest'' is routed to the regular
|
||||
list. The ``digestify'' alias must be added to the regular
|
||||
list's outgoing alias:
|
||||
|
||||
bbbbaaaannnnjjjjoooo----oooouuuuttttggggooooiiiinnnngggg:::: ::::iiiinnnncccclllluuuuddddeeee::::////uuuussssrrrr////llllooooccccaaaallll////lllliiiissssttttssss////bbbbaaaannnnjjjjoooo,,,,bbbbaaaannnnjjjjoooo----
|
||||
ddddiiiiggggeeeessssttttiiiiffffyyyy
|
||||
|
||||
NNNNOOOOTTTTEEEESSSS
|
||||
The volume number does not change automatically; it must be
|
||||
incremented manually.
|
||||
|
||||
For testing/debugging purposes there is a ``hidden'' option
|
||||
----dddd that creates the digest as /tmp/testdigest.nnn (where _n_n_n
|
||||
is the current digest number). Since it is for testing and
|
||||
debugging purposes, it does not mail the digest, it does not
|
||||
place the digest in the archive directory, and it does not
|
||||
update the digest number.
|
||||
|
||||
EEEEXXXXIIIITTTT SSSSTTTTAAAATTTTUUUUSSSS
|
||||
The following exit values are returned:
|
||||
|
||||
0000 Successful completion.
|
||||
|
||||
>>>>0000 An error occurred.
|
||||
|
||||
FFFFIIIILLLLEEEESSSS
|
||||
////eeeettttcccc////aaaalllliiiiaaaasssseeeessss
|
||||
////eeeettttcccc////mmmmaaaajjjjoooorrrrddddoooommmmoooo....ccccffff
|
||||
|
||||
SSSSEEEEEEEE AAAALLLLSSSSOOOO
|
||||
mmmmaaaajjjjoooorrrrddddoooommmmoooo((((8888))))
|
||||
|
||||
AAAAUUUUTTTTHHHHOOOORRRR
|
||||
The digest script was written by Brent Chapman
|
||||
<brent@GreatCircle.COM>. It is available with distributions
|
||||
of Majordomo via anonymous FTP from FTP.GreatCircle.COM, in
|
||||
the directory pub/majordomo. This man page was written by
|
||||
|
||||
|
||||
|
||||
Page 5 (printed 9/23/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ddddiiiiggggeeeesssstttt((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ddddiiiiggggeeeesssstttt((((1111))))
|
||||
|
||||
|
||||
|
||||
Kevin Kelleher <fury@world.std.com>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Page 6 (printed 9/23/96)
|
||||
|
||||
|
||||
|
||||
300
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/majordomo.8
vendored
Normal file
300
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/majordomo.8
vendored
Normal file
@@ -0,0 +1,300 @@
|
||||
.TH MAJORDOMO 8
|
||||
.SH NAME
|
||||
Majordomo \- manage multiple mailing lists
|
||||
.SH SYNOPSIS
|
||||
.B Majordomo
|
||||
.SH "DESCRIPTION"
|
||||
.B Majordomo
|
||||
is a perl script which automates the management of Internet mailing lists.
|
||||
It is executed via electronic mail; users send e-mail to
|
||||
.B Majordomo
|
||||
with instructions in the body of the message, and the perl script performs
|
||||
the requested actions and responds with the results. Any text in the
|
||||
"Subject:" line is ignored.
|
||||
.SH "COMMANDS"
|
||||
.B Majordomo
|
||||
understands the following commands (arguments in "[]" are optional):
|
||||
.TP 5
|
||||
.B
|
||||
subscribe \fIlist\fR [\fIaddress\fR]
|
||||
.P
|
||||
Subscribe yourself (or
|
||||
.I address
|
||||
if specified) to the named
|
||||
.IR list .
|
||||
.TP 5
|
||||
.B
|
||||
unsubscribe \fIlist\fR [\fIaddress\fR]
|
||||
.P
|
||||
Unsubscribe yourself (or
|
||||
.I address
|
||||
if specified) from the named
|
||||
.IR list .
|
||||
If
|
||||
.IR list
|
||||
is ``*'' (an asterisk), unsubscribe from all lists on this Majordomo
|
||||
server.
|
||||
.TP 5
|
||||
.B
|
||||
auth \fIspecial-word\fP subscribe \fIlist address\fP
|
||||
.P
|
||||
If the
|
||||
.I list
|
||||
subscribe policy setting includes \fI+confirm\fR,
|
||||
Majordomo will ask for confirmation before a subscription
|
||||
is approved.
|
||||
The conformation request will show the
|
||||
.I special-word
|
||||
to send with
|
||||
.I auth .
|
||||
.TP 5
|
||||
.B
|
||||
get \fIlist\fR \fIfile\fR
|
||||
.P
|
||||
Get the
|
||||
.I file
|
||||
related to
|
||||
.IR list .
|
||||
.TP 5
|
||||
.B
|
||||
index \fIlist\fR
|
||||
.P
|
||||
Return an index of the files you can
|
||||
.I get
|
||||
associated with
|
||||
.IR list .
|
||||
.TP 5
|
||||
.B
|
||||
which [\fIaddress\fR]
|
||||
.P
|
||||
Find out to which lists you (or
|
||||
.I address
|
||||
if specified) are subscribed.
|
||||
.TP 5
|
||||
.B
|
||||
who \fIlist\fR
|
||||
.P
|
||||
Find out who is on the named
|
||||
.IR list .
|
||||
.TP 5
|
||||
.B
|
||||
info \fIlist\fR
|
||||
.P
|
||||
Retrieve the general introductory information for the named
|
||||
.IR list .
|
||||
.TP 5
|
||||
.B
|
||||
intro \fIlist\fR
|
||||
.P
|
||||
Retrieve the introductory message sent to new users
|
||||
of
|
||||
.IR list .
|
||||
Non-subscribers may not be able to retrieve this.
|
||||
.TP 5
|
||||
.B
|
||||
lists
|
||||
.P
|
||||
Show the lists served by this Majordomo server. It will also show a 50
|
||||
character list description if one has been provided.
|
||||
.TP 5
|
||||
.B
|
||||
help
|
||||
.P
|
||||
Retrieve an informational message, a brief synopsis of the user portion of
|
||||
this manual page.
|
||||
.TP 5
|
||||
.B
|
||||
end
|
||||
.P
|
||||
Stop processing commands (useful if your mailer adds a signature).
|
||||
.PP
|
||||
A command may be split across multiple lines if all of the lines in
|
||||
the command except the last end with a backslash "\\".
|
||||
.PP
|
||||
In addition, the owner of the list can issue the following commands:
|
||||
.TP 5
|
||||
.B
|
||||
approve \fIpassword\fR subscribe \fIlist\fR \fIaddress\fR
|
||||
.P
|
||||
Instruct Majordomo to add
|
||||
.I address
|
||||
to
|
||||
.IR list .
|
||||
The password is required to authenticate the list owner. This is very weak
|
||||
authentication as the password is transmitted in the clear in an e-mail
|
||||
message. No claims are made that it will provide anything other than
|
||||
rudimentary protection against abuse of the Majordomo server.
|
||||
.TP 5
|
||||
.B
|
||||
approve \fIpassword\fR unsubscribe \fIlist\fR \fIaddress\fR
|
||||
.P
|
||||
Instruct Majordomo to delete
|
||||
.I address
|
||||
from
|
||||
.IR list .
|
||||
The password is required to authenticate the list owner. See the comments
|
||||
above regarding the password.
|
||||
.TP 5
|
||||
.B
|
||||
newinfo \fIlist\fR \fIpassword\fR
|
||||
.P
|
||||
Update the informational message for
|
||||
.I list
|
||||
with the text which follows on subsequent lines. No formatting of the
|
||||
message occurs, so the list owner should be careful to constrain the message
|
||||
to eighty columns. Majordomo will include everything up to the string
|
||||
.B EOF
|
||||
or to the end of the mail message, whichever comes first. This is useful in
|
||||
case the owner wants to verify the new message immediately, e.g.,
|
||||
.sp 1
|
||||
.RS 10
|
||||
To: majordomo
|
||||
.sp 0
|
||||
newinfo list password
|
||||
.sp
|
||||
This is new information for the "list" list.
|
||||
.sp
|
||||
EOF
|
||||
.sp 0
|
||||
info list
|
||||
.sp
|
||||
.RE
|
||||
.RS 5
|
||||
This will simultaneously update the information for the list, and then
|
||||
retrieve it for verification. Note that blank lines are preserved in the
|
||||
message.
|
||||
.RE
|
||||
.TP 5
|
||||
.B
|
||||
newintro \fIlist\fR \fIpassword\fR
|
||||
.P
|
||||
Similar to
|
||||
.I newinfo ,
|
||||
but updates the (optional) introductory message sent to new
|
||||
.I list
|
||||
subscribers.
|
||||
.B
|
||||
passwd \fIlist\fR \fIold-password\fR \fInew-password\fR
|
||||
.P
|
||||
Replace the password for
|
||||
.I list
|
||||
with
|
||||
.IR new-password .
|
||||
.TP 5
|
||||
.B
|
||||
config \fIlist\fR \fIpassword\fR
|
||||
.P
|
||||
retrieve a self-documenting configuration file for
|
||||
the list <list>. The \fIpassword\fR can be the password
|
||||
contained in the file <listname>.passwd or the
|
||||
admin_password in the configuration file.
|
||||
.TP 5
|
||||
.B
|
||||
newconfig \fIlist\fR \fIpassword\fR
|
||||
.P
|
||||
Validates and installs a new configuration file. The config file
|
||||
includes everything up to the string
|
||||
.B EOF
|
||||
or to the end of the mail message, whichever comes first. The config
|
||||
file is expected to be a complete config file as returned by the
|
||||
"config" command. Incremental changing of the config file is not yet
|
||||
supported. As soon as the config file is validated and installed its
|
||||
settings are available for use. This is useful to remember if you have
|
||||
multiple commands in your mail message since they will be subject to
|
||||
the settings of the new config file. If there is an error in the
|
||||
config file (incorrect value...), the config file will not be accepted
|
||||
and the error message identifying the problem line(s) will be returned
|
||||
to the sender. Note that only the errors are returned to the
|
||||
sender not the entire config file.
|
||||
.TP 5
|
||||
.B
|
||||
writeconfig \fIlist\fR \fIpassword\fR
|
||||
.P
|
||||
Write a new config in standard form. All of the config
|
||||
file documentation is optional. Only the keywords and
|
||||
values are necessary. If a config file, stripped of
|
||||
all comments is installed using newconfig, that is
|
||||
what is returned by config. Writeconfig forces a
|
||||
rewrite of the config file with all comments and
|
||||
default values in place. It is useful to use after an
|
||||
upgrade of majordomo since it will add the new
|
||||
keywords for people to change. It also updates the
|
||||
documentation in the file if that has changed.
|
||||
.TP 5
|
||||
.B mkdigest
|
||||
.I digest-list-name
|
||||
[
|
||||
.I outgoing-address
|
||||
]
|
||||
.I password
|
||||
.P
|
||||
This will force a digest for the specified list to be created. It is
|
||||
most useful if you don't have an account on the machine that handles
|
||||
the digest for your list.
|
||||
The optional
|
||||
.I outgoing-address
|
||||
will override the default address,
|
||||
.IR listname -outgoing ,
|
||||
for distributing the digests;
|
||||
this is usually done for security.
|
||||
.SH CONFIGURATION
|
||||
(Note that this section has not been updated to majordomo version 1.90).
|
||||
.B Majordomo
|
||||
supports
|
||||
.I open
|
||||
and
|
||||
.I closed
|
||||
lists. An
|
||||
.I open
|
||||
list is one to which anyone can subscribe themselves. A subscription
|
||||
request sent to
|
||||
.B Majordomo
|
||||
for a
|
||||
.I closed
|
||||
list is forwarded to the owner of the list for approval. If a user tries to
|
||||
subscribe an address which is different from their own (for example, a local
|
||||
list exploder),
|
||||
.B Majordomo
|
||||
will forward the request to the list owner for approval, regardless of the
|
||||
open or closed status of the list.
|
||||
.PP
|
||||
.B Majordomo
|
||||
depends on the existence of certain system mail aliases. The first three
|
||||
are for running the perl script on incoming e-mail and specifying the
|
||||
responsible person in charge of the server:
|
||||
.sp 1
|
||||
majordomo: "|/usr/local/mail/majordomo/wrapper majordomo"
|
||||
.sp 0
|
||||
majordomo-owner: brent
|
||||
.sp 0
|
||||
owner-majordomo: brent
|
||||
.sp 1
|
||||
These next few aliases are for a list called "sample":
|
||||
.sp 1
|
||||
sample: :include:/usr/local/mail/lists/sample
|
||||
.sp 0
|
||||
owner-sample: sample-owner
|
||||
.sp 0
|
||||
sample-request: "|/usr/local/mail/majordomo/wrapper request-answer sample"
|
||||
.sp 0
|
||||
owner-sample-request: sample-owner
|
||||
.sp 0
|
||||
sample-owner: brent
|
||||
.sp 0
|
||||
sample-approval: brent
|
||||
.sp 1
|
||||
|
||||
.SH FILES
|
||||
/etc/majordomo.cf
|
||||
.sp 0
|
||||
/usr/local/lib/mail/majordomo/
|
||||
|
||||
.SH BUGS
|
||||
This man page has not been fully updated to conform to majordomo 1.90.
|
||||
|
||||
.SH AUTHORS
|
||||
Majordomo and most of the ancillary perl code was written by Brent Chapman,
|
||||
<brent@GreatCircle.COM>. The latest version of the code is available by
|
||||
anonymous FTP from FTP.GreatCircle.COM, in directory pub/majordomo.
|
||||
This man page was written by Jim Duncan, <jim@math.psu.edu>. Minimal
|
||||
update of the man page by John Rouillard <rouilj@cs.umb.edu>.
|
||||
264
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/majordomo.man
vendored
Normal file
264
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/majordomo.man
vendored
Normal file
@@ -0,0 +1,264 @@
|
||||
|
||||
|
||||
|
||||
MAJORDOMO(8) MAINTENANCE COMMANDS MAJORDOMO(8)
|
||||
|
||||
|
||||
|
||||
NAME
|
||||
Majordomo - manage multiple mailing lists
|
||||
|
||||
SYNOPSIS
|
||||
Majordomo
|
||||
|
||||
DESCRIPTION
|
||||
Majordomo is a perl script which automates the management of
|
||||
Internet mailing lists. It is executed via electronic mail;
|
||||
users send e-mail to Majordomo with instructions in the body
|
||||
of the message, and the perl script performs the requested
|
||||
actions and responds with the results. Any text in the
|
||||
"Subject:" line is ignored.
|
||||
|
||||
COMMANDS
|
||||
Majordomo understands the following commands (arguments in
|
||||
"[]" are optional):
|
||||
|
||||
subscribe _l_i_s_t [_a_d_d_r_e_s_s]
|
||||
Subscribe yourself (or _a_d_d_r_e_s_s if specified) to the
|
||||
named _l_i_s_t.
|
||||
|
||||
unsubscribe _l_i_s_t [_a_d_d_r_e_s_s]
|
||||
Unsubscribe yourself (or _a_d_d_r_e_s_s if specified) from the
|
||||
named _l_i_s_t.
|
||||
|
||||
get _l_i_s_t _f_i_l_e
|
||||
Get the _f_i_l_e related to _l_i_s_t.
|
||||
|
||||
index _l_i_s_t
|
||||
Return an index of the files you can _g_e_t associated
|
||||
with _l_i_s_t.
|
||||
|
||||
which [_a_d_d_r_e_s_s]
|
||||
Find out to which lists you (or _a_d_d_r_e_s_s if specified)
|
||||
are subscribed.
|
||||
|
||||
who _l_i_s_t
|
||||
Find out who is on the named _l_i_s_t.
|
||||
|
||||
info _l_i_s_t
|
||||
Retrieve the general introductory information for the
|
||||
named _l_i_s_t.
|
||||
|
||||
lists
|
||||
Show the lists served by this Majordomo server. It will
|
||||
also show a 50 character list description if one has
|
||||
been provided.
|
||||
|
||||
help Retrieve an informational message, a brief synopsis of
|
||||
the user portion of this manual page.
|
||||
|
||||
|
||||
|
||||
|
||||
Sun Release 4.1 Last change: 1
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
MAJORDOMO(8) MAINTENANCE COMMANDS MAJORDOMO(8)
|
||||
|
||||
|
||||
|
||||
end Stop processing commands (useful if your mailer adds a
|
||||
signature).
|
||||
|
||||
A command may be split across multiple lines if all of the
|
||||
lines in the command except the last end with a backslash
|
||||
"\".
|
||||
|
||||
In addition, the owner of the list can issue the following
|
||||
commands:
|
||||
|
||||
approve _p_a_s_s_w_o_r_d subscribe _l_i_s_t _a_d_d_r_e_s_s
|
||||
Instruct Majordomo to add _a_d_d_r_e_s_s to _l_i_s_t. The pass-
|
||||
word is required to authenticate the list owner. This
|
||||
is very weak authentication as the password is
|
||||
transmitted in the clear in an e-mail message. No
|
||||
claims are made that it will provide anything other
|
||||
than rudimentary protection against abuse of the Major-
|
||||
domo server.
|
||||
|
||||
approve _p_a_s_s_w_o_r_d unsubscribe _l_i_s_t _a_d_d_r_e_s_s
|
||||
Instruct Majordomo to delete _a_d_d_r_e_s_s from _l_i_s_t. The
|
||||
password is required to authenticate the list owner.
|
||||
See the comments above regarding the password.
|
||||
|
||||
newinfo _l_i_s_t _p_a_s_s_w_o_r_d
|
||||
Update the informational message for _l_i_s_t with the text
|
||||
which follows on subsequent lines. No formatting of
|
||||
the message occurs, so the list owner should be careful
|
||||
to constrain the message to eighty columns. Majordomo
|
||||
will include everything up to the string EOF or to the
|
||||
end of the mail message, whichever comes first. This
|
||||
is useful in case the owner wants to verify the new
|
||||
message immediately, e.g.,
|
||||
|
||||
To: majordomo
|
||||
newinfo list password
|
||||
|
||||
This is new information for the "list" list.
|
||||
|
||||
EOF
|
||||
info list
|
||||
|
||||
This will simultaneously update the information for the
|
||||
list, and then retrieve it for verification. Note that
|
||||
blank lines are preserved in the message.
|
||||
|
||||
passwd _l_i_s_t _o_l_d-_p_a_s_s_w_o_r_d _n_e_w-_p_a_s_s_w_o_r_d
|
||||
Replace the password for _l_i_s_t with _n_e_w-_p_a_s_s_w_o_r_d.
|
||||
|
||||
config _l_i_s_t _p_a_s_s_w_o_r_d
|
||||
retrieve a self-documenting configuration file for the
|
||||
list <list>. The _p_a_s_s_w_o_r_d can be the password
|
||||
|
||||
|
||||
|
||||
Sun Release 4.1 Last change: 2
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
MAJORDOMO(8) MAINTENANCE COMMANDS MAJORDOMO(8)
|
||||
|
||||
|
||||
|
||||
contained in the file <listname>.passwd or the
|
||||
admin_password in the configuration file.
|
||||
|
||||
newconfig _l_i_s_t _p_a_s_s_w_o_r_d
|
||||
Validates and installs a new configuration file. The
|
||||
config file includes everything up to the string EOF or
|
||||
to the end of the mail message, whichever comes first.
|
||||
The config file is expected to be a complete config
|
||||
file as returned by the "config" command. Incremental
|
||||
changing of the config file is not yet supported. As
|
||||
soon as the config file is validated and installed its
|
||||
settings are available for use. This is useful to
|
||||
remember if you have multiple commands in your mail
|
||||
message since they will be subject to the settings of
|
||||
the new config file. If there is an error in the con-
|
||||
fig file (incorrect value...), the config file will not
|
||||
be accepted and the error message identifying the prob-
|
||||
lem line(s) will be returned to the sender. Note that
|
||||
only the errors are returned to the sender not the
|
||||
entire config file.
|
||||
|
||||
writeconfig _l_i_s_t _p_a_s_s_w_o_r_d
|
||||
Write a new config in standard form. All of the config
|
||||
file documentation is optional. Only the keywords and
|
||||
values are necessary. If a config file, stripped of all
|
||||
comments is installed using newconfig, that is what is
|
||||
returned by config. Writeconfig forces a rewrite of
|
||||
the config file with all comments and default values in
|
||||
place. It is useful to use after an upgrade of major-
|
||||
domo since it will add the new keywords for people to
|
||||
change. It also updates the documentation in the file
|
||||
if that has changed.
|
||||
|
||||
mkdigest _d_i_g_e_s_t-_l_i_s_t-_n_a_m_e _p_a_s_s_w_o_r_d
|
||||
This will force a digest for the specified list to be
|
||||
created. It is most useful if you don't have an account
|
||||
on the machine that handles the digest for your list.
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
(Note that this section has not been updated to majordomo
|
||||
version 1.90). Majordomo supports _o_p_e_n and _c_l_o_s_e_d lists.
|
||||
An _o_p_e_n list is one to which anyone can subscribe them-
|
||||
selves. A subscription request sent to Majordomo for a
|
||||
_c_l_o_s_e_d list is forwarded to the owner of the list for appro-
|
||||
val. If a user tries to subscribe an address which is dif-
|
||||
ferent from their own (for example, a local list exploder),
|
||||
Majordomo will forward the request to the list owner for
|
||||
approval, regardless of the open or closed status of the
|
||||
list.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sun Release 4.1 Last change: 3
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
MAJORDOMO(8) MAINTENANCE COMMANDS MAJORDOMO(8)
|
||||
|
||||
|
||||
|
||||
Majordomo depends on the existence of certain system mail
|
||||
aliases. The first three are for running the perl script on
|
||||
incoming e-mail and specifying the responsible person in
|
||||
charge of the server:
|
||||
|
||||
majordomo: "|/usr/local/mail/majordomo/wrapper majordomo"
|
||||
majordomo-owner: brent
|
||||
owner-majordomo: brent
|
||||
|
||||
These next few aliases are for a list called "sample":
|
||||
|
||||
sample: :include:/usr/local/mail/lists/sample
|
||||
owner-sample: sample-owner
|
||||
sample-request: "|/usr/local/mail/majordomo/wrapper
|
||||
request-answer sample"
|
||||
owner-sample-request: sample-owner
|
||||
sample-owner: brent
|
||||
sample-approval: brent
|
||||
|
||||
|
||||
|
||||
FILES
|
||||
/etc/majordomo.cf
|
||||
/usr/local/lib/mail/majordomo/
|
||||
|
||||
|
||||
BUGS
|
||||
This man page has not been fully updated to conform to
|
||||
majordomo 1.90.
|
||||
|
||||
|
||||
AUTHORS
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman, <brent@GreatCircle.COM>. The latest version
|
||||
of the code is available by anonymous FTP from
|
||||
FTP.GreatCircle.COM, in directory pub/majordomo. This man
|
||||
page was written by Jim Duncan, <jim@math.psu.edu>. Minimal
|
||||
update of the man page by John Rouillard
|
||||
<rouilj@cs.umb.edu>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sun Release 4.1 Last change: 4
|
||||
|
||||
|
||||
|
||||
184
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/resend.1
vendored
Normal file
184
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/resend.1
vendored
Normal file
@@ -0,0 +1,184 @@
|
||||
.TH resend 1
|
||||
.SH NAME
|
||||
resend \- resend messages after evaluation
|
||||
.LP
|
||||
.SH SYNOPSIS
|
||||
.B resend
|
||||
.B [\-A]
|
||||
.B [\-C config-file]
|
||||
.B [\-I file-list]
|
||||
.B [\-M max-msg-length]
|
||||
.B [\-R]
|
||||
.B [\-a passwd]
|
||||
.B [\-d]
|
||||
.B [\-f from-addr]
|
||||
.B [\-h host-name]
|
||||
.B \-l list-name
|
||||
.B [\-n]
|
||||
.B [\-p precedence]
|
||||
.B [\-r reply-to]
|
||||
.B [\-s]
|
||||
.B destination
|
||||
.LP
|
||||
.SH AVAILABILITY
|
||||
Provided with distributions of Majordomo.
|
||||
.LP
|
||||
.SH DESCRIPTION
|
||||
.B resend
|
||||
is a perl script that is usually used to redirect mail messages to
|
||||
a mailing list after evaluating and parsing the headers. Mail is
|
||||
"resent" by handing it off to the mailer again with an alternate
|
||||
destination as specified by the final operand.
|
||||
.LP
|
||||
Any message that
|
||||
.B resend
|
||||
doesn't like is sent to the list owner (the
|
||||
"-f" address, or "<list-name>-owner" if -f isn't used) along with a
|
||||
comment indicating what "resend" didn't like about it. To go ahead
|
||||
and send the message, just feed it to resend without the flag that
|
||||
caused it to reject it (in other words, if it rejected it because it
|
||||
was too long, omit the "-M <>" flag; if it rejected it because it was
|
||||
administrivia, omit the "-s" flag).
|
||||
.LP
|
||||
If you specify "-a <passwd>" flag, this "approval" password can be
|
||||
used in an "Approved: <passwd>" line to override most of the other
|
||||
checks (those enabled by "-s", "-M", and so forth). The "Approved:
|
||||
<passwd>" line can either be one of the mail headers, or the first
|
||||
line of the body of the message. If it is in the headers, the rest
|
||||
of the headers are resent as part of the approved message. If it is
|
||||
in the body, the current headers are discarded in favor of the headers
|
||||
from the original message which should follow the "Approved:" line in
|
||||
the body.
|
||||
.LP
|
||||
The owner of a mailing list can thus post messages that were initially
|
||||
bounced by adding an "Approved: <passwd>" line and resubmitting the
|
||||
message. Any "Approved: <passwd>" line is stripped before the message
|
||||
is sent to the mailing list, so that list members won't learn the
|
||||
password. If the <passwd> argument to the "-a" flag begins with a "/",
|
||||
it is assumed to be a file name from which the actual password is read.
|
||||
.LP
|
||||
You can make a list "moderated" by specifying the "-A" flag. If the
|
||||
"-A" flag is set, then any messages not containing a valid "Approved:"
|
||||
line are sent to the list owner, rather than the whole list.; the
|
||||
list owner can then review the message, add an appropriate "Approved:"
|
||||
line, and resubmit them (these last two steps can be done easily with
|
||||
the "approve" command that comes with Majordomo). If you specify
|
||||
the "-A" flag, you must also specify the "-a <passwd>" flag, so that
|
||||
resend knows what approval password to use.
|
||||
.LP
|
||||
If you only want to accept messages from members of a list, you can
|
||||
use the "-I <file-list>" flag to do this. "<file-list>" should be a
|
||||
colon-separated list of files in the $listdir directory (specified in
|
||||
the config file) that "resend" will check the address in "From:" line
|
||||
of a message against. If the address doesn't show up in one of those
|
||||
files, and the message doesn't have a valid "approved" header on it,
|
||||
it will be bounced to the list owner.
|
||||
.LP
|
||||
.SH OPTIONS
|
||||
The following options can be used with resend:
|
||||
.LP
|
||||
.TP 10
|
||||
.B \-A
|
||||
Approve; enable list moderation by requiring an Approved: header to be
|
||||
present in the message before resending. Messages without an Approved:
|
||||
header will be redirected to the list owner for approval.
|
||||
.TP
|
||||
.B \-C config-file
|
||||
Alternate configuration file; tell resend to use the file
|
||||
.TP
|
||||
.B config-file
|
||||
instead of the default list-name.config.
|
||||
.TP
|
||||
.B \-I file-list
|
||||
Include; ensure that the message sender (as represented in the From:
|
||||
line of the incoming message) is in one of the file(s) specified in
|
||||
.BR file-list .
|
||||
.B file-list
|
||||
may contain multiple colon separated pathnames. Each pathname should
|
||||
point to a file that contains a sendmail-style mailing list.
|
||||
.TP
|
||||
.B [\-M max-msg-length]
|
||||
Maximum; Specify the maximum length of the relayed message in octets.
|
||||
.TP
|
||||
.B [\-R]
|
||||
Delete the "Received:" lines in the incoming message header. This can
|
||||
make the relayed messages considerably shorter at the expense of
|
||||
losing some potentially interesting debugging information.
|
||||
.TP
|
||||
.B [\-a passwd_file]
|
||||
Specify the pathname of the file containing the approval password for
|
||||
the list. This password is used to check Approved: headers when
|
||||
relaying messages to lists that are marked as moderated through the
|
||||
.B \-A
|
||||
option above.
|
||||
.TP
|
||||
.B [\-d]
|
||||
Debug; print what would be done, but don't do it.
|
||||
.TP
|
||||
.B [\-f from-addr]
|
||||
Set the From: address to
|
||||
.B from-addr
|
||||
.TP
|
||||
.B [\-h host-name]
|
||||
Set the name of the local host to
|
||||
.BR host-name .
|
||||
This name will be used in the From: and To: lines when updating the
|
||||
headers.
|
||||
.TP
|
||||
.B \-l list-name
|
||||
Specify the name of the mailing list as
|
||||
.BR list-name .
|
||||
This option is required, as
|
||||
.B resend
|
||||
uses this name to derive the names
|
||||
of many other files.
|
||||
.TP
|
||||
.B [\-n]
|
||||
Assign a sequence number to each message as it comes through. The next
|
||||
sequence number is stored in the file lists/list-name.seq. If the
|
||||
string $SEQNUM is found in the $subject-prefix configuration variable,
|
||||
it is replaced with the current sequence number. Thus, a
|
||||
$subject_prefix of "($LIST $SEQNUM)" would render a Subject: line of
|
||||
(list-name sequence-number).
|
||||
.TP
|
||||
.B [\-p precedence]
|
||||
Set the Precedence: header to
|
||||
.BR precedence .
|
||||
.TP
|
||||
.B [\-r reply-to]
|
||||
Set the Reply-To: header to
|
||||
.BR reply-to .
|
||||
.TP
|
||||
.B [\-s]
|
||||
Administrivia; Search the message for strings commonly found in
|
||||
administrative messages send to majordomo mailing lists (e.g.
|
||||
subscribe, unsubscribe). If these are found in the first 10 or so
|
||||
lines of the message, the message will be relayed to the list owner
|
||||
instead of being sent on to the mailing list.
|
||||
.SH OPERANDS
|
||||
.TP 10
|
||||
.B destination
|
||||
The alias to which to redirect the message if it is a proper list
|
||||
submission.
|
||||
.LP
|
||||
.SH CONFIGURATION
|
||||
.LP
|
||||
.SH FILES
|
||||
.PD 0
|
||||
.TP 20
|
||||
.B /etc/aliases
|
||||
.TP
|
||||
.B /etc/majordomo.cf
|
||||
.TP
|
||||
.B lists/list-name.config
|
||||
.PD
|
||||
.LP
|
||||
.SH SEE ALSO
|
||||
.B majordomo(8),approve(1)
|
||||
.LP
|
||||
.SH AUTHOR
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman <brent@GreatCircle.COM>.
|
||||
Majordomo is available via anonymous FTP
|
||||
from FTP.GreatCircle.COM, in the directory pub/majordomo. This
|
||||
man page was written by Shane McCarron <ahby@themacs.com>.
|
||||
264
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/resend.man
vendored
Normal file
264
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/man/resend.man
vendored
Normal file
@@ -0,0 +1,264 @@
|
||||
|
||||
|
||||
|
||||
rrrreeeesssseeeennnndddd((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV rrrreeeesssseeeennnndddd((((1111))))
|
||||
|
||||
|
||||
|
||||
NNNNAAAAMMMMEEEE
|
||||
resend - resend messages after evaluation
|
||||
|
||||
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
|
||||
rrrreeeesssseeeennnndddd [[[[----AAAA]]]] [[[[----CCCC ccccoooonnnnffffiiiigggg----ffffiiiilllleeee]]]] [[[[----IIII ffffiiiilllleeee----lllliiiisssstttt]]]] [[[[----MMMM mmmmaaaaxxxx----mmmmssssgggg----
|
||||
lllleeeennnnggggtttthhhh]]]] [[[[----RRRR]]]] [[[[----aaaa ppppaaaasssssssswwwwdddd]]]] [[[[----dddd]]]] [[[[----ffff ffffrrrroooommmm----aaaaddddddddrrrr]]]] [[[[----hhhh hhhhoooosssstttt----nnnnaaaammmmeeee]]]]
|
||||
----llll lllliiiisssstttt----nnnnaaaammmmeeee [[[[----nnnn]]]] [[[[----pppp pppprrrreeeecccceeeeddddeeeennnncccceeee]]]] [[[[----rrrr rrrreeeeppppllllyyyy----ttttoooo]]]] [[[[----ssss]]]]
|
||||
ddddeeeessssttttiiiinnnnaaaattttiiiioooonnnn
|
||||
|
||||
AAAAVVVVAAAAIIIILLLLAAAABBBBIIIILLLLIIIITTTTYYYY
|
||||
Provided with distributions of Majordomo.
|
||||
|
||||
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
|
||||
rrrreeeesssseeeennnndddd is a perl script that is usually used to redirect
|
||||
mail messages to a mailing list after evaluating and parsing
|
||||
the headers. Mail is "resent" by handing it off to the
|
||||
mailer again with an alternate destination as specified by
|
||||
the final operand.
|
||||
|
||||
Any message that rrrreeeesssseeeennnndddd doesn't like is sent to the list
|
||||
owner (the "-f" address, or "<list-name>-owner" if -f isn't
|
||||
used) along with a comment indicating what "resend" didn't
|
||||
like about it. To go ahead and send the message, just feed
|
||||
it to resend without the flag that caused it to reject it
|
||||
(in other words, if it rejected it because it was too long,
|
||||
omit the "-M <>" flag; if it rejected it because it was
|
||||
administrivia, omit the "-s" flag).
|
||||
|
||||
If you specify "-a <passwd>" flag, this "approval" password
|
||||
can be used in an "Approved: <passwd>" line to override most
|
||||
of the other checks (those enabled by "-s", "-M", and so
|
||||
forth). The "Approved: <passwd>" line can either be one of
|
||||
the mail headers, or the first line of the body of the
|
||||
message. If it is in the headers, the rest of the headers
|
||||
are resent as part of the approved message. If it is in the
|
||||
body, the current headers are discarded in favor of the
|
||||
headers from the original message which should follow the
|
||||
"Approved:" line in the body.
|
||||
|
||||
The owner of a mailing list can thus post messages that were
|
||||
initially bounced by adding an "Approved: <passwd>" line and
|
||||
resubmitting the message. Any "Approved: <passwd>" line is
|
||||
stripped before the message is sent to the mailing list, so
|
||||
that list members won't learn the password. If the <passwd>
|
||||
argument to the "-a" flag begins with a "/", it is assumed
|
||||
to be a file name from which the actual password is read.
|
||||
|
||||
You can make a list "moderated" by specifying the "-A" flag.
|
||||
If the "-A" flag is set, then any messages not containing a
|
||||
valid "Approved:" line are sent to the list owner, rather
|
||||
than the whole list.; the list owner can then review the
|
||||
message, add an appropriate "Approved:" line, and resubmit
|
||||
|
||||
|
||||
|
||||
Page 1 (printed 12/10/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rrrreeeesssseeeennnndddd((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV rrrreeeesssseeeennnndddd((((1111))))
|
||||
|
||||
|
||||
|
||||
them (these last two steps can be done easily with the
|
||||
"approve" command that comes with Majordomo). If you
|
||||
specify the "-A" flag, you must also specify the "-a
|
||||
<passwd>" flag, so that resend knows what approval password
|
||||
to use.
|
||||
|
||||
If you only want to accept messages from members of a list,
|
||||
you can use the "-I <file-list>" flag to do this. "<file-
|
||||
list>" should be a colon-separated list of files in the
|
||||
$listdir directory (specified in the config file) that
|
||||
"resend" will check the address in "From:" line of a message
|
||||
against. If the address doesn't show up in one of those
|
||||
files, and the message doesn't have a valid "approved"
|
||||
header on it, it will be bounced to the list owner.
|
||||
|
||||
OOOOPPPPTTTTIIIIOOOONNNNSSSS
|
||||
The following options can be used with resend:
|
||||
|
||||
----AAAA Approve; enable list moderation by requiring an
|
||||
Approved: header to be present in the message
|
||||
before resending. Messages without an Approved:
|
||||
header will be redirected to the list owner for
|
||||
approval.
|
||||
|
||||
----CCCC ccccoooonnnnffffiiiigggg----ffffiiiilllleeee
|
||||
Alternate configuration file; tell resend to use
|
||||
the file
|
||||
|
||||
ccccoooonnnnffffiiiigggg----ffffiiiilllleeee
|
||||
instead of the default list-name.config.
|
||||
|
||||
----IIII ffffiiiilllleeee----lllliiiisssstttt
|
||||
Include; ensure that the message sender (as
|
||||
represented in the From: line of the incoming
|
||||
message) is in one of the file(s) specified in
|
||||
ffffiiiilllleeee----lllliiiisssstttt. ffffiiiilllleeee----lllliiiisssstttt may contain multiple colon
|
||||
separated pathnames. Each pathname should point to
|
||||
a file that contains a sendmail-style mailing
|
||||
list.
|
||||
|
||||
[[[[----MMMM mmmmaaaaxxxx----mmmmssssgggg----lllleeeennnnggggtttthhhh]]]]
|
||||
Maximum; Specify the maximum length of the relayed
|
||||
message in octets.
|
||||
|
||||
[[[[----RRRR]]]] Delete the "Received:" lines in the incoming
|
||||
message header. This can make the relayed messages
|
||||
considerably shorter at the expense of losing some
|
||||
potentially interesting debugging information.
|
||||
|
||||
[[[[----aaaa ppppaaaasssssssswwwwdddd____ffffiiiilllleeee]]]]
|
||||
Specify the pathname of the file containing the
|
||||
approval password for the list. This password is
|
||||
|
||||
|
||||
|
||||
Page 2 (printed 12/10/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rrrreeeesssseeeennnndddd((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV rrrreeeesssseeeennnndddd((((1111))))
|
||||
|
||||
|
||||
|
||||
used to check Approved: headers when relaying
|
||||
messages to lists that are marked as moderated
|
||||
through the ----AAAA option above.
|
||||
|
||||
[[[[----dddd]]]] Debug; print what would be done, but don't do it.
|
||||
|
||||
[[[[----ffff ffffrrrroooommmm----aaaaddddddddrrrr]]]]
|
||||
Set the From: address to ffffrrrroooommmm----aaaaddddddddrrrr
|
||||
|
||||
[[[[----hhhh hhhhoooosssstttt----nnnnaaaammmmeeee]]]]
|
||||
Set the name of the local host to hhhhoooosssstttt----nnnnaaaammmmeeee. This
|
||||
name will be used in the From: and To: lines when
|
||||
updating the headers.
|
||||
|
||||
----llll lllliiiisssstttt----nnnnaaaammmmeeee
|
||||
Specify the name of the mailing list as lllliiiisssstttt----nnnnaaaammmmeeee.
|
||||
This option is required, as rrrreeeesssseeeennnndddd uses this name
|
||||
to derive the names of many other files.
|
||||
|
||||
[[[[----nnnn]]]] Assign a sequence number to each message as it
|
||||
comes through. The next sequence number is stored
|
||||
in the file lists/list-name.seq. If the string
|
||||
$SEQNUM is found in the $subject-prefix
|
||||
configuration variable, it is replaced with the
|
||||
current sequence number. Thus, a $subject_prefix
|
||||
of "($LIST $SEQNUM)" would render a Subject: line
|
||||
of (list-name sequence-number).
|
||||
|
||||
[[[[----pppp pppprrrreeeecccceeeeddddeeeennnncccceeee]]]]
|
||||
Set the Precedence: header to pppprrrreeeecccceeeeddddeeeennnncccceeee.
|
||||
|
||||
[[[[----rrrr rrrreeeeppppllllyyyy----ttttoooo]]]]
|
||||
Set the Reply-To: header to rrrreeeeppppllllyyyy----ttttoooo.
|
||||
|
||||
[[[[----ssss]]]] Administrivia; Search the message for strings
|
||||
commonly found in administrative messages send to
|
||||
majordomo mailing lists (e.g. subscribe,
|
||||
unsubscribe). If these are found in the first 10
|
||||
or so lines of the message, the message will be
|
||||
relayed to the list owner instead of being sent on
|
||||
to the mailing list.
|
||||
|
||||
OOOOPPPPEEEERRRRAAAANNNNDDDDSSSS
|
||||
ddddeeeessssttttiiiinnnnaaaattttiiiioooonnnn
|
||||
The alias to which to redirect the message if it
|
||||
is a proper list submission.
|
||||
|
||||
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
|
||||
FFFFIIIILLLLEEEESSSS
|
||||
////eeeettttcccc////aaaalllliiiiaaaasssseeeessss
|
||||
////eeeettttcccc////mmmmaaaajjjjoooorrrrddddoooommmmoooo....ccccffff
|
||||
lllliiiissssttttssss////lllliiiisssstttt----nnnnaaaammmmeeee....ccccoooonnnnffffiiiigggg
|
||||
|
||||
|
||||
|
||||
Page 3 (printed 12/10/96)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rrrreeeesssseeeennnndddd((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV rrrreeeesssseeeennnndddd((((1111))))
|
||||
|
||||
|
||||
|
||||
SSSSEEEEEEEE AAAALLLLSSSSOOOO
|
||||
mmmmaaaajjjjoooorrrrddddoooommmmoooo((((8888)))),,,,aaaapppppppprrrroooovvvveeee((((1111))))
|
||||
|
||||
AAAAUUUUTTTTHHHHOOOORRRR
|
||||
Majordomo and most of the ancillary perl code was written by
|
||||
Brent Chapman <brent@GreatCircle.COM>. Majordomo is
|
||||
available via anonymous FTP from FTP.GreatCircle.COM, in the
|
||||
directory pub/majordomo. This man page was written by Shane
|
||||
McCarron <ahby@themacs.com>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Page 4 (printed 12/10/96)
|
||||
|
||||
|
||||
|
||||
105
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/quick-digest-setup
vendored
Normal file
105
directadmin-1.62.4/scripts/packages/majordomo-1.94.5/Doc/quick-digest-setup
vendored
Normal file
@@ -0,0 +1,105 @@
|
||||
|
||||
QUICK DIGEST SETUP:
|
||||
|
||||
For the purpose of example, let's say that you have a majordomo list
|
||||
called "banjo" and that you want to create "banjo-digest".
|
||||
|
||||
1. You need to create two directories: the digest's work directory
|
||||
and the digest's archive directory. They CAN'T be the same directory.
|
||||
|
||||
Where should these directories be created? Look in your majordomo.cf
|
||||
file to see how these three variables are defined: $digest_work_dir,
|
||||
$filedir, $filedir_suffix. Let's say they look like this:
|
||||
|
||||
$digest_work_dir = "/usr/local/mail/digest";
|
||||
$filedir = "/usr/local/mail/files";
|
||||
$filedir_suffix = ".archive";
|
||||
|
||||
That being the case, you must create these two directories:
|
||||
|
||||
/usr/local/mail/digest/banjo-digest
|
||||
/usr/local/mail/files/banjo-digest.archive
|
||||
|
||||
The first is the work directory, the second is the archive directory.
|
||||
|
||||
Make sure that majordomo has write permission on both directories.
|
||||
|
||||
|
||||
2. You must create a majordomo list called "banjo-digest".
|
||||
|
||||
In most respects it is just like any ordinary list, but when you
|
||||
set up the configuration file (banjo-digest.config), you will
|
||||
have to configure these parameters:
|
||||
|
||||
digest_issue = 1
|
||||
digest_name = Banjo Digest
|
||||
digest_volume = 1
|
||||
digest_maxdays =
|
||||
digest_maxlines =
|
||||
maxlength = 40000
|
||||
message_footer << END
|
||||
END
|
||||
message_fronter << END
|
||||
END
|
||||
|
||||
Remember that these variables are in banjo-digest.config, NOT banjo.config.
|
||||
|
||||
Also, do NOT touch the variables digest_archive, digest_rm_header, etc.
|
||||
|
||||
Both digest_issue and digest_number should start at 1 unless you have
|
||||
some special reason to do otherwise. The digest name should be an
|
||||
obvious choice, but don't make it longer than 24 characters.
|
||||
|
||||
"maxlength" is the maximum size in characters (bytes) for a digest.
|
||||
"digest_maxlines" is the maximum number of lines in a digest.
|
||||
"digest_maxdays" is the maximum age in days of an article in a digest.
|
||||
|
||||
The last two parameters are optional, but maxlength must be defined.
|
||||
A digest will automatically be created if any one of the three limits
|
||||
is exceeded.
|
||||
|
||||
You can put this sort of material in the header or footer:
|
||||
|
||||
message_fronter << END
|
||||
In this issue:
|
||||
-
|
||||
- _SUBJECTS_
|
||||
-
|
||||
See the end of the digest for information about banjo-digest.
|
||||
END
|
||||
|
||||
Note that you need to indicate blank lines by placing a '-'
|
||||
character at the beginning of the line. You also indicate
|
||||
whitespace at the beginning of a line by putting a '-' in
|
||||
front of the whitespace.
|
||||
|
||||
The _SUBJECTS_ token will be expanded to all of the subject lines
|
||||
of the messages in the digest, one subject per line.
|
||||
|
||||
3. Create some aliases.
|
||||
|
||||
You need to add to the banjo-outgoing alias:
|
||||
|
||||
banjo-outgoing: :include:/path/to/lists/banjo, banjo-digestify
|
||||
|
||||
and then you need the banjo-digest aliases:
|
||||
|
||||
banjo-digestify: "|/path/to/wrapper digest -r -C -l banjo-digest banjo-digest-outgoing"
|
||||
|
||||
banjo-digest: banjo
|
||||
banjo-digest-outgoing: :include:/path/to/lists/banjo-digest
|
||||
owner-banjo-digest-outgoing: harry
|
||||
banjo-digest-approval: harry
|
||||
|
||||
4. Add a cron job.
|
||||
|
||||
If you want digests to be created at regular intervals, put this
|
||||
line in your cron table:
|
||||
|
||||
echo mkdigest banjo-digest pluck | mail majordomo@mj.server.com
|
||||
|
||||
("pluck" is the digest's password).
|
||||
|
||||
5. Test it!
|
||||
|
||||
|
||||
Reference in New Issue
Block a user