| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.