This commit is contained in:
tuend-work
2025-11-13 08:41:45 +07:00
parent 1b646f6a89
commit 18736081c6
166 changed files with 72044 additions and 2 deletions

File diff suppressed because it is too large Load Diff

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

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

View 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 :-)

View 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

View 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=

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

View File

@@ -0,0 +1 @@
13

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

View File

@@ -0,0 +1 @@
1

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

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

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

View 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

View File

@@ -0,0 +1 @@
.so man1/bounce.1

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

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

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

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

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

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

View 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

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

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

View 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!