Message Area
Casually read the BBS message area using an easy to use interface. Messages are categorized exactly like they are on the BBS. You may post new messages or reply to existing messages! You are not logged in. Login here for full access privileges. |
Previous Message | Next Message | Back to D'Bridge Support Echo <-- <--- | Return to Home Page |
|
||||||
From | To | Subject | Date/Time | |||
Rob Swindell | mark lewis | Dupeloops |
June 19, 2018 2:26 PM * |
|||
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) |
||||||
|
Previous Message | Next Message | Back to D'Bridge Support Echo <-- <--- | Return to Home Page |
Execution Time: 0.1001 seconds If you experience any problems with this website or need help, contact the webmaster. VADV-PHP Copyright © 2002-2024 Steve Winn, Aspect Technologies. All Rights Reserved. Virtual Advanced Copyright © 1995-1997 Roland De Graaf. |