Hi All,

The last open-source version of MysticBBS was 1.10A30, grab it at:

http://cmech.dynip.com/MysticBBS_Sourcecode_1.10A30.zip

Note: requires Free Pascal compiler.


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet://cmech.dynip.com |
| Email: fido4cmech(at)lusfiber.net |
| Home page: http://cmech.dynip.com/homepage/ | `----------- WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1 ---'

... Always identify people in your yard before shooting at them.
--- GoldED+/W32-MSVC v1.1.5-b20170303 ... via Mystic BBS!
* Origin: FIDONet - The Positronium Repository (1:393/68)

On 5/30/2017 11:51 AM, Ben Ritchey -> All wrote:

Hi All,

The last open-source version of MysticBBS was 1.10A30, grab it at:

http://cmech.dynip.com/MysticBBS_Sourcecode_1.10A30.zip

Note: requires Free Pascal compiler.

Also note:

Please do not report any problems with this version here. Since Mystic is now on 1.12A33 I highly doubt any support is being given on any old versions. Instead, you will most likely be told to update to the latest version to see if
you still encounter whatever it is you're reporting.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

Please do not report any problems with this version here. Since Mystic
is now on 1.12A33 I highly doubt any support is being given on any old versions. Instead, you will most likely be told to update to the latest version to see if you still encounter whatever it is you're reporting.

True story! Thanks, Nick! :)

That version is terribly out of date now, and has some significant echomail issues, as it was in the middle of adding internal echomail into 1.10. Its also missing a ton of things in the last three versions.

--- Mystic BBS v1.12 A34 (Windows/64)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

On 5/30/2017 4:20 PM, g00r00 -> Nicholas Boel wrote:

True story! Thanks, Nick! :)

No problem at all, my good man!

I take it since the Fido naysayers and nitpickers have stopped complaining lately, that the latest version has successfully addressed most, if not all of the issues that arose while you were away?

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

I take it since the Fido naysayers and nitpickers have stopped
complaining lately, that the latest version has successfully addressed most, if not all of the issues that arose while you were away?

I think the only things I knew about were dupe MSGIDs while posting multiple text files at once with MUTIL, and a QWK bug with messages over 64K in size.

Both of those have been fixed.

--- Mystic BBS v1.12 A34 (Windows/64)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

On 6/1/2017 4:18 PM, g00r00 -> Nicholas Boel wrote:

I take it since the Fido naysayers and nitpickers have stopped
complaining lately, that the latest version has successfully addressed
most, if not all of the issues that arose while you were away?

I think the only things I knew about were dupe MSGIDs while posting multiple text files at once with MUTIL, and a QWK bug with messages over 64K in size.

Both of those have been fixed.

I believe one of the bigg(er) complaints regarding dupes were that the seconds were being left off the message header's timestamps..?

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

On 06/01/17, Nicholas Boel pondered and said...

Both of those have been fixed.

I believe one of the bigg(er) complaints regarding dupes were that the seconds were being left off the message header's timestamps..?

Yep, that's been sorted :) A33 is nice and shiny!

**waves hello**

Best, Paul

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

I believe one of the bigg(er) complaints regarding dupes were that the seconds were being left off the message header's timestamps..?

Oh yeah, Mystic now stores the second too. Forgot about that one.

--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

On 6/1/2017 9:02 PM, g00r00 -> Nicholas Boel wrote:

I believe one of the bigg(er) complaints regarding dupes were that the
seconds were being left off the message header's timestamps..?

Oh yeah, Mystic now stores the second too. Forgot about that one.

No worries. Sometimes I forget what I did an hour ago. ;)

If I ever get any interest in messing with my BBS in the future, I'd like to make a nice easy fix to the overly-convoluted crap I have in place now. Unfortunately, the interest has been severely lacking lately, where I end up closing the putty window and loading up Call of Duty or Playerunknown's Battlegrounds to pass the free time.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

On 2017 Jun 01 17:18:02, you wrote to Nicholas Boel:

I take it since the Fido naysayers and nitpickers have stopped
complaining lately, that the latest version has successfully
addressed most, if not all of the issues that arose while you were
away?

I think the only things I knew about were dupe MSGIDs while posting multiple text files at once with MUTIL, and a QWK bug with messages
over 64K in size.

there is/was also something with trailing spaces being stripped from MSGID lines... GTPower systems seem to leave a trailing space on the MSGID line and when systems that use text processing for thta line work with it, they see the trailing space... some system was stripping off these trailing spaces so when the message came around again and had the space then the CRC of the MSGID line was different so the additional copies were not seen as dupes... i don't remember if this stripping of trailing spaces was ever traced to mystic or not,
though... one would need to carry the few areas where that/those systems post and they don't post very often from them...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Very funny, Scotty - now beam up my clothes!
---
* Origin: (1:3634/12.73)

