On 2018 Jun 19 11:31:08, you wrote to me:

 >> my point is specifically that messages with a ^aRESCANNED control line
 >> should  not be passed on to other links... ever... that will stop them
 >> from triggering  what looks like a regurge or "dupe dump"... they will
 >> be different than the  original message because of the ^aRESCANNED
 >> control line so they will not be  caught by most dupe detection
 >> techniques... that's the real problem...

 RS> Is that true?

in numerous cases, yes... but, if i want a rescan of an area that had damaged
data files and i'm trying to recover the last year's messages, why should the
rescanned messages be sent on to any other system? mine is the only one that
wants or needs them... why should other linked systems have to do the
additional work? if we just don't send ^aRESCANNED messages on to other
systems, no other systems would be bothered...

 RS>  Synchronet/SBBSecho uses 2 methods of dupe messge detection:

 RS> 1. Message-ID (in the case of FTN, that's everything between "\1MSGID: "
 RS> and
 RS>    the CR) - the Message-ID doesn't change when messages a re-scanned
 RS> 2. Message body text (not including kludge/control lines, paths/seen-bys,
 RS>    and tear/tag/origin lines)

 RS> Rescanned messages would (should) be caught as dupes just fine.

that looks ok but not everyone goes that route with their dupe detection
code...

i've seen the second one cause systems to only see, for example, the first
monthly posting of something and they never see it again in any of the
following months... then it is purged out of their message base and they don't
have it any more and don't receive it either... maybe it is echo rules... maybe
 it is a monthly PSA...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Every artist is a cannibal, every poet a thief.
---
 * Origin:  (1:3634/12.73)