home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
High Voltage Shareware
/
high1.zip
/
high1
/
DIR4
/
REF21.ZIP
/
REF.DOC
< prev
next >
Wrap
Text File
|
1994-01-31
|
45KB
|
857 lines
┌───────────────┐
│ The REF 2.1 │
└───────────────┘
"The Message Area Referee"
Compliments of: The HOTware BBS
Net/Node 064/003
* PLEASE DELETE ALL Version 1.5 ARCHIVES, Ver. 1.5 CONTAINS *
* NUMEROUS PROBLEMS AND SHOULD NOT BE USED *
──────────────────────────────────────────────────────────────
History
──────────────────────────────────────────────────────────────
11-02-92 Ver 1.0 Initial Release
11-12-92 Ver 1.1 Added /LOG command line parameter. /LOG
will cause a REF.LOG to be kept in
<GTPATH>\HOTWARE.
10-31-93 Ver 1.2 Added the REVIEW flag. This gives REF the
ability to REVIEW messages from select users
prior to bagging the message area. Added
the /REGISTER feature to REF. Added /NLOG (new
log) to REF.
11-04-93 Ver 1.3 Major Bug Fix! When using The REF on multiple
message areas, the Name's list was not being
purged correctly. The result, any names that
were in previously processed message areas were
again being processed, even if the names were
not listed for that message area. Please
delete version 1.2 of The Ref IMMEDIATELY if
you are processing multiple message areas from
one configuration file.
11-07-93 Ver 1.4 Added four new "FLAGS": REVIEW_BY_ORIGIN,
MOVE_BY_ORIGIN, KILL_BY_ORIGIN, MARK_BY_ORIGIN.
These new "FLAGS" allow you to specify a list
of NET/NODE numbers for REF to look for rather
than sender names on messages. When using
these new "FLAGS" REF will dynamically build
the name list and add any names that it finds
in your message area that has any of NET/NODE
numbers that you listed. See Discussion below
for further information.
1-01-94 Ver 1.5 Added four new "FLAGS": REVIEW_BY_RECEIVER,
MOVE_BY_RECEIVER, KILL_BY_RECEIVER,
MARK_BY_RECEIVER. These new "FLAGS" allow you
to specify a list of RECEIVE names for REF
to look for rather than SENDER names on
messages. When using these new "FLAGS" REF
will now look at the message Receivers rather
than the message Senders. Please read the
documentation below for further information.
1-02-94 Ver 1.6 MAJOR BUG FIX RELEASE! DELETE VERSION 1.5
IMMEDIATELY! Version 1.5 was very overzealous
with Deleting Moving and Marking messages and
SHOULD NOT BE USED. Version 1.6 fixes the
problems with Deleting Moving and Marking of
messages that should not be operated on. This
version also adds a much improved logging
logging facility and improved screens. This
version also repairs a problem with comparing
one word names. Previous version were not
working with single word names.
1-18-94 Ver 1.7 Added four new "FLAGS": REVIEW_BY_SUBJECT,
MOVE_BY_SUBJECT, KILL_BY_SUBJECT,
MARK_BY_SUBJECT. These new "FLAGS" allow you to
specify a list of SUBJECTs for REF to look for
rather than SENDER or RECEIVER names on
messages. When using any of the SUBJECT flags,
the Search text can also match substrings if the
first character of the configured subject is a
*. REF is now much more intelligent when using
the ORIGIN parameter. Rather than building a
name list as before, version 1.7 will look at
the ORIGIN of each message prior to operating
on it. The third improvement for this release
is a configurable message header. You may now
specify what you want REF to report as the
reason for the moved message. Please see the
documentation below for details on the above
new features.
1-21-94 Ver 1.8 Added three modifiers to the "FLAGS" argument
in REF.CNF. These modifiers add two major
improvements. The REF can now RETURN messages
to the sender, and The REF can now be told to
only operate on INCOMING or OUTGOING messages
specifically. These modifiers are invoked
immediately following your FLAGS argument in
REF.CNF in for form of /INBOUND /OUTBOUND
/RETURN. See the documentation below for
details on implementation.
1-22-94 Ver 1.9 REF will now indicate in the LOG File when a
message has been RETURNED to the sender.
1-23-94 Ver 2.0 REF now has the ability to process a GTMDIR.BBS
GLOBALLY, and process a list of message areas
rather than a single message area. Along with
the GLOBAL processing comes the ability to
EXCLUDE specific message areas even though they
are listed in the GTMDIR.BBS file. The REF also
recognizes a new command line parameter, /C:.
This new parameter will allow you to specify a
configuration file other than
<GTPATH>\HOTWARE\REF.CNF.
1-31-94 Ver 2.1 REF now has a new "Flag": ROUTE_VIA_NETMAIL.
This flag will allow you specify a list of
Receivers that you would like to have messages
routed to netmail. When using this "Flag"
each receivers name must be followed by the
Net/Node to route the message to. This release
also has a minor Bug fix. This version will
recognize if the Source and Destination message
areas are in the same directory, ie. the same
message base. This was a problem when the
Destination area in the REF.CNF was also an
area in the GTMDIR.BBS when using the GLOBAL
feature.
──────────────────────────────────────────────────────────────
What is It?
──────────────────────────────────────────────────────────────
What in the heck is The REF? The REF basically acts as a referee
of a Echo Message Area. This utility has two modes of operation
that you can use. Both of these modes are described below:
1: Creating a true READ-ONLY echo area.
The REF will allow you to specify who IS authorized to post in
a particular echo. Any messages that are found in a
configured echo that were posted by an UNAUTHORIZED user will
be "refereed". The sponsor of the echo has three option to
penalize the offending user. The REF can either MOVE the
message, KILL the message, or MARK the message as bagged so
that it will not echo throughout the network. All three of
these flags are classified under READ-ONLY echo mode, and are
described under CONFIGURATION AND EXECUTION below.
2: REVIEW messages TO or FROM users, by SUBJECT, or by ORIGIN.
The REF will allow you to specify who's messages you would
like to REVIEW prior to letting them echo to the network. If
you have had problems with a particular or several users
entering messages that are either off topic, vulgar, or
generally disruptive The REF can help. The REF can move
messages that are TO or FROM a configured list of user names,
SUBJECTS, or ORIGINS to an alternate message area for you, the
sysop or echos sponsor, to REVIEW prior to allowing the
message to echo. The REVIEW flags are classified under REVIEW
echo mode, and are described under CONFIGURATION AND EXECUTION
below.
Not only can REF read a list of User Names that you supply, it can
also check the ORIGIN Net/Node of messages. If you are afraid of
users using alias's, you can provide REF a list of NET/NODE
numbers. The REF will then look at the ORIGIN of each message and
operate on them if applicable. The REF also has the capability to
RETURN the messages to the offending user, see the discussion of
the /RETURN modifier below for details.
──────────────────────────────────────────────────────────────
Why Is It?
──────────────────────────────────────────────────────────────
You may be asking about now, Why would you want to do this?
It's simple. Prior to the birth of The REF there was no real way
of truly forcing an echo to READ ONLY. Now The REF can monitor
the actions of the players in a particular echo and throw flags to
any unauthorized maneuvers. In real life The REF scans the
message area looking for users that are Unauthorized and can take
appropriate action on these messages prior to nightly bagging
routines.
Further expanding on The REF, you can also truly REVIEW messages
by users that have a reputation of causing disruption in your echo
areas. You can now automatically move messages to an alternate
message area by user name, review the messages content, and them
move them and allow them to continue on the echo path at your
discretion.
──────────────────────────────────────────────────────────────
Configuration and Execution
──────────────────────────────────────────────────────────────
The REF reads a configuration file named REF.CNF from a directory
off your GTPATH named HOTWARE. For example if your GTPATH is set
to C:\GT, the REF.CNF must reside in C:\GT\HOTWARE. You may also
tell REF via a command line parameter /C, what configuration file
to use. For a complete discussion of the /C parameter, see
COMMAND LINE PARAMETERS below.
REF has two modes of operation READ-ONLY ECHO mode, and REVIEW
mode. These two modes will be explained separately and then
examples will be shown using the two modes in a single
configuration file.
────────────────────────────────────────────
READ-ONLY ECHO Mode
────────────────────────────────────────────
The READ-ONLY ECHO Mode looks at a list of users that are
classified as AUTHORIZED users. Any users that The REF see's that
is NOT in the AUTHORIZED list will be penalized. Under READ-ONLY
mode you decide whether the message is to be KILLed, MARKed
bagged, or MOVEd to an alternate area.
If you are afraid that some folks might try to use Alias's to get
by The REF, you can alternately supply a list of NET/NODE numbers
that are AUTHORIZED users. The REF will then look at the .ORIGIN
of each message and only allow AUTHORIZED NET/NODES. This is done
through the use of the following flags: KILL_BY_ORIGIN,
MARK_BY_ORIGIN, MOVE_BY_ORIGIN.
You may also look at the message RECEIVER or SUBJECT instead of
the message SENDER or ORIGIN. These options will allow you to
create a message area that contains only messages TO a particular
party, or messages that are a on specific SUBJECT. This is done
through the use of the following flags: KILL_BY_SUBJECT,
MARK_BY_SUBJECT, MOVE_BY_SUBJECT, KILL_BY_RECEIVER,
MARK_BY_RECEIVER, MOVE_BY_RECEIVER.
These are the twelve available "flags" that are used in READ-ONLY
mode, KILL, MARK, MOVE, KILL_BY_ORIGIN, MARK_BY_ORIGIN,
MOVE_BY_ORIGIN, KILL_BY_SUBJECT, MARK_BY_SUBJECT, MOVE_BY_SUBJECT,
KILL_BY_RECEIVER, MARK_BY_RECEIVER, MOVE_BY_RECEIVER
────────────────────────────────────────────
REVIEW Mode
────────────────────────────────────────────
The REVIEW Mode looks at a list of users that are classified as
UN-AUTHORIZED users. Any users that The REF see's that IS in the
UN-AUTHORIZED list will be reviewed. Under REVIEW mode the
messages will be moved to an alternate area (destination echo as
described below) for you to REVIEW.
If you are afraid that some folks might try to use Alias's to get
by The REF, you can alternately supply a list of NET/NODE numbers
that are UN-AUTHORIZED users. The REF will then look at the
.ORIGIN line of each message and classify any messages that match
a NET/NODE from your list as UN-AUTHORIZED. This is done through
the use of REVIEW_BY_ORIGIN.
You may also look at the message RECEIVER or SUBJECT instead of
the message SENDER or ORIGIN. These options will allow you to
specify UN-AUTHORIZED SUBJECTS or RECEIVERS. In other words if
the SUBJECT or RECEIVER is recognized, The REF will move the
message to an alternate message area for you.
This is done through the use of the following flags:
REVIEW_BY_SUBJECT, REVIEW_BY_RECEIVER.
These are the four available "flags" that are used in REVIEW mode,
REVIEW, REVIEW_BY_SUBJECT, REVIEW_BY_ORIGIN, REVIEW_BY_RECEIVER.
────────────────────────────────────────────
A Brief Discussion of Each "FLAG"
────────────────────────────────────────────
MOVE MOVE messages that *ARE NOT* FROM a User.
The MOVE Flag will read a list of USERS that you supply in
your configuration file. After this list of USERS has
been read, The REF will MOVE any messages that *ARE NOT*
FROM a user in the list.
MOVE_BY_RECEIVER MOVE messages that *ARE NOT* TO a User.
The MOVE_BY_RECEIVER Flag will read a list USERS that you
supply in your configuration file. This flag works very
similar to the MOVE flag, except The REF will look at the
message RECEIVER rather than the message SENDER. After
this list of USERS have been read The REF will MOVE any
messages that *ARE NOT* TO a user in the list.
MOVE_BY_SUBJECT MOVE messages that *ARE NOT* a particular subject.
The MOVE_BY_SUBJECT Flag will read a list SUBJECTS that
you supply in your configuration file. This flag works
very similar to the MOVE flag, except The REF will look at
the message SUBJECT rather than the message SENDER. After
this list of SUBJECTS have been read The REF will MOVE any
messages that *ARE NOT* a particular subject. This flag
in particular will recognize wildcards. If the first
character of your listed SUBJECT is a *, REF will search
for the listed subject as a substring of the actual
message subject. For Example:
Your Specified Subject = *ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject will be recognized as a match and WILL NOT be
moved by the MOVE_BY_SUBJECT parameter.
Example Without Wildcard:
Your Specified Subject = ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject WILL NOT be recognized as a match and WILL
be moved by the MOVE_BY_SUBJECT parameter.
MOVE_BY_ORIGIN MOVE messages that *ARE NOT* FROM a Net/Node.
The MOVE_BY_ORIGIN Flag will read a list of NET/NODEs that
you supply in your configuration file. After this list of
NET/NODEs have been read The REF will MOVE any messages
that *ARE NOT* FROM a one of these NET/NODEs. If you
select this FLAG, The REF will read each message and look
at the .ORIGIN line, comparing them to the list of
Net/Nodes you have supplied. Any messages that ARE NOT
from one of the listed Net/Nodes will be moved to an
alternate message area.
MARK MARK messages that *ARE NOT* FROM a User.
The MARK Flag will read a list of USERS that you supply in
your configuration file. After this list of USERS has
been read, The REF will MARK Bagged any messages that *ARE
NOT* FROM a user in the list. This will prevent any
messages that are UnAuthorized from being bagged.
MARK_BY_RECEIVER MARK messages that *ARE NOT* TO a User.
The MARK_BY_RECEIVER Flag will read a list of USERS that
you supply in your configuration file. This flag works
very similar to the MARK flag, except The REF will look at
the message RECEIVER rather than the message SENDER. After
this list of USERS have been read The REF will MARK Bagged
any messages that *ARE NOT* TO a user in the list. This
will prevent any messages that are UnAuthorized from being
bagged.
MARK_BY_SUBJECT MARK messages that *ARE NOT* a particular subject.
The MARK_BY_SUBJECT Flag will read a list of SUBJECTS that
you supply in your configuration file. This flag works
very similar to the MARK flag, except The REF will look at
the message SUBJECT rather than the message SENDER. After
this list of SUBJECTS have been read The REF will MARK
Bagged any messages that *ARE NOT* on a particular
subject. This will prevent any messages that are
UnAuthorized from being bagged. This flag in particular
will recognize wildcards. If the first character of your
listed SUBJECT is a *, REF will search for the listed
subject as a substring of the actual message subject. For
Example:
Your Specified Subject = *ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject will be recognized as a match and WILL NOT be
marked by the MARK_BY_SUBJECT parameter.
Example Without Wildcard:
Your Specified Subject = ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject WILL NOT be recognized as a match and WILL
be marked by the MARK_BY_SUBJECT parameter.
MARK_BY_ORIGIN MARK messages that *ARE NOT* FROM a Net/Node.
The MARK_BY_ORIGIN Flag will read a list of NET/NODEs that
you supply in your configuration file. After this list of
NET/NODEs have been read The REF will MARK Bagged any
messages that *ARE NOT* FROM a one of these NET/NODEs.
This will prevent any messages that are UnAuthorized from
being bagged. If you select this FLAG, The REF will read
each message and build a list of names that are allowed to
post in the message area. The REF will scan the the
messages in the message area, and dynamically build this
list by looking at the ORIGIN line of each message.
KILL KILL messages that *ARE NOT* FROM a User.
The KILL Flag will read a list of USERS that you supply in
your configuration file. After this list of USERS has
been read, The REF will KILL any messages that *ARE NOT*
FROM a user in the list.
KILL_BY_RECEIVER KILL messages that *ARE NOT* TO a User.
The KILL_BY_RECEIVER Flag will read a list of USERS that
you supply in your configuration file. This flag works
very similar to the KILL flag, except The REF will look at
the message RECEIVER rather than the message SENDER.
After this list of USERS has been read The REF will KILL
any messages that *ARE NOT* TO a user in the list.
KILL_BY_SUBJECT KILL messages that *ARE NOT* a particular subject.
The KILL_BY_SUBJECT Flag will read a list of USERS that
you supply in your configuration file. This flag works
very similar to the KILL flag, except The REF will look at
the message SUBJECT rather than the message SENDER. After
this list of SUBJECTS have been read The REF will KILL any
messages that *ARE NOT* on a particular subject. This
flag in particular will recognize wildcards. If the first
character of your listed SUBJECT is a *, REF will search
for the listed subject as a substring of the actual
message subject. For Example:
Your Specified Subject = *ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject will be recognized as a match and WILL NOT be
killed by the KILL_BY_SUBJECT parameter.
Example Without Wildcard:
Your Specified Subject = ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject WILL NOT be recognized as a match and WILL
be killed by the KILL_BY_SUBJECT parameter.
KILL_BY_ORIGIN KILL messages that *ARE NOT* FROM a Net/Node.
The KILL_BY_ORIGIN Flag will read a list of NET/NODEs that
you supply in your configuration file. After this list of
NET/NODEs have been read The REF will KILL any messages
that *ARE NOT* FROM a one of these NET/NODEs. If you
select this FLAG, The REF will read each message and build
a list of names that are allowed to post in the message
area. The REF will scan the the messages in the message
area, and dynamically build this list by looking at the
ORIGIN line of each message.
REVIEW MOVE messages that *ARE* FROM a User.
The REVIEW Flag will read a list of USERS that you supply in
your configuration file. After this list of USERS has
been read, The REF will MOVE any messages that *ARE*
from a user in the list.
REVIEW_BY_RECEIVER MOVE messages that *ARE* TO a User.
The REVIEW_BY_RECEIVER Flag will read a list of USERS
that you supply in your configuration file. This flag
works very similar to the REVIEW flag, except The REF
will look at the message RECEIVER rather than the
message SENDER. After this list of USERS have been read
The REF will MOVE any messages that *ARE* TO a user in
the list.
ROUTE_VIA_NETMAIL MOVE messages that *ARE* TO a User And Apply the
NET/NODE Address as supplied.
The ROUTE_VIA_NETMAIL Flag works identical as the
REVIEW_BY_RECEIVER except you may also supply a Net/Node
address to place in the message header. This flag will
read a list of USERS that you supply in your
configuration file. After this list of USERS have been
read The REF will MOVE any messages that *ARE* TO a user
in the list. The list is specified somewhat differently
than the other flags. The user list must be configured
as:
Rob Roesch,064/003
Jim Knight,064/001
You must also make sure that the destination message
area as listed in you REF.CNF file is listed as a
Netmail Message area in your GTMDIR.BBS. Unless this
message are is a valid netmail message area this feature
will not work correctly. Please see the example
configurations below for more explanation.
REVIEW_BY_SUBJECT MOVE messages that *ARE* a particular subject.
The REVIEW_BY_SUBJECT Flag will read a list of SUBJECTS
that you supply in your configuration file. This flag
works very similar to the REVIEW flag, except The REF
will look at the message SUBJECT rather than the message
SENDER. After this list of SUBJECTS have been read The
REF will MOVE any messages that *ARE* on a particular
subject. This flag in particular will recognize
wildcards. If the first character of your listed SUBJECT
is a *, REF will search for the listed subject as a
substring of the actual message subject. For Example:
Your Specified Subject = *ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject will be recognized as a match and WILL be
moved by the REVIEW_BY_SUBJECT parameter.
Example Without Wildcard:
Your Specified Subject = ECHOMAIL
Actual Message Subject = 064/003 ECHOMAIL REPORT
This Subject WILL NOT be recognized as a match and WILL
NOT be moved by the REVIEW_BY_SUBJECT parameter.
REVIEW_BY_ORIGIN MOVE messages that *ARE* FROM a Net/Node.
The REVIEW_BY_ORIGIN Flag will read a list of NET/NODEs
that you supply in your configuration file. After this
list of NET/NODEs have been read The REF will MOVE any
messages that *ARE* from a one of these NET/NODEs. If you
select this FLAG, The REF will read each message and build
a list of names that are allowed to post in the message
area. The REF will scan the the messages in the message
area, and dynamically build this list by looking at the
ORIGIN line of each message.
────────────────────────────────────────────
Flag Modifiers
────────────────────────────────────────────
The REF will recognize three distinct modifiers for each of
the FLAGS above. The three modifiers that are recognized are
/INBOUND /OUTBOUND or /RETURN. Please note the /INBOUND and
/OUTBOUND cannot be used simultaneously, but /RETURN may be used
in combination with either of the other two modifiers.
The purpose of the modifiers are as follows:
/INBOUND Process ONLY Inbound messages. If the Incoming flag is
not set and you are using this modifier this message will
be ignored.
/OUTBOUND Process ONLY Outbound messages. If the Incoming flag IS
set and you are using this modifier this message will
be ignored.
/RETURN The RETURN modifier will cause any unauthorized messages
to be RETURNED to the author of the message. The
default for The REF when this modifier is not in use is
to simply move the offending message to an alternate
area leaving the message Sender and Receiver intact.
When this modifier is used the message will be have The
REF x.xx as the Sender and the original author as the
Receiver. The Ref will also extract the .ORIGIN
Net/Node address from the message and address it back to
the sender. This allows you to configure your netmail
message area in the Destination Message Area Path in
your REF.CNF. Please note that this flag is not valid
when using the ROUTE_VIA_NETMAIL flag.
────────────────────────────────────────────
Example Single Section Configuration File:
────────────────────────────────────────────
E:\READONLY READ-ONLY Echo <- Echo Path and Name to Referee
E:\DESTAREA Destination Echo <- Destination Path and Name for Moves
MOVE /RETURN This Is A RO Echo <- Flag, Optional Modifier, and Optional Text
Rob Roesch <-
Jim Wilson <--User List To Search
Jim Knight <-
END <- END to specify END OF LIST
The Configuration File is laid out in sections as shown above.
The above seven lines show ONE section of a complete configuration
files. You are allowed to have as many sections in your config
file as you like, as long as each section ends with an END
statement as shown above. Each section contains five individual
components.
Line 1:
This is the full path and name of the message area to
search for matches. If you do not supply a name here
The REF will title the message area UN-NAMED MESSAGE
AREA.
You may alternately indicate here that you would like
to process GLOBALLY all message areas listed in the
GTMDIR.BBS, or an alternate GTMDIR.BBS. If you would
like to do GLOBAL processing the Pathname is replaced
with the work GLOBAL. If you would like to use a
GTMDIR.BBS other than the one found in the GTPATH
directory you may specify the full path and name of the
file. For example, if you placed the following on the
first line:
GLOBAL
The REF would GLOBALLY process all message areas found
in C:\GT\GTMDIR.BBS
If you placed the following on the first line:
GLOBAL C:\GT\ALTGTMDR.BBS
The REF would GLOBALLY process all message areas found
in C:\GT\ALTGTMDR.BBS.
Line 2:
This is the full path and name of the destination
message area you would like messages to be moved to. If
you do not supply a name here The REF will title the
message area UN-NAMED MESSAGE AREA.
Line 3:
The third line of each section must start with one
"flag", MOVE, KILL, MARK, or REVIEW, MOVE_BY_ORIGIN,
KILL_BY_ORIGIN, MARK_BY_ORIGIN, REVIEW_BY_ORIGIN,
MOVE_BY_RECEIVER, KILL_BY_RECEIVER, MARK_BY_RECEIVER,
REVIEW_BY_RECEIVER, ROUTE_VIA_NETMAIL, MOVE_BY_SUBJECT,
KILL_BY_SUBJECT, MARK_BY_SUBJECT, REVIEW_BY_SUBJECT.
In addition to the "flag" you may specify flag
Modifiers to alter The REF's scrutiny. The available
modifiers are /INBOUND /OUTBOUND or /RETURN. All three
are detailed above.
In addition to the "flag" and optional modifiers, you
may create your own text for The REF to use in the
Header that is applied when the message is moved to an
alternate area. If you do not specify any text here,
the default messages will be used. The default text
that is used is as follows:
DEFAULT REVIEW MODE TEXT:
──────── *** ────────
This Message Was Moved From
Your Message Area Name
For The Purpose of Sysop Examination
By The REF x.x
──────── *** ────────
DEFAULT READ-ONLY MODE TEXT:
──────── *** ────────
This Message Was Moved From
Your Message Area Name
By The REF x.x
──────── *** ────────
If you specify text following the "flag" your message
will be customized with your text. For example if you
place MOVE BECAUSE YOU ARE UNAUTHORIZED on line 3, your
text will look like the following:
──────── *** ────────
This Message Was Moved From
Your Message Area Name
BECAUSE YOU ARE UNAUTHORIZED
By The REF x.x
──────── *** ────────
Line 4-?:
Line four is the start of the "Users List" if you are
using MOVE, KILL, MARK, REVIEW, MOVE_BY_RECEIVER,
KILL_BY_RECEIVER, MARK_BY_RECEIVER, or
REVIEW_BY_RECEIVER, or ROUTE_VIA_NETMAIL.
When using the ROUTE_VIA_NETMAIL you must specify a
net/node destination in the form: Rob Roesch,064/003
Line four is the start of the "Net/Node List" if you
are using MOVE_BY_ORIGIN, KILL_BY_ORIGIN,
MARK_BY_ORIGIN, or REVIEW_BY_ORIGIN. You may have up to
1000 entries in this list.
Line four is the start of the "Subject List" if you are
using MOVE_BY_SUBJECT, KILL_BY_SUBJECT,
MARK_BY_SUBJECT, or REVIEW_BY_SUBJECT. You may have up
to 1000 entries in this list.
If you are using the GLOBAL parameter on line 1 of the
configuration file, you may include EXCLUDE lines for
any message areas that you would like to EXCLUDE: from
processing. For example if you used the following
configuration:
GLOBAL C:\GT\ALTGTMDR.BBS
E:\DESTAREA My Destination Echo
MOVE Because It Was From An Un-Authorized User
EXCLUDE:C:\GTMAIL\GENERAL
Rob Roesch
Jim Knight
END
All message areas found in C:\GT\ALTGTMDR.BBS will be
processed EXCEPT C:\GTMAIL\GENERAL. To EXCLUDE message
areas from the global process simply put
EXCLUDE:<PATHNAME> in the name/netnode listing.
Last Line:
The last line of each section MUST be END. The REF
will continue to read each line as a user name until it
see's END.
────────────────────────────────────────────
Example Multiple Section Configuration File:
────────────────────────────────────────────
The following example uses six individual sections
to create a multiple section configuration file.
E:\READONLY My READ-ONLY Echo
E:\DESTAREA My Destination Echo
MOVE Because It Was From An Un-Authorized User
Rob Roesch
Jim Wilson
Jim Knight
END
E:\GTDIGEST GT-ONE Digest Echo
E:\GTPNSYSOP GT-ONE International Echo
MOVE
Perry Alexander
Bob Butcher
END
GLOBAL C:\GT\ALTGTMDR.BBS
E:\GTMAIL\SEEDS Destination for SEED Messages
MOVE Because I Wanted To Get It Out Of The Way
EXCLUDE:C:\GTMAIL\E02\507
SEED
END
E:\MYECHO My Fabulous Echo
E:\NETMAIL My Netmail Message Area
REVIEW_BY_ORIGIN /RETURN You Are Unauthorized To Use This Echo
064/001
032/001
END
E:\MYNEWECHO My New Echo
E:\NEWREVIEW My New Echo Review Area
REVIEW
Jim Knight
Perry Alexander
END
E:\NETMAIL1 My Netmail #1 Area
E:\NETMAIL2 My Netmail #2 Area
REVIEW_BY_SUBJECT /INCOMING Because I Wanted To Get It Out Of The Way
*ECHOMAIL REPORT
RETURN RECEIPT
END
E:\MYECHO My Echomail Area
E:\NETMAIL My Netmail Area
ROUTE_VIA_NETMAIL
Mike Powell,010/022
END
In the above example there are seven individual message areas that
fall under the scrutiny of The REF. You will also notice that the
first three sections are READ-ONLY sections and the fourth, fifth,
and sixth are REVIEW sections. The last section allows to route
Mike Powell's messages via netmail. Note that the third section
does global processing with an excluded message area. Also note
the use of WildCards when using the REVIEW_BY_SUBJECT flag, and
that INCOMING messages only will be moved.
You may place as many individual echos into this config file as
you find necessary. There is no limit other than available disk
space. The REF will continue to process each file until the End
of File is reached..... The above example shows two echos, but
you can run it with 1 or 5000, it's up to you.....
──────────────────────────────────────────────────────────────
Command Line Parameters
──────────────────────────────────────────────────────────────
Currently there are three, /LOG /NLOG and /REGISTER.
/LOG If you want REF to keep a log file for you put /LOG on the
command line. REF will keep an ever growing log file in
the HOTWARE directory off the GTPATH directory.
/NLOG If you want REF to keep a log file for you, erasing any
old log file that may be setting around, put /NLOG (new
log) on the command line. REF will erase any old log
files, and create a new log file in the HOTWARE directory
off the GTPATH directory.
/C:<ALT_CONFIG>
If you wish to use a Config FIle other than
<GTPATH>\HOTWARE\REF.CNF then you can specify a
/C:<ALT_CONFIG> where <ALT_CONFIG> is the full path and
filename of the file you wish to use for the configuration
file.
/REGISTER Kill Protect will the proceed to send me a netmail message
informing me that you are using the program. Please use
this feature ONCE.
──────────────────────────────────────────────────────────────
ErrorLevel Exits
──────────────────────────────────────────────────────────────
Errorlevel 0: Good run, no Errors.
Errorlevel 1: No GTPATH Environment Variable Set
Errorlevel 2: Cannot open REF.CNF
Errorlevel 3: Insufficient Memory
──────────────────────────────────────────────────────────────
Registration
──────────────────────────────────────────────────────────────
I am not requesting any money for this program, but I would
not turn any down either <g>. If you want to slip $5.00 into
and envelope I'll accept it. Although I don't require a
registration fee I would appreciate knowing that you are using
the program on a normal basis. Therefore I have provided a
simple and easy way for you to register this program. From
the DOS prompt type:
REF /REGISTER
The REF will the proceed to send me a netmail message informing
me that you are using the program. Please use this feature ONCE.
──────────────────────────────────────────────────────────────
Who Is Responsible for This?
──────────────────────────────────────────────────────────────
Rob Roesch
The HOTware BBS
GT Power Net-Node 064/003
Rt 7 Box 566
Mocksville, NC
704-492-2081 (USR 16.8 DS)
If you start using this utility, and get a chance, let me know
(see above procedures. If you don't have any use for it, delete
it for your total refund of all the disk space that it was
occupying, assuming your operating system works right. This
program comes with no warranty, no guarantee, and no promises.
If it works GREAT, if not let me know and I will gladly take a
look at it in my spare time. If you really really really like
the program and want to make any donations, feel free, but it is
not a requirement.....
──────────────────────────────────────────────────────────────
Alternate Distribution Sites
──────────────────────────────────────────────────────────────
The HOTware Utilities now have alternate Distribution
Centers for your convenience. The following BBS always
have the latest and greatest HOTware utilities online and
available for download.
BBS Name BBS Phone Location GT Net/Node Hours
┌──────────────────┬───────────────┬────────────────────┬───────┬──────────┐
│ Laboratory 386 │ 618-549-2322 │ Carbondale IL │064/400│ 10pm-8am │
└──────────────────┴───────────────┴────────────────────┴───────┴──────────┘