On 2017 Jun 01 19:43:18, you wrote to g00r00:

I think the only things I knew about were dupe MSGIDs while posting
multiple text files at once with MUTIL, and a QWK bug with messages
over 64K in size.

Both of those have been fixed.

I believe one of the bigg(er) complaints regarding dupes were that the seconds were being left off the message header's timestamps..?

there was that, also... not just being left off but being changed to zeros or possibly a different even number but mystic would only do the different even number if squish bases were still available and if that same code was being used...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You're sick, sick, sick. How can you continue to write such drivel?
---
* Origin: (1:3634/12.73)

On 6/2/2017 10:54 AM, mark lewis -> Nicholas Boel wrote:

there was that, also... not just being left off but being changed to
zeros or possibly a different even number but mystic would only do the different even number if squish bases were still available and if that same code was being used...

If it was Mystic changing time to zeros, it was most likely an earlier version (ie: not the latest). The latest version was stripping the seconds completely and only sending HH:MM. If anything it was other systems adding in the 00 as seconds because it only understood that format.

[ start off-topic ]

Also, Squish hasn't been in Mystic for quite some time now, and I don't recall anyone using a version that still supported it. I believe it was concluded that
it was Squish in general that evened the seconds out, and HPT stores messages locally with even seconds, which would only become a problem if someone were to
rescan with downlinks already setup. Tommi was a part of that and gave the evidence from his Squish system, as were others.

[ end off-topic ]

Let's not confuse other subjects with the things that needed fixing and were addressed in Mystic, please.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

there is/was also something with trailing spaces being stripped from
MSGID lines... GTPower systems seem to leave a trailing space on the
MSGID line and when systems that use text processing for thta line work

I've been thinking a bit about this a bit and I am conflicted. But I think that ultimately this is something that needs to be fixed within GTPower and whatever tossers that are fooled by it.

A MSGID has a static format of "@MSGID: <address> <serial>" and if a tosser is accepting trailing spaces after the serial as part of the serial when doing its dupe checking... then isn't that a fault of the tosser? If not, then why not?

You are essentially asking me to change Mystic so it will be capable of exporting shite formatted MSGIDs to band-aid a broken GTPower tosser, and I am not sure if I should be doing that?

Some message bases like JAM will store kludges separately from the message text, so I don't think its ever safe to assume trailing spaces would still exist on any kludge after going through several systems. The source of the message isn't guaranteed to be from the original PKT after all; it could be from a JAM message base via rescan, for example.

I did look at the code though and it would be an easy change to make.

Thoughts?

--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

If it was Mystic changing time to zeros, it was most likely an earlier version (ie: not the latest). The latest version was stripping the
seconds completely and only sending HH:MM. If anything it was other systems adding in the 00 as seconds because it only understood that format.

Yeah, this sounds about right. Mystic's PKT processor had a maximum length
of 5 defined for its time stamp (instead of 8) so HH:MM was the maximum
length of a time stamp that it could work with.

This processor is used in a HUB situation where the hub is importing
messages and tossing to downlinks. Given that a lot of people weren't using Mystic as a HUB back in the day, its easy to see how it went unnoticed for as long as it did.

It was fixed in A32 and we ran in through the mud over on FSXNET before the release for testing purposes.

--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

there is/was also something with trailing spaces being stripped from MSGID >lines... GTPower systems seem to leave a trailing space on the MSGID line and

[...snip...]

though... one would need to carry the few areas where that/those systems post >and they don't post very often from them...

Here's one!

Mike

---
* SLMR 2.1a * Isn't this where....


--- GTMail 1.26
* Origin: moe's * 1-502-875-8938 * moetiki.ddns.net (1:2320/107.0)

| >there is/was also something with trailing spaces being stripped from MSGID
| >lines... GTPower systems seem to leave a trailing space on the MSGID line and
| [...snip...]
| >though... one would need to carry the few areas where that/those systems post
| >and they don't post very often from them...
|
| Here's one!

And another. :)

Mike

##Mmr 2.61(beta). !link MP 6-02-17 19:38


--- GTMail 1.26
* Origin: moe's * 1-502-875-8938 * moetiki.ddns.net (1:2320/107.0)

On 2017 Jun 02 21:40:06, you wrote to me:

there is/was also something with trailing spaces being stripped from
MSGID lines... GTPower systems seem to leave a trailing space on the
MSGID line and when systems that use text processing for thta line
work

I've been thinking a bit about this a bit and I am conflicted. But I think that ultimately this is something that needs to be fixed within GTPower and whatever tossers that are fooled by it.

