Document: FSC-0063
Version:  001
Date:     10-May-1992

                      A Proposal for FidoNet style messages
                                   Jem Miller
                               1:147/33.0 @FidoNet

Status of this document:

        This FSC suggests a proposed protocol for the FidoNet(r) community,
        and requests discussion and suggestions for improvements.
        Distribution of this document is unlimited.

        Fido and FidoNet are registered marks of Tom Jennings and Fido

        I. Introduction

             The current message strucures that are  transmitted  between
        systems is fast becoming outdated.  Dupe checking, path checking,
        and zone aware routing are all areas of weekness in  the  current
        format.  This  proposal  both  simplifies  the current processing
        needed of mail tossers,  and eliminates the worst  problem  areas
        and limitations of the current methods.

             Currently,  Seen-By  lines  and  Path lines are appended and
        maintained in all EchoMail type message sent into FidoNet technol-
        ogy networks.  The original intention of Seen-By's  was  to  help
        eliminate  duplicate messages,  and give a sort of "tracking his-
        tory" of each piece of EchoMail.  Path lines tell us what systems
        have  actually  processed the mail and sent it on to another sys-
        tem, and offer some audit checking in case of problems.

             Unfortunately,  these systems can not reliably detect and/or
        correct duplicate messges,  or point to the offending system with
        any surity. In recent times, a MSGID kludge has been used, requir-
        ing the maintaining of databases (one per echo usually)  to  test
        each message for duplication.  While this procedure cures much of
        the duplication problems,  it does nothing for the audit trail of
        each  message.  Further,  it needlessly slows the tossing/packing
        process, and promotes disk fragmentation problems further.

             Yet another consideration as we enter wider  acceptance  and
        useage  of  our  electronic  media  is overhead.  Overhead can be
        viewed in many ways,  two of the most important are Cost per mes-
        sage  to transmit,  and disk space used for needless information.
        The proposed changes outlined below address all  of  these  items
        and more, giving a means of expanding into the future.

        II. Proposed Changes

             Seen-By lines will be greatly changed as compared to the cur-
        rent  structure,  Path  lines  will be eliminated,  and the MSGID
        kludge will also be eliminated.  Tear lines and origin lines will
        remain unchanged.  INTL kludges, FMPT kludges, and others will be

             This audit system is not new in concept.  In fact it is cur-
        rently used in a similar manner in the popular TICK and FLEA file
        echo processors.  Each system that processes a piece of mail adds
        its node number into an audit list.  The audit list is similar to
        current Seen-By's only in that node numbers are listed at the end
        of each message.

             Node  numbers added to the audit list are FULL node numbers,



             A system ALWAYS adds itself to the  Audit  list,  but  NEVER
        adds  any  other  system address to the list.  The mail processor
        must be capable of automatically zone matching its own  node  ad-
        dress to that of the system it is currently sending a message to.
        For  example:  If I am sending an echo to zone 1 AND zone 42,  my
        mail processor would add the following Audit entries:

        For each zone 1 message:
        For each zone 42 message:

             My system then sends the message to the  correct  receivers.
        If  the receiver is at the end of a line (not sending the area to
        any other systems),  it simply checks the audit  list  to  ensure
        that the senders address is listed only once, and tosses that mes-
        sage to the correct area.

             ONLY  SYSTEMS  THAT  RE-SEND A MESSAGE add themselves to the
        Audit list.  A system NEVER adds itself to the Audit list if  its
        sending system is listed more than once.  In this case,  the mes-
        sage is a duplicate, and is killed.

             The Audit list is NEVER sorted,  or disturbed in any way ex-
        cept to add a new node to the end of the list.

             There are no databases to maintain,  no path lines to check,
        and best of all,  only SENDING systems are  listed.  In  national
        echos,  it is not uncommon to see 5 to 8 lines of Seen-By's and 2
        or 3 path lines in EACH message.  Even though including the  full
        zone  address  (including points) adds to the length of node num-
        bers,  far fewer node numbers  are  listed.  In  the  case  of  a
        problem,   the   offending  system  can  be  quickly  and  easily
        idetified, and the problem corrected.

             Security is also enhanced by allowing the mail processor  to
        check  the  sending  system against its send-to list in the areas
        file to determine that it was received from the correct node  ad-
        dress (the senders address can be cross checked by the Audit list
        as well as the packet header).

        III. Implementation

        A. Packet Header

             The  current  packet  header  needs  no  changes (except the
        packet type identifier). This allows full backward compatibility.

        B. Packed Messages

             No change to packed message structures or procedures.

        C. MSGID Line


        D. Message Body


        E. Tear Lines


        F. Origin Lines


        G. Seen-By's

             Replaced by Audit list.  The Audit line begins with a unique


        followed by a space (ASCII #32). Each node number is seperated by
        a  space.  Each Audit line is terminated by a carriage return and
        optionally a linefeed (ASCII #13 and #10).  The  length  of  each
        Audit  line  follows  current  Seen-By  line  specifications  (79

             Node numbers in the Audit list are full  Zone:Net/Node.Point
        numbering. The maximum feild length per entry is 23 characters of
        text up to and including:


        H. Path Lines


        IV. Operations

        A. Sender

             The originating system begins the Audit sequence by creating
        the  initial  Audit  line  and  adding  his node number after the
        AUDIT: tag.

        AUDIT: 1:147/33.0

             Then packs the message to the receiving system  as  it  nor-
        mally would.

             A  system  that  is  re-sending the message to other systems
        first completes the Receiver requirements in step B  below.  Then
        the  system  adds  its own node number (zone matched) to the LAST
        Audit line of the message (or creates a new line if needed).  The
        sender then packs the message as it normally would.  This process
        is repeated for each message,  and each system  that  recieves  a
        copy  of the message.  Zone gates may or may not be listed in the
        Audit list to correctly identify any problems (open to ruling).


        B. Receiver

             Upon processing a packet,  the receiver scans for the  Audit
        lines as it currently does for a Seen-By line for each message it
        processes.  Each  entry  in the Audit list is checked against the
        LAST entry, as well as its own address, for duplication. Addition-
        ally,  the LAST address is checked against the receivers list  of
        valid  systems  for  that message area to insure that security is
        not breeched.  Optionally,  the receiver may check the address of
        the  packet header against that of the senders Audit entry to en-
        sure correct addressing.

             After all tests are made,  the message is tossed to the cor-
        rect message area.  If the receiver is to send the message to any
        other systems, it then becomes the sender and procedes as in step
        A above.


        V. Qualifications

             I am a programmer by trade,  and hold a degree in Electronic
        Engineering.  I attended Oklahoma State University, and MIT. I am
        the author of the SuperComm bulletin board system which includes:

        SCBBS     The BBS program
        SCMAIL    The Mail processor
        SCED      The offline Message editor
        SCSET     Set-up utility
        SCNET     Network interface (Front-end mailer).

             The SuperComm system holds a current FidoNet  product  code,
        and  is fully compliant in its mail handling.  A working model of
        ScMail including these changes is available  for  review.  Source
        code ideas are also available for the proposed changes, either in
        C or Turbo Pascal.