TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Paul Edwards
from: Rod Speed
date: 1994-08-03 23:20:36
subject: you bastards

RS>> Corse real MSGIDs in the outgoing PKT would fix the dupe problem even
RS>> better.

PE>> How many times do I have to tell you Rod?

RS> You can tell me as often as you like Paul, if you are wrong the first
RS> time, repeating it isnt going to change anything.

PE> Ah, I see where you're getting mixed up.  I wasn't wrong the first time.

Fraid so. You might care to contemplate why only you turn them off and
most of the rest of the world uses them. The clearly dont think its quite
as simple as you claim it is.

PE>> It doesn't matter a toss if you put in a MSGID.

RS> Yes it does. If you have a MSGID you eliminate the statistical
RS> possibility of some dork dupe checking on the header data alone and
RS> falsely detecting a dupe.

PE> Nope, not at all.  Since Squish 1.10 is using two algorithms, one of
PE> which doesn't use MSGID, and marks it as a dupe if EITHER algorithm
PE> finds a match, then it happens as below.

You are oversimplifying that too much.

PE>> The moment it goes through a squish system, it will do a crc on from,
PE>> to + subject, and get the "time" field, and do a dupe
check on that.

RS> And the statistical possibility of those fields being duplicated in a
RS> pair of messages in a single packet in all except the seconds field
RS> is remote. And there is bugger all practical difference between a 1
RS> and 2 second increment in the seconds field in that case.

PE> Well you are very wrong here,

Nope.

PE> because this is the original problem I had with Bob and others having
PE> their messages marked as dupes, when it was quite obvious that they
PE> weren't.

Nope, you have screwed the argument again. Yes, its useful to have a
second field. No it doesnt make much difference if its incrementing by 1
second or 2 seconds. Cos you ONLY get a problem with messages which have
the SAME time, which is very unlikely coz you have to edit them both in
the same minute, and ONLY then when they also have the same other fields
too. As I say, the risk its tiny with 2 sec increments, no practical
difference with 1 sec increments.

RS> Squish systems can be set to dupe check on MSGID too.

PE>> It is important to make that unique, and PQWK211 does, and PQWK202
PE>> doesn't.

RS> And it aint that simple coz even with a one second increment in the
RS> time field, you have only just improved the chances. MSGID almost
RS> completely eliminates the problem cos THEN you only have the utterly
RS> remote prospect of a change in mail software reusing a MSGID in 3
RS> years. Utterly remote. And even that utterly remote possibility is
RS> avoidable with a system like PQWK that you have control over the
RS> software of.

PE> Tell you what Rod.  Manually create a packet, and include in it two
PE> messages with the from, to, subject, timestamp the same, and also put
PE> in two different MSGIDs.  I bet you $10,000 it doesn't get past my
PE> Squish 1.10 system.

Utterly irrelevant. The point is how often thats going to happen. And
thats a stupid way to dupe check anyway. Even if it is its most unlikely
to bite you.

--- PQWK202
* Origin: afswlw rjfilepwq (3:711/934.2)
SEEN-BY: 711/934
@PATH: 711/934

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