An improved method of duplicate message detection and prevention
Jack Decker
1:154/8@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 subject to the restrictions stated
in the copyright paragraph below.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose:
The purpose of this document is to present a proposal for an improved method
of duplicate message detection and prevention, that could eventually replace
the existing PATH and SEEN-BY lines currently used within Fidonet. The
principal advantages of this method over previous schemes is that it is fully
Domain-, Zone-, and Point-aware, and that it adds far fewer bytes to a message
than the current combination of SEEN-BY and PATH lines. It can also be run in
parallel with existing SEEN-BY and PATH lines for an indefinite period, thus
allowing a "transition period" of as long as is necessary for software to be
converted.
Copyright:
This document is Copyright 1990 by Jack Decker. However, permission is
granted for any and all non-commercial use, providing the contents of this
document are not altered in any way. Also, permission is expressly granted
for any use by developers of software primarily intended to be used in the
Fidonet amateur communications network, or in any similar amateur
communications network that primarily uses Fidonet technology and protocols,
whether that software is commercial or not.
Comments on this proposal, and suggestions for improvement are welcomed by the
author. In particular, suggestions on how this proposal might be reworded to
make the meaning clearer are especially welcome.
A. Definition:
In this document the characters ^A (caret and capital A) will be used to
represent a 0x01 (SOH) byte. It will be most commonly used in reference to
the "^APTH line", which will be a line that begins with a 0x01 byte
immediately followed by the letters "PTH" (and then by additional data as
specified below).
B. Why a new method of duplicate message detection is needed:
Most of the methods of duplicate message detection currently used in Fidonet
echomail processing operate by trying to find some distinguishing
characteristic of an echomail message (whether it be something deliberately
included in the message, such as an EID, MSGID, etc. type of "kludge line", or
something which is contained in all echomail messages, such as the message
header). Typically, either the item being used for duplicate detection itself
or a checksum of that item is then saved in a data file, and if another item
comes in with that same distinguishing characteristic, the message is
considered to be a duplicate message. The data files used to store
previously-seen message data can occupy a significant amount of disk space if
many conferences are carried on a system.
Unfortunately, all such schemes seem to suffer from the drawback that under
the proper circumstances, messages that are not duplicates of each other may
be created with identifying characteristics that are similar enough to be
falsely recognized as duplicates. The circumstances under which this can
happen may differ from method to method, but none are totally foolproof.
Thus, it's possible that messages may be deleted as duplicates even though in
reality they are not duplicates, but rather they are simply messages that
contain data that make them appear to be duplicates.
The most common cause of duplicate messages is improper echomail topology
(also known as the infamous "dupe loop"). While there are certainly other
ways that duplicates can be generated, improper topology is far and away the
leading cause. Further, many of the current duplicate elimination schemes
will NOT catch most of the duplicates that are NOT generated as a result of
improper topology (which is why duplicate messages are seen occasionally, even
though duplicate message detection schemes are currently in use).
Unfortunately, if a duplicate killer is to be effective, it must store the
identifying characteristics for the last several thousand messages that have
passed through a particular system. This not only uses up disk storage space,
it consumes extra processing time during echomail processing, since each new
arriving message must be compared to the data list in the attempt to determine
if it is, indeed, a duplicate.
A better approach would be to store within a message itself data that
identifies it as having already been received by a particular system, before
sending it on to another system. Then, if the same message came back to a
given system in a "dupe loop", it would be possible to positively identify it
as one that has already been seen on that particular system. And, since the
data necessary to identify the message as a duplicate is stored within the
message itself, it is possible to use this method without the necessity of
storing great amounts of data on previously-seen messages (in many
implementations this alone would save 10K or more of disk space per conference
carried!).
Were it not for the fact that the PATH line present in most echomail messages
does not contain Zone or Point information, we could use it for that purpose.
However, since it does not contain that information, it cannot and should not
be used in that manner. Another drawback of the PATH line is that because it
is physically located at the end of a message (after the SEEN-BY lines), if
only the last part of a message is scrambled or deleted, the PATH line
information will be lost.
C. Proposal:
1) A new type of kludge line (commonly known within FIDONET as an "IFNA kludge
line"), which combines certain characteristics of the existing PATH and
SEEN-BY lines, will be placed into each echomail message. This line, known as
the ^APTH line, will be placed at the TOP of the message (not necessarily the
first line, but prior to the body of the message text). IMPORTANT: Support
for the existing PATH and SEEN-BY lines will be retained as long as is
necessary to accommodate everyone in Fidonet, but eventually the ^APTH line
could possibly replace both the current PATH and SEEN-BY lines.
2) The ^APTH line will contain full five-dimensional addressing
(Zone:Net/Node.Point@Domain), BUT elements that are the same as the previous
entry in the line need not be repeated (except when a message passes to a new
domain, in which case the full address of the first node in the new domain
shall be given). When the "point" portion of an address stands alone, it
shall be preceded by at least a "." character (to distinguish it from a node
address).
3) If a system is importing messages and finds a message with its own address
already in the ^APTH line, it will discard the message (unless that address is
in the very last position on the line... this allows for the odd situation
where a point or another task on the same system has already inserted the
system's address in the ^APTH line, or where it is desirable to process the
same message a second time).
4) One (and only one) modifier character may appear just AFTER any address on
the ^APTH line. When using the ^APTH for duplicate message checking only, you
may just skip past any such address, unless it's your own address (see
examples later in this document). In that case, strip the address and the
modifier character (in other words, if you see your own address but it's
immediately followed by a modifier character, remove that address, add yours
to the end of the ^APTH line, and toss the message anyway). The reason for
doing this is to allow the design of an echomail processor that doesn't rely
on SEEN-BY's. Such a processor could append a modifier character (such as a
"!") to an address, in order to indicate that "this message hasn't really
passed through this node, but don't send it back there" (which would be the
equivalent of a SEEN-BY statement for that node, indicating that this message
has already been sent to that node). Thus the ^APTH line could eventually
take the place of SEEN-BY lines, but you could still have a "fully coupled"
triangular or rectangular topology. In this case, you'd add the nodes that
are part of that fully coupled topology to the ^APTH line BEFORE sending the
message to them, but with the special character after the address. The
receiver would know that the message didn't really pass through that node yet,
but it should NOT send it to that node under any circumstances.
(Please note that during the initial design of software to create ^APTH lines,
you would not have to worry about generating the special case with the
trailing modifier characters, you'd just have to be able to handle them as
shown in the examples below if you came across one).
D. Specifications and examples:
The general specifications for a ^APTH line, and a general outline of how an
incoming message might be processed follows.
A valid ^APTH line will contain at a minimum the string ^APTH followed by a
single space character and the network address of the system that created the
^APTH line, in Zone:Net/Node[.Point]@Domain format, where ^A is a 0x01 byte
(SOH) and the point address is required only if the system is a point
(specifically, a system that is NOT a point should not use .0).
Once again, the FIRST Fidonet-technology address specified in a ^APTH line is
expected to contain, at a minimum, Zone, Net, and Node numbers, and a valid
Domain string preceded by the "@" character. If any of these are missing from
the FIRST address, the line should be considered defective (exception: See
Note 5, "Messages sent to/from non-Fidonet-technology networks"). It will be
left to the discretion of the software author as to how to handle a message
with a defective ^APTH line.
Subsequent addresses in the ^APTH line are delimited by spaces and should
contain only that information that is different from the previous entry on the
line, except when a message passes into a new domain (in which case the full
address of the first system in the new domain shall be given) or when a
bossnode receives a message from a point, in which case the bossnode should
append its node number only. Specific examples follow:
a. If the Domain and Zone are the same as the previous address, but the
net is different, then only Net/Node[.Point] should be used.
b. If the Domain, Zone and Net are the same as the previous address, but
the node is different, then only Node[.Point] should be used.
c. If the Domain, Zone, Net, and Node are the same as the previous
address, but the point is different, then only .Point should be used.
Note that in this case, the period is included.
d. If the Domain, Zone, Net, and Node are the same as the previous
address, but the previous address contains a point specifier and the
receiving system is not a point (i.e., it IS the bossnode), then only
Node should be used. .0 (point zero) might also be a valid entry in
this case, but only if the bossnode consistently identifies itself to
other systems using a full five-dimensional address. For example, a
message that originated on 1:234/5.6@Fidonet and went from there to
1:234/5 would contain a ^APTH line in this format:
^APTH 1:234/5.6@Fidonet 5
If the bossnode is also considered to be point zero, then
^APTH 1:234/5.6@Fidonet .0
Would be equally valid.
In the case of a "fully connected" topology, nodes may be added to the ^APTH
line even though a message has not actually passed through those nodes, to
prevent the message from being sent to those nodes. Such nodes should have an
exclamation point character ("!") appended to the end of the entry,
immediately following the node or point number. These nodes should be added
to the very end of a new or existing ^APTH line, after the address of the node
which added them.
For example, suppose that 157/200, 154/9, and 228/6 were in a "fully
connected" topology. When a message was received by 157/200 and then sent to
154/9 and 228/6, the ^APTH line might look something like this:
When a message arrives on one of the nodes indicated by the exclamation point,
the exclamation point entry should be removed, and the node should add itself
to the end of the line in the normal manner. For example, after the message
containing the above ^APTH line were received at 154/9, it would be modified
to read:
Please note that at the time of this proposal, the exclamation point (!) is
the ONLY "officially recognized" modifier character that can be expected to be
appended to a ^APTH line address (except for the @Domain string, of course),
however, the possibility remains that someone may figure out a good reason to
use a different trailing character for some other (but similar) purpose, so I
am allowing for that possibility by using the generic terminology "modifier
character" rather than the more specific "exclamation point" throughout this
document.
The ^APTH line must be terminated with a carriage return and/or linefeed (a
carriage return followed by a linefeed is preferred, and should be used by all
systems capable of generating a carriage return/linefeed combination).
There is no specified limit on the length of a ^APTH line. Each message
should contain only one ^APTH line, even if it extends beyond the typical 80
column screen width. The ^APTH line is primarily intended for use by the
conference mail processing software, so primary consideration is being given
to ease of processing the line, rather than making it easily human-readable
(most software will not display kludge lines hidden behind a ^A character in
any event).
E. Pseudo-outline of message processing
Here is a suggested flow pseudo-outline showing one way that messages might be
processed in a standalone program that runs between the import and export
cycles of an existing conference mail processor such as ConfMail (this outline
assumes that the standard Fido/Opus style *.msg files are used, though
obviously that need not be the case):
1. Open *.msg file for input
2. Open temporary file for output
3. Copy header (first 190 bytes) from input to output file. The following
operations begin immediately following this header.
4. Examine each line of input file (a line is delimited by a carriage return,
linefeed, or any combination thereof) for one of the following:
a. A blank line - Write to output and examine next line.
b. A line containing spaces only - Write to output and examine next line.
c. A line that begins with a 01 byte (SOH) - GoTo 5.
d. A line that does not meet any of the above specifications.
I. Create a line containing the string ^APTH followed by a single
space character and your network address, in
Zone:Net/Node[.Point]@Domain format, where ^A is a 0x01 byte
(SOH) and the point address is required only if you are a point
(specifically, a system that is NOT a point should not
necessarily use .0). This line should be terminated with a
carriage return and/or linefeed (a carriage return followed by a
linefeed is preferred).
II. Write the line created in 4.d.I. to the output file.
III. Write the line input in 4. to the output file.
IV. Goto 9.
5. If a line begins with a 0x01 (SOH) byte, examine the keyword immediately
following it.
a. If the keyword is NOT "PTH", write the entire line to output and
examine the next line (go back to 4).
6. If a line begins with ^APTH, examine each address in the line in turn.
Addresses start immediately following the characters "PTH " (note the
space).
a. The FIRST Fidonet-technology address (not counting any
pseudo-addresses consisting solely of "@Domain") is expected to
contain, at a minimum, Zone, Net, and Node numbers, and a valid Domain
string preceded by the "@" character. If any of these are missing
from the FIRST Fidonet-technology address, the line should be
considered defective (See Note 5, "Messages sent to/from
non-Fidonet-technology networks", for information on "@Domain"
entries). It will be left to the discretion of the software author as
to how to handle a message with a defective ^APTH line.
b. As each address is found, any Zone, Net, and Node numbers and Domain
strings found should be stored in temporary variables, to be used as
defaults for subsequent addresses when only a partial address is
given. For example, the first address will contain a Zone number.
This should be stored in a temporary variable and used as the default
Zone for all subsequent addresses, until and unless another Zone
number is seen in the line, at which time that Zone number should be
stored in the temporary variable and used as the default Zone.
c. If an address is found that consists entirely of the "@" character
(as the first character of the address) followed by a domain name
(with or without punctuation), all temporary variables (defaults)
should be cleared (since any subsequent Fidonet-technology address
should contain full Zone:Net/Node[.Point]@Domain information).
Otherwise, such pseudo-addresses (consisting solely of @Domain) may be
ignored at systems that do not serve as inter-network gateways (such
entries are maintained only by inter-network "gateway" software).
However, they should not under any circumstances be removed from the
^APTH line.
7. As each address is found, it should be compared against the system's
address. If a match is found:
a. Check to make sure that the address is not a point address if the
system's address does not contain a point specifier. If the system's
address is given without a point specifier, then it should not be
considered a match if ANY point address is found in the ^APTH line
address that is being compared (not even .0 - for example, if the
address 1:234/5.0 is seen in the ^APTH line, and 1:234/5 is the given
system address, then it is NOT a match).
b. If the address does match exactly, check to see if a modifier
character (specifically the "!" character) immediately follows the
address. If it does, then that address must be removed from the
line at that point.
I. When removing an address, please make sure that you do not change
the address of subsequent entries. This may require modification
of the next entry on the line, if one exists. For example,
suppose you had a "fully connected" topology where 1:157/200 sent
an echo to both 1:154/9 and 1:154/970. The ^APTH line might end
as follows:
..... 157/200 154/9! 970!
However, after modification of the ^APTH line, it should read:
..... 157/200 154/970! 9
You can see that if 154/9 were simply deleted without regard to
what follows on the line, the following (incorrect) line might
result:
..... 157/200 970! 154/9 (THIS IS INCORRECT)
The above is incorrect because 154/970 has been transformed into
157/970.
II. After removing an address followed by a modifier character,
continue to scan any remaining addresses in the ^APTH line in
case a match is found later in the line. If no other matches
are found, proceed as if no match had been found. Goto 8.
c. Check to see if the address is the last one on the line (not counting
addresses that have a modifier character immediately following
them). If this address is followed only by the end of the line, or
ONLY by addresses that have a modifier trailing character, then
there is a very high probability that we have either inadvertently
or deliberately processed this message twice, and it is not really a
duplicate. In this case, the original *.msg file should be left
untouched.
I. Close both the input and output files.
II. Delete the temporary output file. END.
d. If a match is found, and it is not followed by a modifier
character, and it is not the last address on the ^APTH line, then the
message is a duplicate message and should be treated as such (either
by deleting it, or moving it to a "bad messages" area or the netmail
area).
I. Close both the input and output files.
II. Delete the temporary output file.
III. Either delete or move the original .msg input file, as
appropriate. END.
8. If the end of the ^APTH line is reached and a match has not been found,
then add the system's address to the end of the ^APTH line. Then write
the modified ^APTH line to the output file.
I. If one or more addresses with an appended modifier character
(used within "fully-coupled" topologies) are to be added to the
^APTH line, they should be added at the very end of the line,
after the address of the system currently processing the
message).
9. Copy the remainder of the input file to the output file. Close both files.
10. Delete the input file.
11. Rename the temporary output filename to the old input filename. END.
[End of outline]
F. Additional notes and clarifications:
Note 1: In section 7.b.I. I mentioned the necessity of not simply deleting a
node from the ^APTH line without checking to see if the next address in the
^APTH line needs to be modified. This can easily be accomplished if TWO sets
of temporary variables are kept, for the CURRENT and PREVIOUS Domain, Zone,
Net, and Node information (Point addresses are NOT kept as defaults, thus
there is no need to store Point information). When reading the FIRST address
in the ^APTH line, the Domain, Zone, Net, and Node information of that address
would be stored in both the CURRENT and PREVIOUS variables. Thereafter,
whenever a new Domain string or Zone, Net, or Node number is explicitly
specified in a ^APTH line address, the new value(s) are stored in the CURRENT
variables, but first the CURRENT values are moved to the PREVIOUS values.
To help visualize this, let's again suppose we have a ^APTH line that ends as
follows (all of these addresses are in Fidonet Zone 1):
..... 157/200 154/9! 970!
Let's suppose that we are processing this message on 154/9, and will need to
remove the 154/9! address. When we encounter 157/200, our variables will be
set as follows:
Previous | Current
Domain Fidonet | Fidonet
Zone 1 | 1
Net ? | 157
Node ? | 200
Now, when we read 154/9, our current values will be moved to the previous:
Previous | Current
Domain Fidonet | Fidonet
Zone 1 | 1
Net 157 | 154
Node 200 | 9
We now have the data we need to determine what needs to be added to the next
address, after we delete 154/9. In this case, we need only compare the
Previous and Current addresses to determine which are UNEQUAL. In this case,
the Zone and Domain are the same, but the Net and Node are not. So, if the
following address lacks either the Net or Node, we'll have to add those. Now
we delete the 154/9! and look at the next address, 970. At this point our
variables will look like this:
Previous | Current
Domain Fidonet | Fidonet
Zone 1 | 1
Net 154 | 154
Node 9 | 970
Again, we compare to see which addresses are UNEQUAL. In this case, only the
NODE address is. So we know we do NOT have to add the NODE address, nor do we
have to add the Zone or Domain information (because they were not different on
the first compare). We only need add those address components which were
unequal on the first compare, but equal on the second compare. So, in this
case, the Net address must be added to the next address in the ^APTH line,
leaving as a result:
..... 157/200 154/970!
The current system address is then added back in at the end of the line, thus:
..... 157/200 154/970! 9
Note that whenever a new Domain is specified, the full address (four- or
five-dimensional, depending on whether a point address is given) must be used.
In other words, an address that includes an "@Domain" string but that does not
also include the Zone, Net, and Node components of the address is considered
invalid (it does not meet specifications).
Note 2: In section 4.d it is suggested that, when a line that is neither
blank nor a kludge line (that begins with a ^A character) is found, a ^APTH
line be added at that point. However, there are reports that under certain
circumstances (particularly when messages are "forwarded" or "hurled"),
certain software may insert a non-kludge line prior to previously-existing
kludge lines in a message. It should be recognized by software authors that a
non-kludge line should NEVER be inserted in front of existing kludge lines
located at the start of a message, if those kludge lines are still valid (and
if they are NOT still valid, they should be removed. When a message is
forwarded or hurled, it is probably desirable to remove duplicate control
information since what is essentially happening is that the text of a previous
message is being inserted into a NEW message. Since the message is new, the
"old" duplicate control information is no longer valid).
Software authors that are implementing the ^APTH line in their software should
never search beyond the first text line of a message for the ^APTH line,
because if one is found later in the text, it is in all probability an old
^APTH line that was inadvertently copied over from another message, and is not
relevant to the current message.
Note 3: This is an optional suggestion, for use during the transition period
in which the ^APTH line has to coexist with more traditional PATH and SEEN-BY
lines. If ^APTH line checking is being used during the import phase of
echomail processing in a conference mail processor, it might be a good idea to
optionally check to make sure that all ^APTH line addresses that are in the
system's home Zone and Domain (including those with an appended modifier
character) have been properly included in the SEEN-BY lines, and to add any
that have not been so included. It should be obvious that ^APTH line
addresses that are NOT in the system's home Zone and Domain should NOT be
added to the SEEN-BY lines. If this feature is implemented, it may be a good
idea to give the sysop the ability to enable or disable it by means of a
command line switch or a configuration file option.
Note 4: If nodes with trailing modifier characters are inserted into a ^APTH
line for the purpose of indicating "SEEN-BY" nodes in a fully coupled
topology, it is permissible (but not required) to include those nodes ONLY in
the ^APTH lines of messages actually exported to the nodes participating in
the circular topology. In other words, it's permissible to add such nodes to
the ^APTH lines of messages during the import cycle, in which case messages
with ^APTH lines containing the added nodes would be exported to all nodes.
However, it's also permissible to add those nodes to the ^APTH line during the
export cycle, including them only in the ^APTH lines of the nodes that need to
see them. Please keep in mind that such nodes are added only to the END of
the ^APTH line, AFTER the address of the system processing the message. In
any event, it's up to the software author to implement this feature in such a
manner that duplicates will not be created.
Similarly, if a node RECEIVES a message containing a ^APTH line that lists
nodes with trailing modifier characters, it is permissible to remove those
nodes from the ^APTH line if it can be positively ascertained that they are no
longer required. Generally speaking, this should NOT be done unless there is
absolutely NO possibility of the message being exported to one of the nodes in
question. Note that in most situations, if a ^APTH line contains a node with
a trailing modifier character, but it is followed by a node number (other than
your own) that does NOT have a trailing modifier character (that is, the node
with the trailing modifier character is not one of the last nodes on the
line), then it can usually be safely removed since it will have already
"passed through" the fully-coupled topology.
Using the previous example of 157/200, 154/9, and 154/970 participating in a
fully-coupled topology, the ^APTH line as received at 154/9 and 154/970 might
end as follows:
..... 157/200 154/9! 970!
However, please note that if 157/200 also feeds other nodes that are NOT part
of this particular fully coupled topology, there is no real reason they would
have to see the "154/9! 970!" at the end of the line. However, there is no
prohibition against including those nodes in the ^APTH lines of messages
exported to other nodes.
Once this example message arrives at 154/9, the ^APTH line would be changed to
look like this:
..... 157/200 154/970! 9
Now, when this message is exported from 154/9 to another node (154/111 for
example), that node may remove the "154/970!" as long as 154/9 remains in the
^APTH line, since as long as the message cannot be sent back to 154/9, it
cannot re-enter the fully-coupled topology. The ^APTH line at this point
(after the message is received on 154/111) might look like this:
..... 157/200 154/9 111
It would probably not be advisable to remove the "154/970!" at 154/9 in this
example, even if the message has already been exported, because the message
might need to be re-exported (such as when a new board picks up an echo feed).
When in doubt, nodes with trailing modifier characters (other than your own)
should be left in the ^APTH line. While there is a cost of a few extra bytes
per message if you leave them in, it does not compare to the cost of the
duplicate messages that could be generated if they are removed
indiscriminately.
Note 5: Messages sent to/from non-Fidonet-technology networks: When a
message originates in, or is sent to, a non-Fidonet-technology network (a
network that does not use the Zone:Net/Node.Point addressing format), it is
permissible to indicate this in the ^APTH line by using the syntax "@Domain"
standing alone. For example, a message that comes into Fidonet via a gateway
from the Internet might show a ^APTH line as follows:
^APTH: @Internet 1:114/15@Fidonet 5 ...
Note that in the above example, the first Fidonet-technology address must
still contain, at a minimum, Zone, Net, Node, and Domain information.
It's also permissible to show a non-Fidonet-technology network at some point
in the ^APTH line other than at the beginning, if for some odd reason a
conference starts out in a Fidonet-technology network, passes through a
non-Fidonet-technology network, and then is picked up by another
Fidonet-technology network. For example,
Note that "@Internet" stands alone in the above example, meaning that the
conference originated in Fidonet, passed into the Internet (where the ^APTH
line was not maintained), and then back into a Fidonet-technology network
(Metronet in this case). Note that any Fidonet-technology address that
follows a standalone Domain specifier must contain, at a minimum, Zone, Net,
Node, and Domain information.
The question immediately arises, how do you maintain the original
Fidonet-technology ^APTH line while the message passes through another
(non-Fidonet-technology) network? This could be left solely to the discretion
of the designers of the gateway software, but in order to maintain a standard
that can be followed by authors of different gateway software packages, I
suggest that the ^APTH line be converted to one or more lines that start with
the keyword FtnPth (For "Fidonet-technology ^APTH line), with the @Domain
address of the non-Fidonet-technology network to which the message is being
passed inserted as the last entry in the list. For example, the following
^APTH line
If the receiving network has a line length limitation, then it may be
necessary to break the ^APTH line into multiple FtnPth lines.
If the message is later passed back into a Fidonet-technology network, the
gateway software should ideally be able to take the FtnPth information and
convert it back to proper ^APTH line syntax, adding the name of the network
that the message was received from if not the same as the last network
indicated in the FtnPth line(s). Of course, if no FtnPth lines exist in
message, then the gateway software should ideally create one, showing the
network that the message was received from as the first entry in the ^APTH
line.
If this is done correctly (and if non-Fidonet-technology networks can be
persuaded to leave the FtnPth lines intact), duplicate message detection can
be maintained even if a message passes through a non-Fidonet network. In
addition, those in the other network will have access to information showing
where the message originated, which systems it passed through, and where it
entered their network, which can be a big help in tracking problem messages.
Finally, this information can be used to prevent undesirable message paths
(for example, a message that enters Fidonet from a non-Fidonet-technology
network and then is later sent back into that same network at a different
gateway point, thus causing a potential duplicate message in the other
network).
Please note that in the above examples, references to @Internet are for
example purposes only, and are not intended to specify the "correct" domain
name (in preference to "UseNet" or "UUCP", for example). Determination of the
"correct" domain name for non-Fidonet-technology networks may be left to those
who operate the domain gateways.
Jack Decker
October 7, 1990
Change History:
Version 001: 04/01/90 - Original document
Version 002: 10/07/90 - Added support for Domains, and other minor
modifications to the text (mostly error correction).