it really should only be changed in the GTMail program... no tossers are "fooled" by it... they are taking the line as a string and looking it up in a database or they are taking that line as a string and running a CRC or MD5 or SHA1 or whatever and then looking that up in the database... one stores the string or the parts of the string as strings and may also run a CRC or such on that and store that with the record, too... that way they can search the CRC and if it is found, also compare the address and serial number values to see if
it is a false dupe or not based on the CRC or such... or they may have a btree with the CRC as the vertices (aka index)...

A MSGID has a static format of "@MSGID: <address> <serial>" and if a tosser is accepting trailing spaces after the serial as part of the
serial when doing its dupe checking... then isn't that a fault of the tosser? If not, then why not?

one can take the line or part(s) of the line as strings or one can work with the portions of the line as numerics... string processing is a little slower so
older systems may store the data as numbers and do math on them instead for the
speed... some just keep the line as a string or break it into string parts and work with the information like that...

You are essentially asking me to change Mystic so it will be capable
of exporting shite formatted MSGIDs to band-aid a broken GTPower
tosser, and I am not sure if I should be doing that?

no... no, i'm not... i'm saying that when mystic processes mail to be passed on
to other systems, it should not modify those lines or any part of the message other than adding itself to the seenby and path lines... it should not be, if it is at all, stripping trailing spaces from the control lines or any part of the message during the process of copying and adding that message to the PKTs destined to downlink systems pulling that area from the mystic system... i'm certainly not telling you to add a trailing space to help other systems... that's crazy... just don't strip one if tossing echomail... sure, being stored in the JAM base might clean it up (see below) but that's not the same thing as when passing mail on to other systems in a hubbing setup...

Some message bases like JAM will store kludges separately from the
message text, so I don't think its ever safe to assume trailing spaces would still exist on any kludge after going through several systems.
The source of the message isn't guaranteed to be from the original PKT after all; it could be from a JAM message base via rescan, for
example.

true... but that's on rescans... the posts i was speaking of were not rescanned... i would get two of them here which made it easy to see the problem... both were identical except that one had a trailing space on the MSGID line and the other didn't... these are stored in JAM bases, BTW ;) and the second one was not seen as a dupe by the mail tosser (HPT)... when i looked
into the tosser's dupe database, i saw both MSGID lines in it... one with a space and one without... golded, my message editor, lets me see a raw hex view of the messages... that made the space stand out when flipping between the two posts in question... i have/had maybe 10 posts from the same system that had one dupe each and the only difference to be seen was the trailing space on the MSGID line... looking in the RAW PKTs that the posts arrived in also showed that one had the trailing space and the other didn't... one copy passed through
a mystic system on the way here... that one arrived without the trailing space... both copies passed through at least one fastecho system on the way here... it did not catch them as dupes... i know that FE runs the MSGID string through a CRC formula and stores that value in the dupe database... it does the
calculation and looks to see if the CRC is in the database... if it isn't it adds it... if it is, the message is placed into the DUPES message area for possible later inspection and remediation...

I did look at the code though and it would be an easy change to make.

i'm not saying that a mystic system was responsible for the removal of the trailing space on the MSGID line in mail passed on to other systems... i'm asking that the code be checked to ensure that mail being tossed into downlink PKTs is not modifying the MSGID line or any other control lines... what is done
when putting the messages into the local message base is something else and should not have any bearing on the copies being passed on to other systems during the toss session...

Thoughts?

does the above help?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I modem down, but they grew back.
---
* Origin: (1:3634/12.73)

On 2017 Jun 02 19:38:00, you wrote to me:

@MSGID: 1:2320/107.0 456af434

note the MSGID is the same as below in the HEX dump and in the other message on
this...

there is/was also something with trailing spaces being stripped from
MSGID
lines... GTPower systems seem to leave a trailing space on the MSGID line
and

[...snip...]

though... one would need to carry the few areas where that/those systems
post and they don't post very often from them...

Here's one!

yup, this one arrived with a trailing space... its dupe arrived with no trailing space... see next message ;)

