TIP: Click on subject to list as thread! ANSI
echo: dbridge
to: mark lewis
from: Rob Swindell
date: 2018-06-19 14:26:36
subject: Dupeloops

Re: Dupeloops
  By: mark lewis to Rob Swindell on Tue Jun 19 2018 03:20 pm

 >
 >  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...

I don't dispute that rescanned message shouldn't be forwarded to downlinks and
I just committed a change to SBBSecho to that effect.

 >  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,
 >  RS> 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...

And if it's duplicate, it's a duplicate. That's why auto-posters should (?) put
timestamps or other unique data in their message body if they really want to
avoid being ignored as dupes. But including metadata (control lines) in the
dupe detection seems like a bad approach. If message takes a different path,
it'll have different metadata, but it's still a dupe (and often that's how
dupes arrive, via a different path than the original).

                                            digital man

This Is Spinal Tap quote #43:
I feel my role in the band is ... kind of like lukewarm water.
Norco, CA WX: 80.4øF, 47.0% humidity, 12 mph ENE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 103/705 154/10 203/0 218/700 221/0 1 360 229/426 240/5832 280/464
SEEN-BY: 280/5003 292/854 320/219 423/120 633/267 280 640/384 1384 712/620 848
SEEN-BY: 770/1 2320/100
@PATH: 103/705 280/464 221/0 640/1384 384 712/848 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.