The Conference Mail System
By
Bob Hartman
Sysop of FidoNet(tm) node 132/101
(C) Copyright 1986,87,88 Spark Software, Inc.
427-3 Amherst Street
CS 2032, Suite 232
Nashua, N.H. 03061
ALL RIGHTS RESERVED.
Conference Mail System Revision 4.00 August 23, 1988
WHAT IS THE CONFERENCE MAIL SYSTEM?
Conference Mail is a technique to permit several nodes on a
network to share a message base, similar in concept to the
conferences available on many of the computer services, but it is
most closely related to the Usenet system consisting of more than
8,000 systems world wide. All systems sharing a given conference
see any messages entered into the conference by any of the
participating systems. This can be implemented in such a way as
to be totally transparent to the users of a particular node. In
fact, they may not even be aware of the network being used to
move their messages about from node to node! Unfortunately, this
has its disadvantages also - most users who are not educated
about Conference Mail do not realize the messages transmitted
cost MANY sysops (system operators) money, not just the local
sysop. This is an important consideration in Conference Mail and
should not be taken lightly. In a conference with 100 systems as
participants the cost per message can get quite high.
The Conference Mail System is designed to operate in conjunction
with a FidoNet compatible mail server. The currently supported
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
the mail server is a prerequisite to using the Conference Mail
System, it will be assumed you already have your mail server
operating correctly on your system, and you are connected into
FidoNet or a compatible network.
Page 2
Conference Mail System Revision 4.00 August 23, 1988
HISTORY OF THE CONFERENCE MAIL SYSTEM
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
convenient means of sharing ideas with the other Dallas sysops.
He created a system of programs he called Echomail, and the
Dallas sysops' Conference was born.
Within a short time sysops in other areas began hearing of this
marvelous new gadget and Echomail took on a life of its own.
Today, a scant year and a half later, the FidoNet public network
boasts a myriad of conferences varying in size from the dozen-or-
so participants in the FidoNet Technical Standards Committee
Conference to the Sysops' Conference with several hundred
participants. It is not uncommon for a node to carry 30 or more
conferences and share those conferences with 10 or more nodes.
Unfortunately, this incredible growth pointed out limits in the
original Echomail programs. In particular, the processing was
slow, a few 'bugs' surfaced, and more features were needed to
make a sysop's life just a bit easier.
In November of 1986 I (Bob Hartman) began work on the Conference
Mail System, a faster, more powerful system compatible with
Echomail. This system started out as a series of programs called
FastToss, FastKDup and FastScan. The system was relatively bug
free, and provided significantly greater speed than the original
Echomail utilities. It also added functions designed to make
Echomail more attractive to the average sysop.
The current version of Conference Mail has more features, and is
faster than what was known as the FastEcho series of programs.
This newest program is what you have received with along this
documentation..
Page 3
Conference Mail System Revision 4.00 August 23, 1988
HOW IT WORKS
The Conference Mail System is functionally compatible with the
original Echomail utilities. In general, the process is:
1. A message is entered into a designated area on a FidoNet
compatible system.
2. This message is "Exported" along with some control information
to each system "linked" to the conference through the originating
system.
3. Each of the receiving systems "Import" the message into the
proper Conference Mail area.
4. The receiving systems then "Export" these messages, along with
additional control information, to each of their conference
links.
5. Return to step 3.
As you can see, the method is quite simple - in general. Of
course, following the steps literally would mean messages would
never stop being Exported and transmitted to other systems. This
obviously would not be desired or the network would quickly
become overburdened. The information contained in the 'control
information' section is used to prevent transmitting the same
message more than once to a single system.
Page 4
Conference Mail System Revision 4.00 August 23, 1988
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
There are five pieces of control information associated with a
Conference Mail message. Some are optional, some are not.
Normally this information is never entered by the person creating
the message. The following control fields determine how
Conference Mail is handled:
1. Area line
This is the first line of a conference mail message. Its
actual appearance is:
AREA:CONFERENCE
Where CONFERENCE is the name of the conference. This line is
added when a conference is being "Exported" to another
system. It is based upon information found in the AREAS.BBS
(configuration) File for the designated message area. This
field is REQUIRED by the receiving system to "Import" a
message into the correct Conference Mail area.
2. Tear Line
This line is near the end of a message and consists of three
dashes (---) followed by an optional program specifier.
This is used to show the first program used to add Echomail
compatible control information to the message. The tear line
generated by Conference Mail looks like:
--- ConfMail v4.00
This field is optional for most Echomail compatible
processors, and is added by the Conference Mail System to
ensure complete compatibility. Some systems will place this
line in the message when it is first created, but it is
normally added when the message is first "exported."
3. Origin line
This line appears near the bottom of a message and gives a
small amount of information about the system where it
originated. It looks like:
* Origin: The Conference Mail BBS (1:132/101)
The " * Origin: " part of the line is a constant field.
This is followed by the name of the system as taken from the
AREAS.BBS file or a file named ORIGIN located in the DOS
directory of the designated message area. The complete
network address (1:132/101 in this case) is added by the
program inserting the line. This field is generated at the
same time as the tear line, and therefore may either be
generated at the time of creation or during the first
"export" processing. Although the Origin line is not
required by all Echomail processors, it is added by the
Conference Mail System to ensure complete compatibility.
Page 5
Conference Mail System Revision 4.00 August 23, 1988
4. Seen-by Lines
There can be many seen-by lines at the end of Conference
Mail messages, and they are the real "meat" of the control
information. They are used to determine the systems to
receive the exported messages. The format of the line is:
SEEN-BY: 132/101 113 136/601 1014/1
The net/node numbers correspond to the net/node numbers of
the systems having already received the message. In this way
a message is never sent to a system twice. In a conference
with many participants the number of seen-by lines can be
very large. This line is added if it is not already a part
of the message, or added to if it already exists, each time
a message is exported to other systems. This is a REQUIRED
field, and Conference Mail will not function correctly if
this field is not put in place by other Echomail compatible
programs.
5. PATH Lines
These are the last lines in a Conference Mail message and
are a new addition, and therefore is not supported by all
Echomail processors. It appears as follows:
^aPATH: 132/101 1014/1
Where the ^a stands for Control-A (ASCII character 1) and
the net/nodes listed correspond to those systems having
processed the message before it reached the current system.
This is not the same as the seen-by lines, because those
lines list all systems the message has been sent to, while
the path line contains all systems having actually processed
the message. This is not a required field, and few echomail
processors currently support it, however it can be used
safely with any other system, since the line(s) will be
ignored. For a discussion on how the path line can be
helpful, see the "Advanced Features" section of this manual.
Page 6
Conference Mail System Revision 4.00 August 23, 1988
SETTING UP THE CONFERENCE MAIL SYSTEM
To set up the Conference Mail System, the following steps must be
followed:
1. Have a working FidoNet compatible system using the message
format described by the FidoNet Technical Standards Committee
(FTSC) in the document FSC001. This basically means TBBS systems
cannot use the Conference Mail System since they do not have a
message base of the appropriate format. Systems known to work
with the Conference Mail System are listed in the "What is
Conference Mail?" section of this manual.
2. Determine the conferences you would like to start, and the
conferences you would like to receive. A good place to start is
by looking for a file called ECHOLST.ARC on your local bulletin
board already running an Echomail compatible system. This list
contains information on tying into over 100 known conferences are
already popular throughout FidoNet.
3. Set up a directory for messages for each of the separate
conferences. Yes, you read correctly - one directory for each
conference. If you do not create individual directories, then you
will run into a problem known as "cross-linking" a conference.
This means the information from one conference will end up
intermingled with another. Although this is sometimes desirable,
generally it causes severe backlash at the person responsible.
For example, imagine if the two areas accidentally cross-linked
were the BLACK_MAGIC and BIBLE areas. Needless to say there would
be an uproar in the conference getting material originally
destined for the other conference. Unfortunately, this happens
all too often, and even the most experienced Conference Mail
wizards will make this mistake. Refer to the documentation for
your FidoNet compatible system for how to make this directory
accessible to the system.
4. Set up the AREAS.BBS configuration file for your system and
the conferences you wish to receive (see the section entitled
"Configuration (AREAS.BBS) file). This file must be in the
correct format, and should be thoroughly tested on a small scale
before linking to any large conferences.
5. Alter your batch files to make the appropriate calls to the
Conference Mail system for importing, exporting and maintaining
the message bases. Samples batch file sections are given in the
section entitled "Batch File Examples".
Page 7
Conference Mail System Revision 4.00 August 23, 1988
6. Set up conference links with other systems for the conferences
you are interested in. To do this, simply send a netmail message
to the other system requesting to tie into the conference in
question. If the sysop does not carry the conference they can
usually point you in the right direction. Remember when setting
up links, local calls are preferred since Conference Mail can
generate large phone bills if taken to extremes. Also be careful
of conference "topology" (see the section entitled "Conference
Topology" for more details). Also determine with the other sysop
if "ARCmail" is to be used or not (ARCmail is discussed in the
section entitled "Methods of Sending Conference Mail").
If all of these procedures are followed, then the result should
be a fully operational Conference Mail System.
Page 8
Conference Mail System Revision 4.00 August 23, 1988
CONFIGURATION (AREAS.BBS) FILE
The Configuration File for the Conference Mail System is usually
called AREAS.BBS. It may be called any name, but AREAS.BBS is
used for historical reasons. The file has 4 parts:
1. Comment lines - these lines may appear anywhere in the file.
They are blank lines, or start with a semi-colon (;).
Historically there is one other special type of comment line
starting with a dash (-). The Conference Mail System uses some of
the dash lines as "special command" lines (see number 3 below).
2. Board name ! Sysop name - this line is the first line of the
file other than comment lines. This line is used by the
Conference Mail System when it generates an Origin line (see
section entitled "How it Works"), and also the name to be
substituted for Sysop when it is found in the FROM field of a
message. The format of the line is free format with the board
name and sysop name separated by an exclamation point (!). The
zone:net/node will be appended to this information, so it should
never appear in the file itself. For example:
The Conference Mail BBS ! Bob Hartman
might expand to:
* Origin: The Conference Mail BBS (1:132/101.1)
3. Special Commands - these lines begin with a dash (-) and are
followed by a special keyword. The supported keywords (discussed
in the "Advanced Features" section) are:
All versions:
ZONEGATE
PASSWORD
"Point" versions:
POINTNET
BOSSNODE
4. Conference lines - All other lines in the file fit into the
category of Conference lines. These lines have a very special
format as follows:
Directory Area Nodes
Each line has the same format, although each line may use the
following format pieces differently:
Directory - this may be either a path name (easiest and
recommended method) or it may be a Fido/Opus area number.
Area - This is the label associated with the Conference. It is
important to have this spelled correctly (upper/lower case does
not matter) since incorrectly spelled area names will not be
recognized.
Page 9
Conference Mail System Revision 4.00 August 23, 1988
Nodes - These are the nodes sharing the conference. The format is
a list of net/node numbers for each node. If the net number is
the same for two consecutive nodes, then the net number and slash
(/) may be deleted for the second number. For example, both of
the following are equivalent (the first node number must have an
associated net number):
132/101 132/107 132/555 136/601
132/101 107 555 136/601
The entire list of nodes is optional for a conference - it is
often desirable to have an area called GENERAL and another called
PRIVATE with no links listed in order to get general or private
mail from other boards running compatible software (this is
considered standard practice, although as some users have said
"You may go a lifetime and never see anyone use this feature on
your system, but the capability is there"). On a system running
"secure" Conference Mail (see section entitled "Advanced
Features"), this is not recommended.
Sample Configuration (AREAS.BBS) File:
; The first line that is not a comment line is the
; Board Name ! Sysop Name line. This MUST appear or
; the Conference Mail System will not function correctly
The Conference Mail BBS ! Bob Hartman
; The next section of lines is my "special command"
; section. It gives examples of the use of three
; "special" commands. This is actually the
; setup for a possible "point server" node. For a
; "point" itself, the POINTNET line would be changed
; to a BOSSNODE line as in "-BOSSNODE=132/101". Note
; the dash (-) is in column 1 (this is important)
; and there are no spaces until after the number
; following the equal sign (=).
-POINTNET=1014
-ZONEGATE=3/1 1/3 105/30
-PASSWORD=1014/1 ConfMail
; Now come all of the Conference Lines:
; Directory Area Node 1 Node 2 Node 3 Node 4
C:\MSG\PRIVATE PRIVATE
C:\MSG\GENERAL GENERAL
C:\MSG\SYSOP SYSOP 132/101 136/601 107/312 1014/1
C:\MSG\TECH TECH 132/101 136/601 107/312 1014/1
C:\MSG\POINT POINT 1014/1
C:\MSG\NESYSOP NESYSOP 132/101 1014/1
; The above lines are in columns simply to be pleasing
; to the eye. It is not necessary, but it does make
; changing the lists much easier. The column headings
; are also given for clarity and are not required.
Page 10
Conference Mail System Revision 4.00 August 23, 1988
METHODS OF SENDING CONFERENCE MAIL
To this point the issue of how Conference Mail is actually sent
has been glossed over entirely. The phrase has been, "the message
is exported to another system." What exactly does this mean?
Well, for starters lets show what is called the "basic" setup:
In this setup exported mail is placed into the FidoNet mail area.
Each message exported from a Conference Mail area has one
message generated for each receiving system. This mail is then
sent the same as any other network mail. When Echomail was first
created this was the only way mail could be sent.
The "basic" method has some disadvantages. First, since Echomail
has grown so large it is not uncommon to get 200 new messages per
day imported into various message bases. It is also not uncommon
for a system to be exporting messages to 4 or 5 other systems.
Simple arithmetic shows 800-1000 messages per day would be sent
in normal netmail! This puts a tremendous strain on any netmail
system, not to mention transmission time and the resultant phone
charges. When this limitation of Echomail was first noticed a lot
of people started scratching their heads wondering what to do. If
a solution could not be found it appeared Echomail would
certainly overrun the capabilities of FidoNet.
Thom Henderson (from System Enhancement Associates) came up with
the original ARCmail program. Having previously written the ARC
file archiving and compression program, he knew the savings
achievable by having all of the netmail messages placed in .ARC
format for transmission. As a byproduct, the messages no longer
appeared in the netmail area, but were included in a file
attached to a message (see your FidoNet mailer manual for file
attaches). In this way the tremendous number of messages
generated, and the phone bill problems were both solved.
Unfortunately, ARCmail required the messages to first be placed
into the netmail area before it could be run. In effect, it
caused the messages to be scanned once when they were exported,
once during the ARCmail phase, once when ARCmail was run at the
other end to get the messages out of .ARC format, and once when
those messages were later imported into a message base on the
receiving system. The Conference Mail System solves this problem
by eliminating the ARCmail program. Conference Mail builds the
ARCmail files during Export, and unpacks them during Import. This
way messages are exported directly to ARCmail style file
attaches, and imported directly from ARCmail style file attaches.
The scanning phases between importing and exporting messages are
totally removed and processing time is proportionally reduced.
This is now the most common method for sending Conference Mail
between systems. The overhead involved in doing it during the
importing and exporting phases is much less than what is involved
if ARCmailing is not utilized. This was a primary consideration
in the design and implementation of the Conference Mail System,
and as a result the entire system is optimized for this type of
use. Please refer to the Import and Export functions for
specifics on how to use the ARCmailing feature.
Page 11
Conference Mail System Revision 4.00 August 23, 1988
CONFERENCE TOPOLOGY
The way in which systems link together for a particular
conference is called the "conference topology." It is important
to know this structure for two reasons: 1) It is important to
have a topology which is efficient in the transfer of the
Conference Mail messages, and 2) It is important to have a
topology which will not cause systems to see the same messages
more than once.
Efficiency can be measured in a number of ways; least time
involved for all systems to receive a message, least cost for all
systems to receive a message, and fewest phone calls required for
all systems to receive a message are all valid indicators of
efficiency. Users of Echomail compatible systems have determined
(through trial and error) the best measure of efficiency is a
combination of all three of the measurements given above.
Balancing the equation is not trivial, but some guidelines can be
given:
1. Never have two systems attempting to send Conference mail
to each other at the same time. This results in "collisions"
that will cause both systems to fail. To avoid this, one
system should be responsible for polling while the other
system is holding mail. This arrangement can alternate based
upon various criteria, but both systems should never be
attempting to call each other at the same time.
2. Have nodes form "stars" for distribution of Conference
Mail. This arrangement has several nodes all receiving their
Conference Mail from the same system. In general the systems
on the "outside" of the star poll the system on the
"inside". The system on the "inside" in turn polls other
systems to receive the Conference Mail that is being passed
on to the "outside" systems.
3. Utilize fully connected polygons with a few vertices.
Nodes can be connected in a triangle (A sends to B and C, B
sends to A and C, C sends to A and B) or a fully connected
square (all corners of the square send to all of the other
corners). This method is useful for getting Conference Mail
messages to each node as quickly as possible.
Page 12
Conference Mail System Revision 4.00 August 23, 1988
All of these efficiency guidelines have to be tempered with the
guidelines dealing with keeping duplicate messages from being
exported. Duplicates will occur in any topology that forms a
closed polygon that is not fully connected. Take for example the
following configuration:
A ----- B
| |
| |
C ----- D
This square is a closed polygon that is not fully connected. It
is capable of generating duplicates as follows:
1. A message is entered on node A.
2. Node A exports the message to node B and node C placing
the seen-by for A, B, and C in the message as it does so.
3. Node B sees that node D is not listed in the seen-by and
exports the message to node D.
4. Node C sees that node D is not listed in the seen-by and
exports the message to node D.
At this point node D has received the same message twice - a
duplicate was generated. Normally a "dup-ring" will not be as
simple as a square. Generally it will be caused by a system on
one end of a long chain accidentally connecting to a system on
the other end of the chain. This causes the two ends of the chain
to become connected, forming a polygon.
In FidoNet this problem is reduced somewhat by having "Regional
Echomail Coordinators" (RECS) that try to keep track of Echomail
connections within their regions of the world. A further rule
which is followed is that only the RECS are allowed to make
inter-regional connections for the larger conferences. In return,
the RECS have established a very efficient topology which gets
messages from coast to coast, and onto over 200 systems in less
than 24 hours. If no one were willing to follow the rules, then
this system would collapse, but due to the excellent efficiency
it has remained intact for over a year.
Page 13
Conference Mail System Revision 4.00 August 23, 1988
ADVANCED FEATURES
Special AREAS.BBS Commands (all versions of Conference Mail)
PASSWORD
The format for this line is:
-PASSWORD=net/node password
where 'net/node' is the net/node number of the system using
this password, and 'password' is up to 8 characters of a
password. This option is currently only supported by the
Conference Mail System. The method used for this feature has
been approved by the FidoNet Technical Standards Committee
(FTSC), and should start appearing in other Echomail
processors in the future. Up to 100 systems can be given
passwords by having a separate -PASSWORD= line for each one.
If Conference Mail is received in ARCmail format from a
system listed on a -PASSWORD= line, the ARCmail packet will
be checked for the proper password, and if the password is
missing, or incorrect the packet will be renamed and a
message generated to alert the sysop. ARCmail created for a
node listed on a -PASSWORD= line will be generated with the
password in place, so the receiving system should also have
the same password in place in their AREAS.BBS file. This is
part of the security discussed more fully in the section
entitled "Creating a Secure Environment."
ZONEGATE
The format for this line is:
-ZONEGATE=a/b c/d e/f ...
where 'a/b' is the net/node number of the system that is the
"zonegate" and 'c/d e/f ...' are the net/node numbers to be
listed in the seen-by lines of messages exported to the
"zonegate." This option is primarily used to keep
transmission costs down by deleting seen-bys for systems
that are not in the same "zone". If a message goes through a
"zonegate" it can never return except through the same
"zonegate", hence all seen-bys for the original zone can
safely be removed. This option allows this, as well as
specifying a extra seen-bys to be listed in case the
PASSTHRU option is also being used (see the section entitled
"Using the Passthru Option").
Page 14
Conference Mail System Revision 4.00 August 23, 1988
Special AREAS.BBS Commands ("Point" versions of Conference Mail)
POINTNET
This format for this line is:
-POINTNET=net
Where 'net' corresponds to the net number of the private net
which is used to support "points." This option should ONLY
be used on a system supporting points, and never on an
actual point. This option strips all occurances of the
private net number from appearing in the seen-by lines of
messages exported to other systems. This is necessary since
many nodes might have the same private network number for
the points that they service, and seen-by lines generated on
one system might cause points on another system to not
receive the messages.
BOSSNODE
The format for this line is:
-BOSSNODE=net/node
where 'net/node' is the net/node number of the system which
acts as a point server. This option should ONLY be used on a
system which is a point. It causes the Origin line to
contain a fully qualified network address as:
zone:net/node.point
rather than the usual:
zone:net/node
The fully qualified address is generated as follows:
zone - from the zone in the CONFIG.DOG file, otherwise
it defaults to zone 1.
net - from the net listed on the -BOSSNODE= line.
node - from the node listed on the -BOSSNODE= line.
point - from the node listed in the primary address
found in the system information file (see section
entitled "Required Files").
For example, if the primary address is 1:1014/1, and the
line -BOSSNODE=132/101 appeared in the AREAS.BBS file, then
the fully qualified address would be 1:132/101.1
Page 15
Conference Mail System Revision 4.00 August 23, 1988
Creating a "Secure" Environment:
For the purposes of this section, a "secure" system will be
defined as: one accepting echomail only from sources which can be
verified. In other words, a "hacker" cannot enter echomail
messages without getting caught.
In order to create a secure system, the ways in which a "hacker"
can enter echomail messages without being detected have to be
identified and countered:
1. The first (and most commonly used method) is to create a
regular Fidonet mail message to a node running echomail.
This message is created with the various echomail control
information lines in place. When the receiving system gets
the message it imports it into a message area based on the
AREA: line, and the "hacker" has successfully entered an
echomail message. The Conference Mail System stops this
problem with the -M option for the Import function. A
regular netmail message will never be imported.
2. The second method is by sending ARCmail file attaches.
Again, the receiving system will unpack the ARCmail and
import it into the message areas based on the AREA: lines.
This is addressed by the -S option for the Import function.
If the system sending the message does not appear in the
AREAS.BBS file for the conference, the message is redirected
to the netmail area for the sysop.
3. The third method is to send ARCmail file attaches with a
net/node number that is known to be in the AREAS.BBS file.
This would not get caught by the checking done to stop
number 2, and therefore is the most difficult to detect. The
Conference Mail System addresses this by allowing ARCmail
packets to have an associated password. The sysops of the
two systems exchanging mail decide upon a password and if it
is not present in the ARCmail, then the secure system will
rename the packet and alert the sysop to what transpired.
If the combination of the Import -S and -M options as well as
passwording is used, the system is secure. Because "hackers" are
always thinking up new ways to break into systems, Conference
Mail goes one step further - identifying the perpetrator. When a
message is being exported, it is analyzed, and if it has traits
which tend to make it look like a locally originated message, yet
it was not entered locally, the phrase ' Of net/node' is appended
to the "From:" field of the message. For example, if a message is
being exported that falls into this category, and it is from
"Scott Tissue", the exported messages will be appear to be from
"Scott Tissue Of net/node" where net/node is the net/node number
of the system which sent the message.
Having the ability to impersonate anyone else when sending an
echomail message has been abused within FidoNet. This abuse led
to the security features mentioned above being made integral to
the design of the Conference Mail System. Do not underestimate
what might happen to you! When possible, implement security.
Page 16
Conference Mail System Revision 4.00 August 23, 1988
Why a PATH line?
As was previously mentioned, the PATH line is a new concept in
Echomail. It stores the net/node numbers of each system having
actually processed a message. This information is useful in
correcting the biggest problem encountered by nodes running an
Echomail compatible system - the problem of finding the cause of
duplicate messages. How does the PATH line help solve this
problem? Take the following path line as an example:
^aPATH: 107/6 107/312 132/101
This shows the message was processed by system 107/6 and
transferred to system 107/312. It further shows system 107/312
transferred the message to 132/101, and 132/101 processed it
again. Now take the following path line as the example:
^aPATH: 107/6 107/312 107/528 107/312 132/101
This shows the message having been processed by node 107/312 on
more than one occasion. Based upon the earlier description of the
'information control' fields in Echomail messages, this clearly
is an error in processing (see the section entitled "How it
Works"). This further shows node 107/528 as the node which
apparently processed the message incorrectly. In this case the
path line can be used to quickly locate the source of duplicate
messages.
In a conference with many participants it becomes almost
impossible to determine the exact topology used. In these cases
the use of the path line can help a coordinator of the conference
track any possible breakdowns in the overall topology, while not
substantially increasing the amount of information transmitted.
Having this small amount of information added to the end of each
message pays for itself very quickly when it can be used to help
detect a topology problem causing duplicate messages to be
transmitted to each system.
Page 17
Conference Mail System Revision 4.00 August 23, 1988
Special Situations:
The Conference Mail System can handle a number of special
situations. Points and security are two situations already
mentioned. Other situations are "passthru", "bad messages",
"routed conferences", "splitting" a conference, and "merging" a
conference.
Passthru:
The ZONEGATE special AREAS.BBS command has already been
mentioned, but there is one more special feature of
Conference Mail that can be utilized by zonegates. This is
the ability to "passthru" echomail areas without having to
retain them. This feature is triggered by a special area
name of "PASSTHRU" listed in the AREAS.BBS file, along with
systems to be linked with the area. The PASSTHRU area works
as follows:
1. All messages that have an unrecognized AREA: line
are imported into the PASSTHRU area. The original
AREA: line is left intact (normally Import will remove
the AREA: line when placing a message in a regular
Conference Mail message base).
2. Export processes the PASSTHRU area like any other
area, with one exception: it does not add an AREA: line
to the messages since the line is already there.
3. Export does not update the seen-by lines in the
messages that are retained in the PASSTHRU area.
These three items allow messages to simply pass thru a
system that is functioning as a zone gateway. The systems
on each side of the zone gateway can add areas, and never
have to inform the zone gateway.
This function is designed ONLY for zone gateways. Other uses
should be carefully thought out before implementation.
Page 18
Conference Mail System Revision 4.00 August 23, 1988
Bad Messages:
Another special feature of the Conference Mail System is the
ability to have "bad messages" placed in a special area.
This allows the sysop to analyze the messages to see what
the problems are, and then to fix them. This feature is
triggered by a special area name of "BAD_MSGS" listed in the
AREAS.BBS file. The BAD_MSGS directory will contain any
messages that could not be tossed for some reason (other
than a bad password). Possibilities are:
1. An uknown area name.
2. The message is a duplicate of one of the last 1000
messages in the area.
3. The message is from a node that is not listed in the
AREAS.BBS file, and secure operation was enabled.
Routed Conferences:
It is not uncommon for conference messages to be routed
rather than being sent directly to the destination. This
practice is frowned upon unless the system being used for
the routing confirms that it is alright. A situation like
this can occur if a conference distributor has a "free"
phone line and can send to other nodes at a lower cost than
sending the conferences directly. The ROUTETHRU area name
is a special name reserved for this purpose. If a
conference message is received, and it is not addressed to
the current node, it is then placed in the directory
associated with the ROUTETHRU area name. When this area is
exported, the net/node number of the receiving system is
taken from the message header, rather than the AREAS.BBS
file, or the SEEN-BY lines. This is generally a useful
option for network hosts to use.
Merging a Conference:
In the section entitled "How Conference Mail Works", mention
was made to "cross-linking" areas, and how undesirable it
was. This section deals with the special case when it is not
undesirable. One such situation arises when a conference is
being disbanded in favor of another conference on the same
topic. In this case it is desirable to have the two
conferences merged together for a period of time. The
Conference Mail System can handle this situation by listing
the same message directory with two or more different area
names in the AREAS.BBS file. For example, to merge together
the TURBO_PASCAL and PASCAL conferences, the following lines
would appear in the AREAS.BBS file used by Import:
C:\MSG\PASCAL TURBO_PASCAL 107/312 136/601
C:\MSG\PASCAL PASCAL 114/15 161/1
Extreme care should be used when deliberately cross-linking
a conference.
Page 19
Conference Mail System Revision 4.00 August 23, 1988
Splitting a Conference:
Another special case arises when two systems want to call
the same conference by different names. The Conference Mail
System can handle this situation the same way it handles
splitting conference. The example given above could also be
used by the AREAS.BBS file used for Export. It would split
the conference into two conferences called TURBO_PASCAL
received by 107/312 and 136/601, and PASCAL received by
114/15 and 161/1.
Page 20
Conference Mail System Revision 4.00 August 23, 1988
CONFERENCE MAIL COMMAND SUMMARY
In General:
The Conference Mail System is driven by a single program
contained in the executable file CONFMAIL.EXE. All of the tasks
for the Conference Mail System are actually performed by many
sub-functions. In the section entitled "Conference Mail Sub-
Function Summary", all sub-function names should be preceded by
the program name. For example:
Import -N
should be given on the command line as:
ConfMail Import -N
There is one special case where this is not true: The ConfMail
program is capable of taking its input parameters from a "command
file." The sub-function calls in this command file are NOT
preceded by the name 'ConfMail'. To utilize this ability it is
necessary to call the ConfMail program with a second argument of
'FILE' and the third argument being the filename to use as a
command file. Additional arguments are numbered sequentially,
and can be used as %1 thru %9 in the command file. For example:
ConfMail FILE ConfMail.CMD 10 ConfMail.Dat
Where ConfMail.CMD may contain any valid ConfMail sub-function
calls such as:
Import -N -F %2 -A PKXARC
Export -A PKXARC
Any number of ConfMail Sub-function calls may be executed. The
command file is only aborted if there is an abnormal error in
processing for any of the functions.
Page 21
Conference Mail System Revision 4.00 August 23, 1988
Required Files:
System Information File:
The Conference Mail System requires a system information
file to be present. This file is called either MAIL.SYS in
the current directory (Fido systems), or a file called
CONFIG.DOG in the directory named by the SEADOG environment
variable or the current directory.
In the case of MAIL.SYS, Fido creates and maintains this
file for you (refer to the Fido documentation).
The CONFIG.DOG file should contain the following:
NODE zone:net/node
The zone:net/node of the system
MAIL mailpath
mailpath corresponds to the directory containing
the FidoNet mail area.
FILES filepath
filepath corresponds to the directory used to
store incoming FidoNet files.
AKA net/node
This statement is not required, but if present
gives alternate net/node numbers for the system,
and will include, by default, the first AKA
net/node address in the seen-by lines of exported
messages.
Any other statements in the file area ignored.
If your system does not have a MAIL.SYS file, then it will
be necessary to create a CONFIG.DOG file using the
statements given above. The Conference Mail System will not
function without one or the other. The CONFIG.DOG file takes
precedence if both exist.
Origin Line Files:
When the Conference Mail System exports a message that does
not have an Origin line, one is appended. This line is
normally formed from the 'board name' section of the
AREAS.BBS configuration file being used. This default can be
overridden by having a file named 'ORIGIN' in the DOS
directory containing the messages for a conference. When a
message in the conference needs to have an Origin line
appended it will then be taken from the first line of the
ORIGIN file.
Page 22
Conference Mail System Revision 4.00 August 23, 1988
Message Identification Database:
This is a file named CONFDUPS.DAT that is present in each
conference mail message directory. IT SHOULD NEVER BE
DELETED. This file contains identification information for
the last 1000 messages to appear in the conference, and it
is used by the Import sub-function to delete duplicate
messages before they appear in the conference. It is
maintained by the Import sub-function, and should never be
altered or deleted. It will take up approximately 10K bytes
(the size of 5 average messages) in each conference
directory.
Page 23
Conference Mail System Revision 4.00 August 23, 1988
CONFERENCE MAIL SUB-FUNCTION SUMMARY
IMPORT:
Function:
Receives Conference Mail messages and places them into the proper
message base (if they are not duplicates of earlier messages).
Format:
Import [afile] [-K] [-N or -O] [-M] [-S] [-F file]
[-D num_dups] [-A [ARC_cmd]]
Options:
afile
This is the name of the AREAS.BBS file to use for this run.
-K
Delete NULL messages rather than imported them.
-N or -O
Specifies imported messages should have their date formats
changed to the new Opus 1.0 format (-N option), or the older
Fido format (-O option). The default is to do no conversion.
-M
Messages will NOT be imported from the network mail
directory. This option is useful for a "secure" environment
(see the section entitled "Advanced Features"). The default
is to Import messages from the network mail area.
-S
Import will operate in "secure" mode. This means messages
will not be imported to Conference Mail message bases unless
the sending node is listed as a recipient of the conference;
the messages will be placed into the Fidonet mail area
instead. This option is useful for a "secure" environment
(see the section entitled "Advanced Features").
-F file
Each Conference Mail area having a message imported to it
will have the area name listed in the file named 'file'.
This is for correlating the workings of Import and Maint.
Page 24
Conference Mail System Revision 4.00 August 23, 1988
-D num_dups
Allow for killing duplicates based on the last 'num_dups'
messages received in each area. The default for num_dups is
1000, and should only be decreased. If the default is
increased, there is a very good chance that not enough
memory will be present in the default 64K data space, and
the program will exit with a warning.
-A [ARC_cmd]
Import will attempt to extract ARCmail files. The ARC_cmd
parameter will be used as the command to unARC, and if not
given will default to 'ARC X'. This option MUST be last on
the command line, and everything following the -A is taken
as the unARC command.
Errorlevels returned:
0 - No messages imported
1 - Messages were imported
2 - Severe error in processing
Examples:
To import messages without date conversion, and to extract
ARCmail using the ARC command:
Import -A ARC X
To import messages in Opus 1.0 format from the netmail area only:
Import -N
To import messages in Opus 1.0 format and also extract ARCmail
using the PKXARC program:
Import -N -A PKXARC
To use the file AREAS1.BBS for Importing, create a list of areas
having messages Imported into them, and to extract ARCmail (using
the default of 'ARC X'):
Import AREAS1.BBS -F Conf.Out -A
Maximum security operation of Import using ARCE to extract the
ARCmail files:
Import -M -S -A ARCE
Page 25
Conference Mail System Revision 4.00 August 23, 1988
EXPORT:
Function:
Prepares messages for transmission to other systems sharing the
Conference.
Format:
Export [afile] [-0/1] [-M #] [-K] [-S #] [-C] [-H]
[-T] [-I] [-Q] [-R] [-G] [-NF/P] [-O dir]
[-P dir] [-D dir] [-F file] [-A ARC_cmd]
Options:
afile
This is the name of the AREAS.BBS file to use for this run.
-0 or -1
Use either the primary (0) or alternate (1) set of high
water marks. This can be used in instances where two
AREAS.BBS files are useful. One such instance occurs when
some nodes receiving a conference wish to receive ARCmail,
and other nodes do not want ARCmail.
-M #
Export messages until '#' of messages have been exported.
The Conference Mail System will completely export a message
before stopping, so this number may be exceeded by a few
messages.
-K
Use the International FidoNet Association (IFNA) endorsed
"kludge" of hiding the AREA and SEEN-BY lines behind a
Control-A character. This option should not be used by
systems which must communicate with older echomail
compatible systems.
-S #
Add '#' AKA addresses to the seen-by lines. This number does
not include the primary address which is always included in
the seen-by lines. The default is to have 1 AKA included.
-C
Set the CRASH bit on messages and ARCmail file attaches.
-H
Set the HOLD bit on messages and ARCmail file attaches
Page 26
Conference Mail System Revision 4.00 August 23, 1988
-T
Strip the seen-by list down to a 'tiny' subset. This list
consists of the current system, plus any conference links
the system maintains. For example:
System 132/101 maintains links with 107/312 and 136/601
in the SYSOP conference. A message is being exported
from that conference, and the current seen-by list is:
SEEN-BY: 107/6 107/312 107/528 120/38 133/1
The new seen-by list would be:
SEEN-BY: 107/312 132/101 136/601
This option should be used with EXTREME care. It can cause a
topology which had not been generating duplicate messages to
suddenly start generating them. See the section entitled
"Troubleshooting" for more information.
-I
Use internal ARCmailing on Opus systems.
-Q
Operate in "quiet" mode.
-R
Send private conference replies via netmail. This option
will cause messages that are replies to previous messages,
and also marked private to be sent via netmail, rather than
being exported as a normal Conference Mail message. This is
useful for a conference coordinator, as well as individuals
wishing to reply to a message but not have all of the
conference participants see the reply.
-G
Disable the generation of the PATH line in exported
messages. Currently there is no need to ever use this
option, however, it is available in case there are
compatibility problems in the future.
-NF
Do not forward messages that did not originate on this
system. This option should only be used by systems on the
end of a topology chain (see the section entitled
"Conference Topology" for more information).
Page 27
Conference Mail System Revision 4.00 August 23, 1988
-NP
Do not forward private messages via echomail. If a private
message is encountered, and it is not a reply it will not be
sent. If it is a reply and the -R switch is not used, then
it also will not be sent. If the -R switch is in use, and
the message is marked private, then the logic for the -R
switch will be utilized.
-O dir
For use by Opus 1.0 systems. Place exported messages in .OUT
files in the DOS directory 'dir'. These messages can later
be processed by oMMM. This option MUST be used by systems
using Opus 1.0 for outbound FidoNet mail.
-P dir
Temporary packets created by the ARCmailing process will be
placed in the DOS directory 'dir'. If 'dir' is on a RAM disk
processing can be increased dramatically. This option is
also useful if the default directory (the current directory,
or one named by the SEADOG environment variable) does not
have enough free disk space.
-D dir
Place the final ARCmail files in the DOS directory 'dir'.
This option is incompatible with versions below 1.0 of the
ARCmail program created by System Enhancement Associates.
-F file
Takes area names from 'file' and only exports messages from
those areas.
-A ARC_cmd
Create ARCmail files using the command 'ARC_cmd'. This MUST
be the last option on the command line, and ARC_cmd consists
of everything after the -A. The default ARC_cmd is 'ARC A'.
Errorlevels returned:
0 - All processing terminated normally
1 - The maximum number of messages were output (the -M option)
2 - Severe error in processing
Examples:
Page 28
Conference Mail System Revision 4.00 August 23, 1988
BATCH FILE EXAMPLES
The following examples illustrate several possible operating
modes for the Conference Mail System. Each example is preceded by
a short paragraph explaining the system configuration and the
desired results. The corresponding section of the batch file used
to obtain those results is then shown:
1. Importing all messages including ARCmail messages into the
Conference Mail message bases using the new Opus 1.0 compatible
date format. Conferences having messages imported then have
maintenance performed on them. This is a typical installation in
the FidoNet network.
ConfMail Import -N -F ConfMail.out -A
IF ERRORLEVEL 2 GOTO SEVERE
IF ERRORLEVEL 1 GOTO DO_MAINT
GOTO END_IMPORT
:DO_MAINT
ReplyLnk -F ConfMail.Out
IF ERRORLEVEL 2 GOTO SEVERE
GOTO END_IMPORT
:SEVERE
ECHO Severe Error in Import or Maint
:END_IMPORT
2. A "secure" version of the above example (see the section
entitled "Advanced Features" for a discussion of a secure
system).
ConfMail Import -M -S -N -F ConfMail.out -A
IF ERRORLEVEL 2 GOTO SEVERE
IF ERRORLEVEL 1 GOTO DO_MAINT
GOTO END_IMPORT
:DO_MAINT
ReplyLnk -F ConfMail.Out
IF ERRORLEVEL 2 GOTO SEVERE
GOTO END_IMPORT
:SEVERE
ECHO Severe Error in Import or Maint
:END_IMPORT
3. Exporting messages from all Conference Mail message bases into
ARCmail files. When exporting messages send private replies via
FidoNet mail. This is a typical installation in the FidoNet
network.
ConfMail Export -R -A
IF ERRORLEVEL 2 GOTO SEVERE
GOTO END_EXPORT
:SEVERE
ECHO Severe Error in Export
:END_EXPORT
Page 29
Conference Mail System Revision 4.00 August 23, 1988
4. Using AREAS1.BBS for those systems receiving ARCmail, and
AREAS2.BBS for those systems not receiving ARCmail, export
messages from all Conference Mail message bases. For those
systems not receiving ARCmail, send out a maximum of 200 messages
during this run. Send private replies via FidoNet mail.
REM first handle the nodes that can receive ARCmail
ConfMail Export AREAS1.BBS -0 -R -A
IF ERRORLEVEL 2 GOTO SEVERE
REM now handle those nodes that cannot receive ARCmail
ConfMail Export AREAS2.BBS -1 -R -M 200
IF ERRORLEVEL 2 GOTO SEVERE
GOTO END_EXPORT
:SEVERE
ECHO Severe Error in Export
:END_EXPORT
5. Use a small RAM disk for holding the ARCmail packet files
created during exporting. Since the RAM disk is small, only
export 100 messages at a time, but continue on until all messages
have been processed. Also create 'tiny' seen-by lines and include
no AKA addresses.
:LOOP
ConfMail Export -M 100 -S 0 -T -P E:\ -A
IF ERRORLEVEL 2 GOTO SEVERE
IF ERRORLEVEL 1 GOTO LOOP
GOTO END_EXPORT
:SEVERE
ECHO Severe Error in Export
:END_EXPORT
6. On an Opus 1.0 system export messages into the Opus outbound
directory in .OUT file format for later processing by oMMM. Use
'tiny' seen-by lines, and send private replies via FidoNet mail.
ConfMail Export -O C:\OPUS\OUTBOUND -T -R
IF ERRORLEVEL 2 GOTO SEVERE
GOTO END_EXPORT
:SEVERE
ECHO Severe Error in Export
:END_EXPORT
Page 30
Conference Mail System Revision 4.00 August 23, 1988
IMPORTANT NOTICE:
In the past, this section contained all kinds of words that
basically meant "Don't rip me off, because it is illegal to do so, and
if you use this product and it doesn't work, it isn't my fault".
Well, that is still more or less true, but there is more now. Now,
ConfMail is being distributed as "GuiltWare <no tm>". This is a "new"
idea that I came up with. Basically, it means that if you use this
product, then you do what you can to help promote good BBS'ing by
other people. One aspect of good BBS'ing is to say "Thank you" in
some way. For ConfMail, I would appreciate it if you would send $35
to your favorite local charity, in the name of "GuiltWare" and have
the charity acknowledge receipt of your donation to the address given
on the title page for Spark Software. If $35 is too much to ask, then
at least send a thank you note from yourself - even a netmail message
will do. If you cannot do at least that, then GuiltWare fits, because
you should feel exceedingly guilty.
Page 31