• Mystic Source

    From Ben Ritchey@1:393/68 to All on Tue May 30 11:51:51 2017
    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)
  • From Nicholas Boel@1:154/10 to Ben Ritchey on Tue May 30 15:42:52 2017
    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)
  • From g00r00@1:129/215 to Nicholas Boel on Tue May 30 17:20:34 2017
    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)
  • From Nicholas Boel@1:154/10 to g00r00 on Tue May 30 21:18:00 2017
    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)
  • From g00r00@1:129/215 to Nicholas Boel on Thu Jun 1 17:18:03 2017
    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)
  • From Nicholas Boel@1:154/10 to g00r00 on Thu Jun 1 19:43:18 2017
    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)
  • From Paul Hayton@3:770/100 to Nicholas Boel on Fri Jun 2 12:58:48 2017
    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)
  • From g00r00@1:129/215 to Nicholas Boel on Thu Jun 1 22:02:07 2017
    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)
  • From Nicholas Boel@1:154/10 to g00r00 on Thu Jun 1 21:46:24 2017
    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)
  • From mark lewis@1:3634/12.73 to g00r00 on Fri Jun 2 11:50:00 2017

    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)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Fri Jun 2 11:54:36 2017

    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)
  • From Nicholas Boel@1:154/10 to mark lewis on Fri Jun 2 15:24:26 2017
    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)
  • From g00r00@1:129/215 to mark lewis on Fri Jun 2 21:40:07 2017
    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)
  • From g00r00@1:129/215 to Nicholas Boel on Fri Jun 2 21:45:47 2017
    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)
  • From Mike Powell@1:2320/107 to Mark Lewis on Fri Jun 2 19:38:00 2017
    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)
  • From Mike Powell@1:2320/107 to Mark Lewis on Fri Jun 2 19:57:00 2017
    | >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)
  • From mark lewis@1:3634/12.73 to g00r00 on Sun Jun 4 00:29:22 2017

    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)
  • From mark lewis@1:3634/12.73 to Mike Powell on Sun Jun 4 01:20:52 2017

    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)
  • From mark lewis@1:3634/12.73 to Mike Powell on Sun Jun 4 01:22:50 2017

    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)
  • From Nicholas Boel@1:154/10 to mark lewis on Sun Jun 4 08:49:46 2017
    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)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Sun Jun 4 13:45:14 2017

    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)
  • From g00r00@1:129/215 to mark lewis on Sun Jun 4 20:15:47 2017
    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)
  • From mark lewis@1:3634/12.73 to g00r00 on Mon Jun 5 00:41:42 2017

    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)
  • From Paul Hayton@3:770/100 to All on Mon Jun 5 20:08:07 2017
    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)
  • From Nicholas Boel@1:154/10 to Paul Hayton on Mon Jun 5 15:28:52 2017
    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)
  • From Paul Hayton@3:770/100 to Nicholas Boel on Tue Jun 6 12:34:05 2017
    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)
  • From Allen Prunty@1:2320/102 to Nicholas Boel on Sun Jun 18 23:39:18 2017
    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)
  • From Allen Prunty@1:2320/102 to g00r00 on Mon Jun 19 01:00:23 2017
    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)
  • From Mike Powell@1:2320/107 to Allen Prunty on Mon Jun 19 19:05:00 2017
    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)
  • From Allen Prunty@1:2320/102 to Mike Powell on Fri Jun 23 04:34:53 2017
    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)