0000 02 00 00 00 0B 00 00 00 4D 69 6B 65 20 50 6F 77 ........Mike Pow 0010 65 6C 6C 03 00 00 00 0A 00 00 00 4D 61 72 6B 20 ell........Mark
0020 4C 65 77 69 73 06 00 00 00 0D 00 00 00 4D 79 73 Lewis........Mys 0030 74 69 63 20 53 6F 75 72 63 65 04 00 00 00 16 00 tic Source...... 0040 00 00 31 3A 32 33 32 30 2F 31 30 37 2E 30 20 34 ..1:2320/107.0 4 0050 35 36 61 66 34 33 34 20 D1 07 00 00 3F 00 00 00 56af434 -...?...
trailing space ----^^-----------------------------------^
0060 31 39 2F 33 33 20 33 34 2F 39 39 39 20 39 30 2F 19/33 34/999 90/ 0070 31 20 31 31 36 2F 31 38 20 31 31 36 20 31 32 30 1 116/18 116 120 0080 2F 33 33 31 20 31 32 33 2F 31 34 30 20 31 34 31 /331 123/140 141 0090 20 31 32 38 2F 31 38 37 20 31 33 30 2F 32 30 D1 128/187 130/20- 00A0 07 00 00 42 00 00 00 31 33 35 2F 33 30 30 20 31 ...B...135/300 1 00B0 34 30 2F 31 20 31 35 34 2F 31 30 20 32 31 38 2F 40/1 154/10 218/ 00C0 37 30 30 20 32 33 30 2F 31 35 30 20 32 34 30 2F 700 230/150 240/ 00D0 31 31 32 30 20 32 34 39 2F 33 30 33 20 32 35 30 1120 249/303 250 00E0 2F 31 20 32 36 31 2F 33 38 D1 07 00 00 42 00 00 /1 261/38-...B.. 00F0 00 32 36 31 2F 31 30 30 20 32 36 36 2F 34 30 34 .261/100 266/404 0100 20 32 36 37 2F 31 35 35 20 32 38 30 2F 31 30 32 267/155 280/102 0110 37 20 32 38 32 2F 31 30 33 31 20 31 30 35 36 20 7 282/1031 1056
0120 32 39 32 2F 31 34 30 20 39 30 38 20 33 32 30 2F 292/140 908 320/ 0130 31 31 39 D1 07 00 00 41 00 00 00 33 32 30 2F 32 119-...A...320/2 0140 31 39 20 33 34 30 2F 34 30 30 20 33 39 33 2F 36 19 340/400 393/6 0150 38 20 37 35 20 33 39 36 2F 34 35 20 37 31 32 2F 8 75 396/45 712/ 0160 38 34 38 20 38 30 31 2F 31 36 31 20 31 38 39 20 848 801/161 189
0170 32 33 32 30 2F 31 30 30 20 31 30 35 D1 07 00 00 2320/100 105-... 0180 2A 00 00 00 32 33 32 30 2F 31 30 37 20 33 36 33 *...2320/107 363 0190 34 2F 31 32 20 31 35 20 32 37 20 34 32 20 35 30 4/12 15 27 42 50 01A0 20 36 36 36 20 35 30 32 30 2F 31 30 34 32 D2 07 666 5020/1042-. 01B0 00 00 1B 00 00 00 32 33 32 30 2F 31 30 37 20 31 ......2320/107 1 01C0 30 35 20 32 36 31 2F 33 38 20 33 36 33 34 2F 31 05 261/38 3634/1 01D0 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2...............

Mike

---
* SLMR 2.1a * Isn't this where....

--- GTMail 1.26
* Origin: moe's * 1-502-875-8938 * moetiki.ddns.net (1:2320/107.0) SEEN-BY: 19/33 34/999 90/1 116/18 116 120/331 123/140 141 128/187 130/20 SEEN-BY: 135/300 140/1 154/10 218/700 230/150 240/1120 249/303 250/1

261/38

SEEN-BY: 261/100 266/404 267/155 280/1027 282/1031 1056 292/140 908

320/119

SEEN-BY: 320/219 340/400 393/68 75 396/45 712/848 801/161 189 2320/100 105 SEEN-BY: 2320/107 3634/12 15 27 42 50 666 5020/1042
@PATH: 2320/107 105 261/38 3634/12

here's the path this one took to me... i'll quote its dupe in a second for the
other path and hex output...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Yeah, and hookers! We need plenty of hookers!
---
* Origin: (1:3634/12.73)

On 2017 Jun 02 19:38:00, you wrote to me:

@MSGID: 1:2320/107.0 456af434

note the MSGID is the same as below in the HEX dump and in the other message on
this...

there is/was also something with trailing spaces being stripped from
MSGID
lines... GTPower systems seem to leave a trailing space on the MSGID line
and

[...snip...]

though... one would need to carry the few areas where that/those systems
post and they don't post very often from them...

Here's one!

yup, this one arrived *without* a trailing space ;)

