home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Media Share 9
/
MEDIASHARE_09.ISO
/
hamradio
/
mb1501a.zip
/
MB1501A.EXE
/
CONFIG.DOC
< prev
next >
Wrap
Text File
|
1992-11-27
|
29KB
|
903 lines
R:921122/0643 1766@WA7SJN.WA.USA.NA
R:921122/0618 9294@W0RLI.OR.USA.NA
The Configuration Files.
The following files are text files that contain site-specific information.
Edit these files for the proper parameters for your site.
In general:
Fields are delimited by any number of blanks and/or tabs.
Lines beginning with ";" are ignored, may be used for commentary.
Blank lines delimit groups, or are ignored.
A ";" delimits trailing comments on that line.
DIRS.MB - File directory area definitions.
DIST.MB - Bulletin distribution lists.
FWD.MB - Message routing information.
HELP.MB - Help command text.
INFO.MB - Text of the "I" command. System information.
INIT.MB - Information about the system owner.
KEYS.MB - Passwords for remote sysops.
MOTD.MB - Text of the login message.
NEWUSER.MB - Text sent to user at their first login.
PORTS.MB - COM port definitions.
SERVER.MB - Server definition information.
TAG.MB - Your message "signature".
TEXT.MB - Various configurable prompts, messages, etc.
XLATE.MB - Designator translation lists, file-by-BID list, etc.
The following are created and maintained automatically by the MailBox:
BID.MB - Bulletin ID database.
MAIL.MB - Message database.
WP.MB - White Pages database.
YYMMLOG.n - The log files. A text file that contains the user log.
A separate log is kept by each copy of the program.
YYMM is the current year and month.
The form $x is a variable text field. The "$x" is replaced by
the current value for that text.
$A - Total number of MailBox tasks.
$a - Number of active MailBox tasks.
$B - Users home bbs.
$D - The current date.
$H - Hang at end of line (suppress carriage return). Use at end of line only.
$h - Number of held messages.
$I - Sysops name.
$L - Number of the last message in the MailBox
$M - Message number from current msg header.
$m - Number of active messages (total minus killed)
$N - Number of messages on system.
$n - Number of killed messages.
$O - Sysops callsign.
$P - Current Port ID
$Q - Sysops QTH
$T - Current time.
$t - Current task ID.
$U - Users callsign.
$W - Users name.
$X - Date user last logged in.
$Y - Time user last logged in.
$Z - Users zip code.
-----------------------------------------------------------------------------
The File INIT.MB - Sysop Information.
-----------------------------------------------------------------------------
The basic information about the system owner and system operation is
contained in the file INIT.MB. Replace the information with your own.
If you feel you need to change the various WP lifetimes, be very
careful and think through the implications of any such change.
-----------------------------------------------------------------------------
The File MOTD.MB - The Login Message.
-----------------------------------------------------------------------------
The login message is contained in the file MOTD.MB
Variable text fields can be used in MOTD.MB, just as in CONFIG.MB
-----------------------------------------------------------------------------
The File DIRS.MB - File directory areas.
-----------------------------------------------------------------------------
The first field is a single character path ID,
followed by "D" if downloading is allowed, and "U" if uploading is allowed.
The second field is the path, with trailing '\'.
The third field is the name of the path, as shown to the user.
-----------------------------------------------------------------------------
The File XLATE.MB - Translation, file-by-BID, hold lists, etc.
-----------------------------------------------------------------------------
Each line in this section instructs the MailBox to take some action
when it receives some specific kind of message. Each line has several fields.
The first field tells WHAT action to take. The second and following fields
tell HOW to take that action. Note that the character string matches allow
wildcards (See WILD.DOC). If more than one action applies to a given message,
they take place in the order they are given in CONFIG.MB
Action code Meaning
B File message by BID
K Kill after forwarding. Applies to bulletins only.
H Hold any messages TO, FROM, or @ this callsign.
HT Hold any messages TO this callsign.
HF Hold any messages FROM this callsign.
HA Hold any messages @ this callsign.
R <old TO> <old @> <new TO> <new @> - Address translation information.
The 1st or 2nd fields may use wildcard matching (see wild.doc).
A single "*" in the 3rd or 4th fields means "leave unchanged".
T Set time-to-live for this bulletin class.
Examples:
b arl* \bull\arrl\ - File ARRL bulletins by BID.
k sale allusa - Kill SALE and ALLUSA after forwarding.
hf n1nerd - Hold any messages from N1NERD
ht sell - Hold any messages to SELL
r * w0rli * - Remove the "BBS" if it is this BBS.
r * orgb * allor - Any message @ "ORGB" becomes @ "ALLOR".
r sysops * sysop * - Any message to "SYSOPS" becomes to "SYSOP".
r all amsat amsat allusa - Bulletins to ALL@AMSAT become AMSAT@ALLUSA
t wx pdx 2 - Bulletins to WX@PDX will go away in two days.
t * amsat 10 - Bulletins @AMSAT will go away in ten days.
-----------------------------------------------------------------------------
The File DIST.MB - Distribution lists
-----------------------------------------------------------------------------
The file consists of any number of lines, where each line has:
TO AT call1 call2 call2 ...
If a message matches the TO and AT (with wildcards - see wild.doc), then it
will be distributed to the calls listed on the rest of the line. There can
be up to 14 calls per line. If you have more than 14 calls for a single
distribution, simply create two lines. Distribution lists are cumulative.
Note that if you put your own call in the list, the message will
not automatically kill until after you have read it. It will be
"distributed" to you.
The message is not forwarded to the stations in the list any special order.
If a station is busy then the MailBox will try again the next hour.
An "L ;" listing of a message with a distribution list shows the sysop the
status of forwarding to each station on a second "cc:" line. The calls to
which the message have been sent have an asterisk before them.
Distribution list example:
* allor ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn
* allors w7dcr n7dxt wa7shp
* allusa ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn
* allusa w7xyz w7xyz aa7qq
* allusw ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn
* amsat ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn
* open ka7agh kb7dbd wa7sjn
* pdx ka7agh n7chr kb7dbd wa7shp wa7sjn n7vyn
* pnw ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn
* sunami n7hae w7vtw
* wwgb ka7agh n7chr kb7dbd wa7sjn n7vyn
sysop * w0rli
* net ve3gyq w3iwi wb1dsw w0ljf k0jjv ad8i
Things to note:
A message addressed SYSOP @ PNW will hit two distribution lists,
"sysop *" and "* pnw". It will thus get all the calls in both
lists as it's distribution.
The distribution list file is read "fresh" for each message, thus
you can alter it "on the fly" while the system is running, IF your
text editor supports file sharing properly. If it does not, you
may get "sharing violation error" when attempting to write the
file back out from your editor.
-----------------------------------------------------------------------------
The File FWD.MB - Automatic Forwarding.
-----------------------------------------------------------------------------
The file FWD.MB contains information that drives the automatic forwarding
of messages. If the file does not exist, no forwarding is done. Forwarding
is attempted each hour at the minute specified for the port in PORTS.MB.
Forwarding will occur on those hours given in FWD.MB.
FWD.MB consist of a number of lists, and a "forwarding script" associated
with each list. Each list has the information for one MailBox to which you
will forward. The script associated with the list tells your MailBox how
to connect to the MailBox you will forward to. The list contains information
that describes which messages will forward to that MailBox. Each list is
terminated by one or more blank lines.
I have included an example FWD.MB file.
The overall structure of FWD.MB is thus:
Script1
List1
Script2
List2
... etc.
Routing lists.
Each list has a header line, and any number of callsigns, designators, or
sublists. The header line tells the MailBox when to do the forwarding to
that station, what MailBox port to use for the connection, and how to
identify the list when you use the X commands. There can be up to 24
callsigns or designators on each line.
Thus, a list will look like:
fa0023w0qrm
ntsmn ntssd
w0qrm k0cj
or:
fh0205w7xyz
ntswa 98* w7xyz aa7abc
Format of the list header.
Columns Data
1 List type.
2 Port identifier or filler. "A" = COM1, "B" = COM2, etc.
3-4 First hour to do this function.
5-6 Last hour to do this function.
7-12 Key used to select the list with the X or XI commands.
For forwarding lists, this must be the callsign of the MailBox to
forward to, WITHOUT SSID.
For Export/Import lists, the name of the file
to be exported or imported.
List types:
Type Function
E "Answer Reverse Forward Requests"
F "Forward and Reverse Forward"
H "Forward, Reverse Forward, and Poll"
E, F, and H lists are lists of stations for whom you should forward messages.
They are grouped in the list by the call of the MailBox to which the messages
An "F" list is used when you wish to initiate forwarding.
An "H" list acts the same as an "F" list, except that the
connect and probe for reverse forwarding will occur even
if you do not have any messages to forward.
An "E" list acts like an "F" list, except the forwarding is not done,
the list is used only when someone requests reverse forwarding from you.
Connect Scripts.
Connect scripts are supported through C, L, N, P, Q, R, and S items.
The Connect Script precedes the list that uses it. The following are
some examples of common Connect Scripts:
For a direct connect to the MailBox you wish to forward to:
cc n7hae <- Means "connect to n7hae from the tnc"
For a simple NET/ROM connect to the MailBox you wish to forward to:
cc k7zvv-7 <- Means "connect from the tnc (uplink) to your local node"
nc w7fbm-8 <- Means "connect from this node to the distant node"
nc n7hae <- Means "downlink from this node, to the MailBox"
To connect to a distant MailBox running the g8bpq switch, when you are
using the g8bpq switch also just connect to that MailBox call:
nc n7kmj
Summary of script items in FWD.MB
C Connect TO this call FROM a normal tnc.
N Connect TO this call FROM a node.
J Connect TO this call, it is a KA-node.
K Connect TO this call, FROM this KA-node.
P Do this tnc command before connecting.
Q Do this tnc command after disconnecting.
P! Do this DOS command before connecting.
Q! Do this DOS command after connecting.
L Limit forwarding when you use this list.
S Send this text.
R Receive this text.
R! Receive any text.
T Set port timeout (in seconds) for this forward.
M+ Raise RTS.
M- Drop RTS.
W Wait for this many seconds.
Some further examples:
CC W6NR-11
CC N7EQN-10 via A6DIG
NC W6NR
NC W6QRM v N6DIG
P items give TNC commands to be executed BEFORE the connection:
Pretry 10
Pmaxframe 3
Pfrack 8
Q items give TNC commands to be executed AFTER the disconnect:
Qretry 3
Qmaxframe 7
Qfrack 3
Be very careful using P and Q items. The MailBox assumes that the
TNC is setup in a "standard" manner. If you change CR, CP, or SE
in a script, it could cause problems.
An L item is used to place limits on what will forward when the list is used.
L nnnn - Will limit the size of messages forwarded.
L B - Will NOT forward bulletins.
Examples:
L 5000
Would cause any message larger than 5000 bytes to NOT forward.
S and R items are used to forward in unusual situations, so that
you can handle networks which do not use NET/ROM or KA-NODES.
S and R items come in pairs:
An S item is a line to send:
SBBS
An R item is the expected response:
R#SBAY1:N7EQN-10} Connected to #WWORM:WB6FFC-1
In the case that ANY response is valid use:
R!
There can only be one C item in a script, but may be as many N, P, Q, R
and S items as required. As an example, the script for W0RLI
in Santa Cruz using NET/ROM to connect with KA6IQA in San Diego might
be (using all the possible script features).
l 2000 <- Don't forward messages larger than 2K
t 240 <- Use 4 minute timeout for this forward
pretry 10 <- Tough path, retry a lot.
pmaxframe 3 <- And don't send very many packets.
pfrack 8 <- And wait a long time for ACK.
qretry 3 <- Put things back to normal after this forward.
qmaxframe 7 <- Ditto
qfrack 3 <- Ditto
cc w6amt <- Connect to the local NET/ROM
nc w6amt-3 <- Connect to the NET/ROM closest to KA6IQA
nc ka6iqa v w6amt-4 <- Connect to KA6IQA
fb0023ka6iqa <- Use port B. All hours. List name KA6IQA.
ka6iqa <- Forward messages TO or AT KA6IQA
91* <- Forward zip codes starting with 91
Wildcards and special "callsigns" in lists.
When the designator in FWD.MB is compared to the TO or @ BBS call,
the characters '?', '*', '@', '!', '+', '"' in the designator act as
wildcards. See WILD.DOC for an explanation of how to use them.
The callsign "*" is special. Putting it into a list means for forward
all messages not addressed to users of the system. It is a shorthand way
to set up a "local" bbs, which forwards all outgoing traffic to a single
"full service" bbs. If you use this feature, there should be NO other
callsigns or designators in the list.
Sublists.
At any place in the FWD.MB file you can refer to another file. The contents
of the file is treated exactly as if it was in the FWD.MB file. This feature
is very useful when you have several alternate paths to a given location.
FWD.MB need only contain the connect Script for each different path, and a
list containing a reference to the file which contains the list contents.
A sublist file is given by a line starting with "@". The rest of the line is
the device, path, and file name of the sublist.
Example:
NC N4CHV
FC0023N4CHV
N4CHV
@C:\BBS\HF111.FWD
@C:\BBS\SILICON.FWD
NC W6CUS-1
FD0023W6AMT
NI6A
@C:\BBS\SILICON.FWD
Entry qualifiers.
A qualifier is appended to the line it affects. There is one qualifier at
this time: " /TSSEE" where SS is the start hour and EE is the end hour.
This qualifier causes the line to be ignored if the current time is not
within the time window.
-----------------------------------------------------------------------------
The File PORTS.MB - Port Definitions.
-----------------------------------------------------------------------------
There must be a definition for your printer:
Printer type can be one of LPTx, COMx, or NONE
Examples:
Printer NONE
Printer COM5
Printer LPT2
There must a definition for the Console:
Console
Timeout 300
Errlim 20
For each port available to the MailBox, there must be a definition.
The first field is the port type:
Node - This port connects to G8BPQ switch software.
Serial - This port has a modem, computer, or terminal connected.
TNC - This port has an ordinary TNC connected.
The second field is the port identifier.
It is used when you refer to the port in FWD.MB, or use terminal mode.
The 3rd field is the port address or COM number.
Examples:
TNC A 1
Node G 12
Serial L 5
This line is followed by information about how the port is to be used:
Options <xxxx> - A list of characters that give information about the port:
B - Only BBS may connect on this port.
I - Kick off user that connects using illegal call.
N - This port will never be used as alternate for forwarding.
1 - Echo monitored packets to the console.
2 - Echo user data and forwarding to the console.
3 - Echo TNC commands to the console.
Timeout xxxx - Connect timeout, in seconds.
DTimeout xxxx - Disconnect timeout, in seconds.
Maxfwd xxxx - Number of concurrent forwards allowed on this port.
Fwdtime xxxx - Minute of the hour to attempt forwarding.
Note that any value above 59 will disable forwarding on the port.
Errlim xxxx - Number of command errors allowed before user disconnected.
Init xxxx - Command to be sent to TNC at startup.
Examples:
TNC A 1
Options I2NB
Timeout 300
DTimeout 30
Maxfwd 0
Fwdtime 22
Errlim 5
Init echo off
Init flow off
Node D 12
Options I2
Timeout 180
DTimeout 10
Maxfwd 3
Fwdtime 55
Errlim 5
-----------------------------------------------------------------------------
The File SERVER.MB - Definitions for the server.
-----------------------------------------------------------------------------
SERVER.EXE is the main dispatcher for events that happen on
a periodic basis. It drives forwarding, import/export of messages
to external servers such as REQFIL, and does the daily housekeeping.
You must have SERVER running for the system to operate properly.
External Server operation: Automatic Export/Import of messages.
The file SERVER.MB contains information that drives the automatic
Export/Import of messages. If the file does not exist, no Export/Import is done.
There are two types of server; "simple" and "complex".
The information required in SERVER.MB, and the type of processing done,
is slightly different for each type.
Simple Server:
A simple server first checks for messages to export. If there are
none, it does nothing. If there were messages to export, it exports them,
and runs the server process. If the server process completes normally,
then an import is done. If the server process does not complete normally,
no import is done. A line like the one below, placed into SERVER.MB, is
all that is required to define a simple server.
S SNAME SNAME.EXE SNAME.OUT fmt SNAME.IN fmt
"SNAME" is the name of the server. Messages addressed to SNAME or SNAME @ SYSOP
will be processed. SNAME.EXE is the name of the server program to execute.
If the server executable has extension EXE or COM, COMMAND.COM is not loaded.
If the server executable has extension BAT, then COMMAND.COM will be loaded,
and about 23k more memory will be required.
To activate the "echo" server, which reads file ECHO.OUT and
creates file ECHO.IN, with ECHO.EXE in directory \MB :
S ECHO \MB\ECHO.EXE ECHO.OUT H8 ECHO.IN H8
Complex Server:
A complex server first exports any messages that match the designators in
the designator list. Then the server process is run. Then any generated
messages are imported. Note that, unlike a simple server, all three functions
always take place. Thus a complex server can function (for example) to
transfer messages both ways between the MailBox and smtp.
A list like the one below, placed into SERVER.MB, is required to define a
complex server. If the server file extension is EXE or COM, then COMMAND.COM
is not loaded. If the server file extension is BAT, then COMMAND.COM is
loaded, and you must take it's memory requirement into account.
C SNAME SNAME.EXE SNAME.OUT fmt SNAME.IN fmt
list
Messages will be processed according to the list, just as in FWD.MB.
Export, Import, and Execute, with no Server process.
Export Only:
O FILE.OUT fmt
list
Import Only:
I FILE.IN fmt
Execute Only:
! FILE
Summary of list types within SERVER.MB
Item Function
C "Activate a Complex server"
I "Input from File"
O "Output to File"
S "Activate a Simple server"
! "Run program or batch file"
Available format modifiers are:
O - Use the old style "standard" (WA7MBL) export/import format.
8 - Use RFC-822 headers.
H - Include the BBS message headers.
On import, there will be no blank line between existing
headers and the new header created with the new message.
If no modifier is given, then ONLY the message text is put into the file.
To Export messages TO the file MSG.OUT in old (WA7MBL) format :
O MSG.OUT O
WA6XXX
To Export messages TO the file MSG.OUT, with only RFC-822 headers
and message text, (as might be used by a user written smtp interface):
O MSG.OUT 8
WA6XXX
To Export messages TO the file MSG.OUT,
with RFC-822 headers, existing BBS headers, and message text :
O MSG.OUT H8
WA6XXX
To Export messages TO the file MSG.OUT, with only the message text :
O MSG.OUT
WA6XXX
To Import messages FROM the file MSG.IN, which is in "standard" format :
I MSG.IN OH
DOS commands.
A "!" list is a program or batch file to run. A file extension must be given.
If the extension is BAT, the window size must be large enough for COMMAND.COM
as well as the largest program run from the batch file.
Example:
! CLOCK.BAT
This will run CLOCK.BAT, which can do multiple DOS commands.
! CLOCK.EXE
This will load and run CLOCK.EXE
Wildcards and special "callsigns" in lists.
See WILD.DOC for a description of how to use wildcard characters.
Sublists.
At any place in the SERVER.MB file you can refer to another file.
What happens is that the contents of the sublist are treated exactly
as if they were in the SERVER.MB file. A sublist is given by a line
starting with "@". The rest of the line is the device, path, and file
name of the sublist file.
File formats.
The following is an example export file produced using format H8.
Things to note about this file:
1. There is a blank line following the RFC-822 header, and another
following the MailBox header.
2. The special header item "X-msgtype" is used to show whether the
message is a Bulletin, is Personal, or is an NTS message.
3. The special header item "X-BID" is used to show the BID,
if the message has one.
4. The file can contain multiple messages.
Date: 12 Mar 89 17:09 <- Date at originating MailBox
Message-ID: <8988@N6IYA> <- Message number at orig MailBox
X-msgtype: P <- Message type (B, P, T)
X-BID: 1234_N6IYA <- BID, if the message has one.
From: N6IYA@N6IYA <- User at orig MailBox
To: ECHO@W0RLI.OR.USA.NA <- Full location as sent
Subject: Testing path turnaround. <- Message title
<- Blank between RFC-822 hdr and MailBox hdrs
R:890312/1722z @:W0RLI.OR.USA.NA West Linn #:3571 Z:97068
R:890312/1709z @:N6IYA.CA.USA.NA Felton #:8988 Z:95008
<- Blank between MailBox hdrs and text.
Test message. <- Message text.
../EX <- ".." added, not there in actual format
It appears that there will be a large number of servers created.
These are servers I have heard about. Some are ready for use, some
are in the planning/coding stage.
ECHO - "echo" the message back to sender for path testing.
REQDBF - Database server by K0ZXF.
FILEX - "File eXchange". Upload, Download, directory listings.
REQDIR - Request directory information.
The FILEX server handles REQDIR.
REQFIL - Request a file.
The FILEX server handles REQFIL.
REQQSL - Request qsl manger info for dx callsign.
REQWP - Request WP information.
Remote access to the I, I@, IH, and IZ commands.
RLIMON - Automated sysop functions from KJ4LQ.
REQQTH - Request name/address for callsign.
REQCB - Callbook info from the J-Comm or RT Systems databases.
SMTP - smtp/BBS message interface.
Here is an example for a user-written server, using only DOS batch commands.
This server will print selected messages as they arrive.
1. In the distribution lists for any messages you want printed,
add an extra callsign PRTIT.
2. In SERVER.MB add the lines:
! DEL PRTIT.OUT
O PRTIT.OUT 8
PRTIT
! PRINT PRTIT.OUT
-----------------------------------------------------------------------------
The File KEYS.MB - Passwords for Remote Sysops.
-----------------------------------------------------------------------------
Sysop passwords for the MailBox.
Designed by Geert Jan de Groot, PE1HZG, Eindhoven, Holland
Remote sysop is a nice way to split the work involved with managing a
BBS among several people. However, in the past, some crooks used the
calls of some (remote) sysops and erased all files...
I added a netrom-like verification procedure to check if a remote
sysop is really who he says he is.
The procedure is as follows:
Each 'trusted person' has his own personal key, which consists of
an array of 10 by 10 random letters and numbers, like this:
Key for: PE1HZG
01234 56789
0 tBixT 03ytR
10 9yD6s HfC0c
20 ze28q 70nL4
30 7OczX 1fEdW
40 6R8BU cao07
50 OWJ1m lTo2q
60 XLHGl NCDdF
70 2wXUO rjwDL
80 uh7P4 fsYiO
90 mQPjY zXxAM
On the @ command, the BBS gives 3 lines of 8 numbers, like this:
2354 - L#4912 - PI8ZAA-BBS > @ (user gives sysop command)
2 55 26 46 24 52 79 77 (BBS verification )
41 23 94 23 86 56 54 23
75 69 3 97 77 49 64 38
il0aqJLw (user response to 1st line)
N#182 - L#4912 - PI8ZAA-BBS > (success - sysop prompt)
A remote sysop translates ONE (just random, first, second or third) line
into the matching characters using his personal key. Which line matches,
does not matter.
If the sent response-string matches, the user is who he says he is and goes
to remote sysop status. If not, nothing happens.
Bad guys who monitor the BBS, see an answer to 3 possible questions, and
don't know what line matches the response string, so they can't re-build
the key matrix owned by the remote sysop. This, of course, only works
if remote sysops randomly pick the first, second or third line to translate.
(However, using statistics, people can deduce the original key if they
have enough data. Crypt wizards say it may take 100 sessions before
such an attempt may be successful. If you go sysop 1 time a day
at most, and change keys every 2 months, they should not be able to
get sysop status.. time will tell!)
In the BBS, there is a file called KEYS.MB which has records of this
format:
PE1HZG
tBixT03ytR9yD6sHfC0cze28q70nL47OczX1fEdW6R8BUcao07 (continue at next line)
OWJ1mlTo2qXLHGlNCDdF2wXUOrjwDLuh7P4fsYiOmQPjYzXxAM
Each remote sysop has his own entry in the keys.mb file, and should have
different keys. At PI8ZAA, the actual keys are generated by machine,
a small basic program will do the trick.
Of course, NOBODY should EVER consider downloading the KEYS.MB on air!
If a person with a unknown call tries to get sysop status, simply
NO response-string matches. I did this because it was easier and
maybe it keeps the bad guys puzzled..
If the password is a single "*", then that user may become sysop
without any password being required (added by W0RLI).
Note that the port definition in CONFIG.MB must have the "R" privilege
set for remote sysop to be allowed at all, and must have the "P"
privilege set to require passwords.
-----------------------------------------------------------------------------
The File TAG.MB - Message tagging
-----------------------------------------------------------------------------
The file consists of any number of groups, where each group has:
Header line
<any number of text lines>
. <a line containing only a period, this terminates the text>
Header line
<text>
.
etc.
The header line contains a single character to indicate when to apply
the tag, and a list of callsigns, (no more than 15).
The character at the start of the line can be:
L - Apply the tag to locally entered messages (it's your signature).
R - Apply the tag to messages received from these stations.
If any station in the list sends a message, the text following that
header is appended to the message.
For example:
r w3iwi k0jjv n6iya
----------------------------------------------------------
This message received at W0RLI via HF unattended operation.
Please contact your ARRL representatives if you feel this
service is of value to you.
----------------------------------------------------------
.
l w0rli
... Hank
.