ml>> the easiest option is to use MSGID and simply use a serial number
 ml>> that starts at x and increments x+1 for each message posted... the
 ml>> only problem with this method is determining what digit to start x
 ml>> at because it is possible that a system may need to be reinited and
 ml>> thus start with a new counter...

 RJT> The gateway program I run here (GIGO) uses a file for this
 RJT> purpose:

same thing here... gating emailnetmail, newsgroupsechos,
mailing listsechos, echosmailing lists... even have a few
external tools tied in... ie: a ping replyer

 ml>> of course, we also have to look to the buggy and flawed software
 ml>> that regurgitates messages with modified headers and control
 ml>> lines... those that strip, replace or add MSGID will mess up
 ml>> thie method but many would rather read a true duplicate a second
 ml>> or third time than risk loosing a message and having it never
 ml>> get read at all...

 RJT> I used to have a message area set aside for dupes to be tossed
 RJT> into,  but instead have them deleted these days.  Every once
 RJT> in a while I'll see some in the logs,  and wonder...

yup... there's only been a few times that i've really seen any dupes and
that's generally been due to something on my system causing the PKT to be
reprocessed... i don't know if the reprocessed messages get passed on to
those who feed from me... i've not heard anything from them saying anything
about it...

 RJT> And speaking of buggy and flawed software,  I can still
 RJT> remember occasions that go by every so often where some
 RJT> system out there will dump *ALL* of their messages into a
 RJT> whole mess of echos.  The first clue is that they're
 RJT> (usually) all dated a ways back,  maybe as much as a couple
 RJT> of months,  but not always.  The other good clue is that
 RJT> most of them show the original from/to headers and origin
 RJT> line,  but if you look at the PATH the first system there
 RJT> doesn't match the origin line, not at all.  And the PATH
 RJT> lines are all the same...

yup... many of those are/were wildcat and/or pcboard systems... they just
aren't designed for use with fidonet... the tools available are real
kludges and generally work just barely enough to get the messages in and
out... wildcat, specifically, has no internal highwater mark for the
tosser... what happened was that when those systems would upgrade to a new
version of wildcat, they were supposed to deliver any mail they had
waiting, run their scan and delete all the exported messages and then they
could go back to normal operation... some of them didn't do the delete or
didn't catch it in time or whatever... in any case, they got out... the
last one, some few months ago, was some 17000 messages...

 RJT> I'm surprised that somebody hasn't come up with a fix for
 RJT> this one by now.

you've not heard of nobogus? what you describe is exactly one of the
situations that it is designed to handle...

)\/(ark