0000 02 00 00 00 0B 00 00 00 4D 69 6B 65 20 50 6F 77 ........Mike Pow 0010 65 6C 6C 03 00 00 00 0A 00 00 00 4D 61 72 6B 20 ell........Mark
0020 4C 65 77 69 73 06 00 00 00 0D 00 00 00 4D 79 73 Lewis........Mys 0030 74 69 63 20 53 6F 75 72 63 65 04 00 00 00 15 00 tic Source...... 0040 00 00 31 3A 32 33 32 30 2F 31 30 37 2E 30 20 34 ..1:2320/107.0 4 0050 35 36 61 66 34 33 34 D1 07 00 00 3E 00 00 00 35 56af434-...>...5
*no* trailing space ----^^-----------------------------------^
0060 37 2F 30 20 31 31 36 2F 31 30 32 20 31 31 36 20 7/0 116/102 116
0070 31 32 33 2F 31 34 31 20 31 38 30 20 31 32 39 2F 123/141 180 129/ 0080 32 31 35 20 31 33 30 2F 32 31 30 20 35 31 32 20 215 130/210 512
0090 31 33 35 2F 33 30 30 20 31 34 30 2F 31 D1 07 00 135/300 140/1-.. 00A0 00 3D 00 00 00 31 35 34 2F 31 30 20 32 30 20 33 .=...154/10 20 3 00B0 30 20 34 30 20 37 30 30 20 32 30 33 2F 30 20 32 0 40 700 203/0 2 00C0 32 31 2F 36 20 32 32 36 2F 31 30 30 20 32 32 37 21/6 226/100 227 00D0 2F 32 30 31 20 32 32 39 2F 33 31 30 20 32 35 30 /201 229/310 250 00E0 2F 33 D1 07 00 00 43 00 00 00 32 36 31 2F 33 38 /3-...C...261/38 00F0 20 32 38 30 2F 34 36 34 20 33 31 37 2F 32 20 33 280/464 317/2 3 0100 34 30 2F 38 30 30 20 33 39 33 2F 36 38 20 37 31 40/800 393/68 71 0110 32 2F 38 34 38 20 37 37 30 2F 30 20 31 20 33 20 2/848 770/0 1 3
0120 31 30 30 20 33 34 30 20 37 37 32 2F 30 D1 07 00 100 340 772/0-.. 0130 00 25 00 00 00 37 37 32 2F 31 20 32 31 30 20 35 .%...772/1 210 5 0140 30 30 20 33 36 33 34 2F 31 32 20 31 35 20 32 37 00 3634/12 15 27 0150 20 34 32 20 35 30 20 36 36 36 D2 07 00 00 2F 00 42 50 666-.../. 0160 00 00 32 33 32 30 2F 31 30 37 20 31 30 35 20 32 ..2320/107 105 2 0170 36 31 2F 33 38 20 33 39 33 2F 36 38 20 37 37 30 61/38 393/68 770 0180 2F 31 20 31 35 34 2F 31 30 20 33 36 33 34 2F 31 /1 154/10 3634/1 0190 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2...............

Mike

---
* SLMR 2.1a * Isn't this where....

--- GTMail 1.26
* Origin: moe's * 1-502-875-8938 * moetiki.ddns.net (1:2320/107.0) SEEN-BY: 57/0 116/102 116 123/141 180 129/215 130/210 512 135/300 140/1 SEEN-BY: 154/10 20 30 40 700 203/0 221/6 226/100 227/201 229/310 250/3 SEEN-BY: 261/38 280/464 317/2 340/800 393/68 712/848 770/0 1 3 100 340 772/0
SEEN-BY: 772/1 210 500 3634/12 15 27 42 50 666
@PATH: 2320/107 105 261/38 393/68 770/1 154/10 3634/12

and here's the path this one took... if it isn't the mystic system in the above
path then there's two other tossers to look at before it gets to my system... the first three in the path already pass the test since they were the same three in the path of the one with the trailing space ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... We die only once, and for such a long time.
---
* Origin: (1:3634/12.73)

On 6/4/2017 12:22 AM, mark lewis -> Mike Powell wrote:

@PATH: 2320/107 105 261/38 393/68 770/1 154/10 3634/12

and here's the path this one took... if it isn't the mystic system in
the above path then there's two other tossers to look at before it gets
to my system... the first three in the path already pass the test since they were the same three in the path of the one with the trailing space ;)

Those would be Fastecho (770/1) and HPT (me). Both of which I believe you work with on your many setups.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

On 2017 Jun 04 08:49:46, you wrote to me:

@PATH: 2320/107 105 261/38 393/68 770/1 154/10 3634/12

and here's the path this one took... if it isn't the mystic system in
the above path then there's two other tossers to look at before it
gets to my system... the first three in the path already pass the
test since they were the same three in the path of the one with the
trailing space ;)

Those would be Fastecho (770/1) and HPT (me). Both of which I believe
you work with on your many setups.

