@MSGID: 2:292/140 092a1b30
@REPLY: 1:229/426 1AC2B28E
@SEEN-BY: 1/123 14/0 90/1 105/81 114/709 120/340 123/131 129/305 203/0 @SEEN-BY: 221/1 226/30 227/114 702 229/424 426 428 450 550 664 700
@SEEN-BY: 230/0 240/5832 249/1 206 317 400 280/464 282/1038 292/140 @SEEN-BY: 292/789 854 8125 301/1 317/3 322/757 335/364 342/200 410/9 @SEEN-BY: 633/280
@PATH: 292/140 854 229/426
@MSGID: 2:292/140 092a1b30
@REPLY: 1:229/426 1AC2B28E
@SEEN-BY: 30/0 80/1 103/705 153/757 154/10 203/0 218/700 840 221/1 6 6000 @SEEN-BY: 229/426 664 230/0 240/1120 261/38 280/464 282/464 292/140 789 854 @SEEN-BY: 292/8125 301/0 1 101 113 335/364 341/66 410/9 712/848 920/1 > 4500/1
@SEEN-BY: 5020/1042 5058/104
@PATH: 292/140 854 301/1 221/6
Greetings,
Rudi
--- D'Bridge 4
* Origin: AfterShock Beta Tester (2:292/140)
Greetings,
Rudi
--- D'Bridge 4
* Origin: AfterShock Beta Tester (2:292/140)
The only difference between the two messages is the blank line between "Rudi" and the tear line:
Here's another one from the DBRIDGE echo that's come through after I switched my feed from Tommi back on:
The only difference between the two messages is the blank line between "Rudi" and the tear line:
Message 1:
Greetings,
Rudi
--- D'Bridge 4
* Origin: AfterShock Beta Tester (2:292/140)
Message 2:
Greetings,
Rudi
--- D'Bridge 4
* Origin: AfterShock Beta Tester (2:292/140)
So I think I'm going to leave my extra feeds switched off for a bit while I experiment with another tosser. Any
suggestions for something that can run on a Pi? I'm only aware of Mystic, SBBS & Husky.
The only difference between the two messages is the blank line between
"Rudi" and the tear line:
As both versions originate from my system and then go separate ways it's obvious there is a problem at 2:301/1 ...
Mystic thinks they are not dupes even if they have identical MSGID.
Would it be possible to adjust Mystic to check only MSGID when it exists?
Mystic thinks they are not dupes even if they have identical MSGID.
Would it be possible to adjust Mystic to check only MSGID when it exists?
Do you know if these extra lines are CR characters (ASCII 13)?
I think a better solution for Mystic would be that it does not take the ASCII 13 into consideration when it scans
for message content duplication. If they are represented as CRs (ASCII 13) and that is excluded then Mystic will
report these messages as duplicates.
The downside is that people would lose their existing dupe database and have to start over in the next version of
Mystic but I'm down to do it if people are okay with that.
I'd be hestitant to have Mystic rely only on MSGID since there are network types compatible with Mystic that do
not use MSGID at all (that can be gated), there are softwares that don't even use MSGID, and there are softwares
that spit out duplicate MSGIDs for completely different messages. Content dupe checking is important to make sure
that those situations do not allow dupe floods or report false positives dupes. I'd like to keep that feature in
while also addressing this specific issue if possible.
A hexdump of my test message in fidotest echo:
There you can see 0D's in line of "0070".
Three RC's are altering in-transit messages. Isn't that cool. :)
2:301/1 is stripping empty lines from the end of a message. 2:203/0
and 2:240/5832 are stripping empty lines from the beginning.
Three RC's are altering in-transit messages. Isn't that cool. :)
So I think I'm going to leave my extra feeds switched off for a bit
while I experiment with another tosser. Any suggestions for something that can run on a Pi? I'm only aware of Mystic, SBBS & Husky.
2:301/1 is stripping empty lines from the end of a message. 2:203/0
and 2:240/5832 are stripping empty lines from the beginning.
Three RC's are altering in-transit messages. Isn't that cool. :)
And they (and their software) probably have been doing so for decades, yet it wasn't a problem in dupe detecting
for that same period. So it seems the tossers that have been arround for that same time, have been adapted to this
behaviour, and are coping quite well... ;-)
(FMail doesn't even use the message text at all for dupe detection, even wh there is no MSGID)
2:301/1 is stripping empty lines from the end of a message. 2:203/0
and 2:240/5832 are stripping empty lines from the beginning.
2:203/0 and 2:240/5832 both use Squish. I've never noticed them stripping empty lines, but I would have to test further to confirm.
Sysop: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 32:52:18 |
Calls: | 141 |
Files: | 5,058 |
Messages: | 220,694 |