FTS-0004        EchoMail Specification

This document is directly derived from the documentation of


                           The Conference Mail System
                                  Bob Hartman
                       Sysop of FidoNet(tm) node 132/101
                  (C) Copyright 1986,87, Spark Software, Inc.
                              427-3 Amherst Street
                              CS  2032, Suite  232
                              Nashua,  N.H.  03061
                              ALL RIGHTS RESERVED.


version 3.31 of 12 December, 1987.

With Bob Hartman's kind consent, copying for the purpose of technological
research and advancement is allowed.



          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.


          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.


          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

          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

          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.


          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:


               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:

                                    --- <a small product-specific banner>

               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.

          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

          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.


          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.


          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

               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.

          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.

     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

          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.