yup... and since 261/38 already passed it on to me cleanly, that removes BBBS from being the culprit and the two systems before it... that takes us back to mystic being the one doing the stripping of the trailing spaces... at least on the MSGID line...

string processing vs numerical processing can be a real PITA in situations like
this... this is one case where either works and works well as long as everything is the same for both processing methods... as soon as one side changes, it all falls apart...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... We were so poor, we went to KFC to lick other people's fingers!
---
* Origin: (1:3634/12.73)

it really should only be changed in the GTMail program... no tossers are "fooled" by it... they are taking the line as a string and looking it up in a database or they are taking that line as a string and running a CRC or MD5 or SHA1 or whatever and then looking that up in the database...

According to you some tossers are being fooled by the extra space. Mystic for example accurately detects them as duplicates regardless of the extra spaces. A trailing space shouldn't completely blow up a tossers duplicate checking IMO.

Anything that is creating a database of MSGIDs for dupe checking should probably be parsing the address and serial number, not just taking the entire string regardless of what is in there and then hashing it.

Thats something that could easily be remedied in a tosser.

no... no, i'm not... i'm saying that when mystic processes mail to be passed on to other systems, it should not modify those lines or any part of the message other than adding itself to the seenby and path lines...

Well you're asking me to change Mystic's export function to willingly export ill-formatted MSGID kludges. :)

You'll be happy to know that I did end up making the change to not strip the end of a GTPower MSGID of its trailing space, so despite our possibly difference of options at least that particular issue should resolve itself. :)

strip one if tossing echomail... sure, being stored in the JAM base
might clean it up (see below) but that's not the same thing as when passing mail on to other systems in a hubbing setup...

I think it *IS* the same thing because content passed to a downlink doesn't always come from the original incoming PKT. Many people do rescans which is probably the most common example of this.

You are operating under the assumption of a single use case and in that single use case your points are valid. But the problem is there are many use cases that you are not taking into consideration.

A proper dupe checking system should hash the address and serial specifically from MSGID *not* the entire line (because the format can vary). It should then hash the entire message content without ANY kludge/seenby lines, and finally it should hash the from/to/subject/date. (IMO)

If the properly parsed MSGID hash is in the database its a dupe OR if the message content and the message header hashes are matches then its a dupe.

Thoughts?

does the above help?

Yes, thanks for your feedback and letting me know of the problem :)

We may not agree completely, but I made the change for the next alpha.

--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

On 2017 Jun 04 20:15:46, you wrote to me:

it really should only be changed in the GTMail program... no tossers
are "fooled" by it... they are taking the line as a string and
looking it up in a database or they are taking that line as a string
and running a CRC or MD5 or SHA1 or whatever and then looking that up
in the database...

According to you some tossers are being fooled by the extra space.

no, sorry, i did not say any software was "being fooled"... those are not words
i've used in this situation...

Mystic for example accurately detects them as duplicates regardless of
the extra spaces.

you apparently have a different method of dupe checking, then... i've explained
that some take the whole line or the address and serial number portion as a string and run that through a CRC routine... they simply take everything or from the startpos of the address to the end of the line an run it through... going that way will retain the trailing space and it will be run through the CRC calculator... HPT even stores it in the dupe database... others simple store the CRC value...

A trailing space shouldn't completely blow up a tossers duplicate
checking IMO.

it doesn't... it simply allows modified messages to be seen as individuals and not dupes... NO tosser should EVER strip anything from from a message on initial processing and feeding to other systems... rescan bring a whole different causation to the table and we're not talking about rescans... the the
routines used to place a message into the local message base should not be used
on posts passing through if they modify the data string before writing it to the outbound PKTs...

Anything that is creating a database of MSGIDs for dupe checking
should probably be parsing the address and serial number,

no, the data fields in a MSGID are just that... data fields... they are not for
parsing... they are only for message identification and reply linking... nothing else... not even trying to determine the originating address for netmail purposes... the MSGID is designed for one purpose and one purpose only... it is a string line and that's all that really matters...

not just taking the entire string regardless of what is in there and
then hashing it.

Thats something that could easily be remedied in a tosser.

the problem is that a tosser is modifying messages in transit when it should NOT be doing so...

no... no, i'm not... i'm saying that when mystic processes mail to be
passed on to other systems, it should not modify those lines or any
part of the message other than adding itself to the seenby and path
lines...

Well you're asking me to change Mystic's export function to willingly export ill-formatted MSGID kludges. :)

no i am not... i'm not talking about exporting from the local message base... i'm talking about when you pull a message from a freshly arrived PKT and copy it into an outbound PKT for delivery to another system... nothing in that copy should be different from the original other than the seenbys and path line modifications that are generally performed...

