| Document: FSC-0074
  | Version:  001
  | Date:     28th July 1993
  | Author:   John Souvestre, David Troendle, Bob Davis, George Peace
  |
  | FTS-0004.002 -- proposed


                      EchoMail Specification

                            June, 1992

                      This document began as
              the Conference Mail System User Manual
                By Bob Hartman t/a Spark Software
          FidoNet(tm) node 132/101 (currently 1:104/501)
                       Used with permission

  Revision 2:

       06 Jun 1991
       John Souvestre, David Troendle, Bob Davis

       29 Oct 1991
       John Souvestre, David Troendle

       28 Jan 1992
       George Peace

       02 Jun 1992
       George Peace



                         ECHOMAIL DEFINED

  EchoMail is a technique that permits several nodes on a
  network to share a message base. It is similar in concept to
  the conferences available on commercial information services
  but is most closely related to the Usenet system consisting of
  thousands of 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 system.  In fact, they may not even be aware of the
  network being used to move their messages about from node to
  node!

  Unfortunately, EchoMail has disadvantages as well.  Many users
  who are not educated about EchoMail systems do not realize the
  messages transmitted cost MANY sysops (system operators)
  money, not just the local sysop.  This is an important
  consideration in EchoMail and should not be taken lightly.  In
  a conference with 100 systems participating the cost per
  message can be quite high.






                    BRIEF HISTORY OF ECHOMAIL

  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 the FidoNet public network boasts a myriad of
  conferences varying in size from a handful of participants to
  Sysop conferences with hundreds of participants.  It is not
  uncommon for a system to carry hundreds or more conferences
  and share those conferences with 10 or more nodes.



                        HOW ECHOMAIL WORKS

  Today's EchoMail processing is functionally compatible with
  the original EchoMail utilities.  In general, the process is:

    -  A message is entered into a designated area on a FidoNet
       compatible system.

    -  This message is "Exported" along with some 'control
       information' to each system "linked" to the conference
       through the originating system.

    -  Each receiving system "Imports" the message into the
       proper Conference Mail area.

    -  The receiving systems then "Export" these messages, along
       with additional control information, to each of their own
       EchoMail links.

    -  Return to the import step.

  The method is quite simple in general.  Of course, following
  the steps literally means messages would never stop being
  Exported and transmitted to other systems.  This obviously
  would not be desired.  The information contained in the
  'control information' section is used to prevent exporting the
  same message more than once to a single system.



                   MESSAGE CONTROL INFORMATION

  Control information is associated with each EchoMail message.
  This information consists of certain special lines placed
  inside the message.  These lines are typically inserted
  automatically by the program which prepares or processes the
  message, not by the person writing it.






  In FTS-0001 terminology, these control information lines shall
  be inside the "text" field of a "packed message".

  Control information lines shall contain only ASCII characters,
  from 32 to 126, except the first character of the path line
  and as noted elsewhere in this document.  This limitation
  applies only to control information lines.

  Alphabetic characters in required literal strings (AREA,
  Origin, SEEN-BY, and PATH) are case-sensitive.

  All control information lines shall be terminated with ASCII
  character 13 (carriage return).

  These required control information lines determine how
  EchoMail is handled:



  1. Area line

  There shall be exactly one area line in an exported message.
  The AREA line:

    -  Shall be the first line of the text and thus shall
       immediately follow the packed message header.  This
       position is "offset 0" of the "text" portion of the
       packed message.

    -  Shall be formatted as:

            AREA:CONFERENCE

            AREA: is a required five character upper case
            literal.

            CONFERENCE is the name of the conference. The
            conference name is composed of ASCII characters in
            the range 33 to 96 and 123 to 126.  The conference
            name shall be no more than 60 characters in length.

  The AREA line is added when a conference is "Exported" to
  other systems.  It is based upon information found in a
  configuration file for the designated message area.  This
  field is used by receiving systems to "Import" messages into
  the correct EchoMail area.

  Some implementations insert a Ctrl-A (0x01) immediately
  preceding the AREA: literal (^AAREA:CONFERENCE).

  Six months after adoption of this document the ^AAREA: format
  shall be processed equally with the AREA: format when either
  occurs in received packets.








  2. Origin Line

  There shall be exactly one origin line in a message.  It shall
  be placed in the message following all user entered
  information and immediately before the remaining control
  information lines.

  The origin line:

    -  Shall begin with the eleven character literal:

            <space>*<space>Origin:<space>

    -  Is optionally followed by user/system defined data in the
       ASCII range 32 to 126.

    -  Shall end with a FidoNet network address enclosed in
       parenthesis:

            ([<zone>:]<net>/<node>[.<point>][@<domain>])

    -  Shall be no more than 79 characters long including the
       required lead-in and address information.

    -  Shall be inserted into the message at the originating
       system.

  The complete line might look like:

            * Origin: Conference Mail BBS (1:132/101)



  3. Seen-by Lines

  Seen-by lines are the focus of EchoMail distribution control
  information.  They are used to determine which addresses
  (systems) have received messages.  There can be as many seen-
  by lines as required to store the necessary information.

  Seen-by lines consist of "SEEN-BY:<space>", followed by a list
  of net/node numbers corresponding to the systems which have
  received that message.  The net/node number of each system to
  which a message is exported is added to the seen-by lines at
  the time of export.

  There shall be exactly one set of seen-by lines in a message.
  Seen-by lines:

    -  Shall follow the origin line.

    -  Shall begin with the nine character literal:






            SEEN-BY:<space>

    -  Shall contain a list of net/node numbers.

    -  Shall be no more than 80 characters long including the
       required literal.

  The complete lines might look like:

            SEEN-BY: 104/1 501 132/101 113 136/601 1014/1
            SEEN-BY: 1014/2 3

  The list of net/node numbers:

    -  Shall identify at least one address. "Blank" seen-by
       lines shall not be transmitted.

    -  Shall be sorted in ascending net/node order.

    -  Shall not contain repeated node numbers.

    -  Shall use only "2D" net/node notation.

    -  May use short form address notation where a net number is
       listed once on any one line.  These 2 lines are
       equivalent:

            SEEN-BY: 104/1 104/501 132/101 132/113 136/601
            SEEN-BY: 104/1 501 132/101 113 136/601

  Some implementations insert a Ctrl-A (0x01) immediately
  preceding the SEEN-BY: literal (^ASEEN-BY:).

  Six months after adoption of this document the ^ASEEN-BY:
  format shall be processed equally with the SEEN-BY: format
  when either occurs in received packets.



  4. Path Lines

  Path lines identify a list of net/node numbers that processed
  a message before it reached the current system.  There can be
  as many path lines as required to store the necessary
  information.

  This is different from seen-by lines, in that seen-by lines
  list list all systems to which the message has been sent while
  path lines list the systems which have processed the message.

  There shall be exactly one set of path lines in a message.
  Path lines:

    -  Shall follow seen-by lines.






    -  Shall be the last line(s) in the text field of a packed
       message.

    -  Shall begin with the seven character literal:

            ^APATH:<space>

       The ^A is a special character which stands for Control-A
       (ASCII character 1), and is required at the beginning of
       each path line.

    -  Shall contain a list of net/node numbers.

    -  Shall be no more than 80 characters long including the
       required literal.

  The complete path line might look like:

            ^APATH: 132/101 1014/1

  The list of net/node numbers:

    -  Shall identify at least one net/node number.  "Blank"
       path lines shall not be transmitted.

    -  Shall not be sorted.  They shall remain in the order
       representing the actual "path" along which the message
       traveled.

    -  Shall use only "2D" net/node notation.

    -  Shall begin with the net/node of the originating system.

    -  Shall not be deleted during processing.  The original
       path information shall be maintained from origin to final
       destination.



                        ECHOMAIL TOPOLOGY

  The way in which systems link together for a particular
  conference is called the "EchoMail Topology."  It is important
  to know this structure for two reasons:

    -  It is important to have a topology which is efficient in
       the transfer of the EchoMail messages.

    -  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

    -  Fewest phone calls required for all systems to receive a
       message.

  Users of EchoMail systems have determined (through trial and
  error) the best measure of efficiency to be a combination of
  all three measurements.  Balancing the equation is not
  trivial, but some guidelines can be offered:

    -  Have nodes form "stars" for distribution of EchoMail.
       This arrangement has several nodes all receiving their
       EchoMail 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 in a similar star configuration to receive the
       EchoMail that is being passed on to the "outside"
       systems.

    -  Utilize fully connected polygons with 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
       EchoMail 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:

    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 a
  regional EchoMail star distribution architecture that
  maintains EchoMail connections within regions of the world.
  Within that architecture only a small number of prearranged
  systems (regional collection systems) make inter-regional
  connections.  This architecture, along with multiple daily
  connections, results in an efficient topology which typically
  allows global distribution within 24 hours.



                    THE PATH LINE AND TOPOLOGY

  The PATH line 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 that 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.  Here's another 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
  identifies an error in processing.  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 help
  locate the source of duplicate messages or topology problems.

  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 moderator or
  distributor of a 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 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.