Hi Mark!

 ml> what version of the source code? it might be something that could help
 ml> unless it is after such was released to the public...

IIRC it's the version being released. I must do some digging...

 DR>> I could also watch what happens when some newbie activated
 DR>> a gate using Gigo.

 ml> hunh?

Yep. There has always been a dupe wave afterwards. :-(

 ml>>> SAFE_THREADS maintains a local database of MSGID, References ...

 DR>> Here you have the reason when you don't have an "encapsulated
 DR>> circuit" for messages being gated with Gigo. In the very
 DR>> moment such a message leaves that circuit (comes to another
 DR>> system which carries original message) it is a dupe but cannot
 DR>> be identified.

 ml> ahhh... that would indicate that SAFE_THREADS is only good for local bases
 ml> and not echo areas...

As long as it's ensured that there's no further connection to the world you
can use it for echo areas as well. Trouble arises in the very moment when
somebody establishes an additional connection.

 ml>>> the May 24, 1994 version contained specific work done for squish
 ml>>> problems...

 DR>> This assumption maybe is ... hmm... not fully correct. Squish
 DR>> 1.10 needs some specific setup to work correct (see my
 DR>> previous posting about this).

 ml> yes, i'm aware that squish has numerous shortcomings...

Uh??
I'm not aware of anything being worth to be called
"shortcomming". I use Squish since many years, used it with up to
ten FTNs and performed complete routing in hub/host position (route.cfg
> 50kB).

F.e. with Fastecho it wouldn't be possible to do what I have done with
Squish. I have registration keys of every important tosser and never left
Squish. To save some time and to make my live easier a little bit I
installed a tracker (Itrack) few years ago.

That's all over here, it's a simple system using a real workhorse. :-)

 DR>>>> FTN1 - Gigo - RFC - Gigo - FTN2

 DR>>>> When having a close look at this posting you'll encounter
 DR>>>> THREE different msgids in dependancy on where you pick it:

 DR>>>> Now you can link systems FTN1 and FTN2 (they feed each other
 DR>>>> directly or via many other systems). What happens?

 ml>>> a dupe loop that would happen just like it would for echomail...

 DR>> With normal echomail this is no real problem because recipient
 DR>> system is able to identify dupes when msgid is not altered.
 DR>> Such a dupe will not be exported anymore.

 ml> true... that is why there was developed a method that all systems would
 ml> "calculate" the same info for the MSGID... however, i
seem to recall that
 ml> it was a bit "short" in its working...

Such a system can't work without a common central system. Standalone mode
would cause production of very same msgid at multiple systems at some time.
Each method being used to calculate msgids has it's shortcommings but, it
what has been developed so far looks like working fine or sufficient at
least.

 ml>>> no matter... if GIGO is put on sourceforge someone can still
 ml>>> fix this problem if it is still a problem...

 DR>> This will be a problem as long as original msgid is not
 DR>> preserved and included as such in any message.

 ml> so you are recommending "converting" the original RFC
Message-ID to the
 ml> "originating system" portion of the MSGID? then what to
do for the "serial
 ml> number" portion? or just carry the original Message-ID in full
as another
 ml> control line?

The original msgid must be preserved as such. One can add other controls
but, changing msgid is a very big NoNo.

 DR>>>> Over here in Germany you'll encounter many FTN-RFC gateways
 DR>>>> but, AFAIK most of them use Fidogate or parts of it at least.
 DR>>>> Any gate will be closed very fast when first dupe is
 DR>>>> encountered.

 ml>>> the same happens (or should) when any echomail dupe loop is
 ml>>> discovered...

 DR>> There's no real distribution when software being used for
 DR>> gating works as it should be.

 ml> there is if an area is being passed from one system (the gateway) to
 ml> numerous others... isn't there?

That's correct. Sorry, I wrote an inclomplete sentence. :-( It should be
...no real distribution of dupes when ... .

 ml>>> however, we must also note that some dupe loops are by design...
 ml>>> consider a fully connected backbone network...

 ml>>> hubA=========hubB
 ml>>> | \         / |
 ml>>> |  \       /  |
 ml>>> |   \     /   |
 ml>>> |    \   /    |
 ml>>> |     \ /     |
 ml>>> |      X      |
 ml>>> |     / \     |
 ml>>> |    /   \    |
 ml>>> |   /     \   |
 ml>>> |  /       \  |
 ml>>> | /         \ |
 ml>>> hubC=========hubD

 DR>> No problem at all. We did similar over here for long time to
 DR>> ensure and speed up distribution of mail. Dupe prevention is
 DR>> done when each hub feeds specific systems which have
 DR>> absolutely no feed in direction to another hub. It needs some
 DR>> discipline at downlink side but works fine when this is given.

 ml> this is how both (Z1B and NAB) distribution systems are connectied here in
 ml> Z1... only they each have more than four systems as shown above in that
 ml> simple diagram...

R24 backbone works similar. Additionally there are "sleeping"
systems being located like an enclosing ring "around" this
backbone. In case of real trouble we should be able to fix every problem
within less than 24 hours.

 ml>>> dupes are a way of life and required to ensure proper message
 ml>>> propogation... however, those dupes should not be sent to
 ml>>> systems linkedoff each hub...

 DR>> Change msgid and things will become much more worse. :-)

 ml> i'm sure... we have that problem from time to time with fubar software
 ml> still in use... wildcat and PC Board stuff used to be the worst... wildcat
 ml> especially after an upgrade to a newer version... it used to export entire
 ml> message bases back into the distribution system...

Well, I have the very same problem due to tossers which perform
dupechecking over all areas (Squish' dupe checking is dedicated to each and
every area):
I run the gateway to and from MxBBSNet (Zone 256).

I had to exchange gateway software because of dupechecking and NoBogus (it
complained about some irrelevant things and stopped delivery for this). Now
there's the problem of "illegal links" like it exists with Gigo.
At some time some people tried to do open additional links and caused dupes
for this but seenby-adding fixed it very fast... 

cu, Dieter

---