You'll be happy to know that I did end up making the change to not
strip the end of a GTPower MSGID of its trailing space, so despite our possibly difference of options at least that particular issue should resolve itself. :)

excellent! i understand why one might want to "strip(msgidline,' ')" but this is a case where it should not be done... not for any lines in any message being
passed on to another system...

FWIW: GTPower may not be the only one with this type of problem... it is just the one that's been found with it at this point in time ;)

strip one if tossing echomail... sure, being stored in the JAM base
might clean it up (see below) but that's not the same thing as when
passing mail on to other systems in a hubbing setup...

I think it *IS* the same thing because content passed to a downlink doesn't always come from the original incoming PKT.

that's a separate and distinct situation from this one where we're specifically
talking about copying a message from PKT to PKT and modifying it during that copying process...

Many people do rescans which is probably the most common example of
this.

that may be but the cause of this is the combination of today's multipath distribution and some tosser modifying part(s) of messages that should not be modified... rescan messages are a different animal and don't come into play here...

You are operating under the assumption of a single use case and in
that single use case your points are valid.

no, that is the specific case where this problem takes place... i'm fully aware
of the other scenarios and am explicitly leaving them out so as to be very clear as to the problem, the cause and the solution...

But the problem is there are many use cases that you are not taking
into consideration.

see above...

A proper dupe checking system should hash the address and serial specifically from MSGID *not* the entire line

says you... not everyone sees it like that...

(because the format can vary).

so what? the first part is defined as an address... it doesn't matter what format that address is in... it isn't supposed to be parsed... the second part is the serial number which is defined as an eight character HEX serial number... the only thing that matters about these fields is that they do not appear in another message with the same contents within a three year period... their contents really don't matter... not even the value of the HEX serial number... they just can't appear within a three year period...

It should then hash the entire message content without ANY
kludge/seenby lines, and finally it should hash the
from/to/subject/date. (IMO)

if that works for you, great... some don't see the need to go through that extra stuff when only the header information and maybe some control line data are all that's needed...

If the properly parsed MSGID hash is in the database its a dupe OR if
the message content and the message header hashes are matches then its
a dupe.

i agree... the thing is that that's not what all other tossers do... some don't
even take the MSGID into account at all... i know of one that will throw a message out as a dupe if the body is the same no matter what the header contains... there's another one that i'm aware of that takes the binary header and some of the first bytes of the message body and runs that through a hash function... those first bytes of the message body are generally where some control lines reside... hopefully that data would be different in non-dupe messages when other things (eg: the seconds) are ignored in the processing because they don't store seconds in their local message base at all... this is one reason why it is a very good idea to place the MSGID first in the message body when a message is generated... the lack of seconds comes up later in that rescan scenario that you keep pointing to ;)

Thoughts?

does the above help?

Yes, thanks for your feedback and letting me know of the problem :)

you are welcome... i'm glad that you did look and apparently saw where the stripping might be taking place and adjusting it to not do so... i look forward
to seeing what happens with those particular types of posts when the new code hits the streets :)

We may not agree completely, but I made the change for the next alpha.

we agree in more ways than some might think... the problem is that we need to be generous in what we accept but tight in what we emit... i'll qualify that with emit being only for messages originating on our system (includes new and rescans) and does not apply to messages passing through to other systems even if they are tossed into our local message base at the same time...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... And then there was the guy who stuffed Corn Flakes in the serial port.
---
* Origin: (1:3634/12.73)

On 06/05/17, mark lewis pondered and said...

Yes, thanks for your feedback and letting me know of the problem :)

you are welcome... i'm glad that you did look and apparently saw where
the stripping might be taking place and adjusting it to not do so... i look forward to seeing what happens with those particular types of posts when the new code hits the streets :)

We may not agree completely, but I made the change for the next alpha

we agree in more ways than some might think... the problem is that we

We'll it's a thumbs up from me to you both. :) I'm going to have to get you guys over for a beer one day. We can all talk bollocks about the good old
days of BBS when a MSGID was a MSGID and SEEN-BY lines were, erm .. SEEN-BY lines etc. etc. :)

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

On 6/5/2017 3:08 AM, Paul Hayton -> All wrote:

We'll it's a thumbs up from me to you both. :) I'm going to have to get

you

guys over for a beer one day. We can all talk bollocks about the good old days of BBS when a MSGID was a MSGID and SEEN-BY lines were, erm ..

SEEN-BY

lines etc. etc. :)

While I know this didn't include me directly, I'd like to note that if I were ever to make my way to New Zealand to have a beer with you, MSGID and SEEN-BY lines would most likely not be on my mind, nor in any of my topics of discussion. ;)

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

