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
Software.
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
eliminated.
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,
ie.
Zone:Net/Node.Point
1
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:
1:147/33.0
For each zone 42 message:
42:1036/33.0
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
Eliminated.
2
D. Message Body
Unchanged.
E. Tear Lines
Unchanged.
F. Origin Lines
Unchanged.
G. Seen-By's
Replaced by Audit list. The Audit line begins with a unique
tag:
AUDIT:
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
characters).
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:
65535:65535/65535.65535
H. Path Lines
Eliminated.
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.
3
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.