On 06/05/17, Nicholas Boel pondered and said...

While I know this didn't include me directly, I'd like to note that if I were ever to make my way to New Zealand to have a beer with you, MSGID
and SEEN-BY lines would most likely not be on my mind, nor in any of my topics of discussion. ;)

Ha ha... fair enough... BBQ and New Zealand beer focus it is then :)

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

I take it since the Fido naysayers and nitpickers have stopped
complaining lately, that the latest version has successfully addressed most, if not all of the issues that arose while you were away?

I am only hoping that everything has worked out. If so I will once again
start moving things towards Mystic. Synchro has worked well for me in the interum but would like to move my mail into the JAM Message base format.

It would also be nice if there is at least a consideration for some security within the same zone to lock down coordinator echos within the zone? As it
is now if I go mystic it makes everything I have available to all of my downlinks. It would be nice to say that XXX echo is only available to XXX sysops (not that I have a kinky XXX echo lol).

Allen

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Mystical LiveWire - Rose Terrace, KY (1:2320/102)

I've been thinking a bit about this a bit and I am conflicted. But I think that ultimately this is something that needs to be fixed within GTPower and whatever tossers that are fooled by it.

As far as I know there is only ONE system that is even running GTPower anymore... and they dominate the Weather echo. There are a handful of
Platinum Express / wildcat systems out there. I have moved away from that because of GTPower causing my system to resend everything with a corrected
tear line.

I do agree there have to be standards, but there is a boatload of legacy software out there that some still cling to. At least Nick Andre keeps D'Bridge working properly.

Unfortunately the tosser for GTPower's author has long exited the scene and
the author of Platinum Express doesn't seem to care about hobbyists anymore.

Allen

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Mystical LiveWire - Rose Terrace, KY (1:2320/102)

As far as I know there is only ONE system that is even running GTPower anymore... and they dominate the Weather echo. There are a handful of Platinum Express / wildcat systems out there. I have moved away from that because of GTPower causing my system to resend everything with a corrected tear line.

I have asked you about that multiple times and you have never explained
what you mean. My GT Power system connects directly with my SBBS system, and the tearlines from my GTP system are ALWAYS in tact on the SBBS system, as
are the origin lines.

Meanwhile, whenever I receive a message from your system in any of the usenet echos, on both the GT and SBBS systems, your tear AND origin lines are NOT there.

As I have said before, I do not think the issue is on this end, but I am
not 100% certain what that issue even is. You and I connect directly, but
you get the Weather echo from elsewhere, so I have no idea what happens to
it between here and there.

I have had some other oddities happening because of how the MSGID is
created, but no one other than you is having difficulties with the format,
or lack of, any tear or origin lines.

And the weather echo messages originate from SBBS, and have for a while now.

Mike

---
* SLMR 2.1a * DALETECH - for all your home security needs!


--- GTMail 1.26
* Origin: moe's * 1-502-875-8938 * moetiki.ddns.net (1:2320/107.0)

Meanwhile, whenever I receive a message from your system in any of the usenet echos, on both the GT and SBBS systems, your tear AND origin
lines are NOT there.

In my usenet setup my tear and origin lines are translated into organization lines for Usenet and are removed when it goes across usenet. The header address is sent in a manner that if anything comes across the gateway as an e-mail reply to any post going through my gateway it will translate to
netmail.

But that's not the problem.

The problem was when I ran wildcat your MSGID was not formatted properly
making my system generate a PROPER MSGID (the way PX was written to deal with it back when Bob Hoffman gated between Fido and Familynet) PX did not see it as a Fidonet message due to the improperly formatted msgid so what it did was assume your message was a "gated" message give it a proper MSGID for fidonet and tack my origin line underneath your origin line and shoot it off again as
a dupe in fidonet.

In fact had a discussion with Mark Lewis who agreed this is the old and
proper way to do Zonegateing. It also did not help that your Weather echo's gateway from Irex used a strange zone that was not a fido zone 1-5 which further caused PX to trigger Zonegating making a dupe of every message in the Weather echo, I think you eventually fixed it or Synchronet just ignored it once I switched to Synchro... but you were one of the main reasons why I did abandon Platinum Express/Wildcat as I got a lot of hate mail from messages
that were duplicated because of bad MSGID's in either an improper formed from GTFido or the wrong Zone From Irex.

It's all good now as I have given up on a new tosser for Wildcat I'm too connected to Zone 2, 3 and 4 to operate with PX and it does not seem like WildMail is going to be completed... sad, but haven't heard a peep from Joe Martin and I owe my downlinks a stable feed.

Allen

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Mystical LiveWire - Rose Terrace, KY (1:2320/102)