• > 255 character long lines (paragraphs)

    From Oli@2:280/464.47 to All on Wed Apr 1 10:15:56 2020
    I wonder if newer versions of Mystic cut all long lines (paragraphs) after 255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right, this line should be
    cut off right now. If I'm wrong, you still can read this.


    * Origin: kakistocracy (2:280/464.47)
  • From Ryan Fantus@1:218/820 to Oli on Wed Apr 1 01:57:00 2020
    I wonder if newer versions of Mystic cut all long lines (paragraphs)
    after 255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right, this line should be cut off right now. If I'm wrong, you still
    can read this.

    I don't have the /latest/ prealpha but have a relatively recent one.

    --- Mystic BBS v1.12 A46 2020/03/18 (Linux/64)
    * Origin: monterey bbs (1:218/820)
  • From Tony Langdon@3:633/410 to Oli on Wed Apr 1 21:39:00 2020
    On 04-01-20 10:15, Oli wrote to All <=-

    I wonder if newer versions of Mystic cut all long lines (paragraphs)
    after 255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right, this line should be cut off right now. If I'm wrong, you still
    can read this.


    * Origin: kakistocracy (2:280/464.47)

    Looks like it all came through. :)


    ... This tagline provided free of charge. Taxes may apply.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Oli@2:280/464.47 to Ryan Fantus on Wed Apr 1 13:17:26 2020
    01 Apr 20 01:57, you wrote to me:

    I wonder if newer versions of Mystic cut all long lines
    (paragraphs) after 255 characters. So I'm writing some more words
    until I reach 256 chars to test, if this is really the case. Bla
    bla bla bla .... If I'm right, this line should be cut off right
    now. If I'm wrong, you still can read this.

    I don't have the /latest/ prealpha but have a relatively recent one.

    My suspicion is that it started with 2020/03/26 and it might even be fixed in the latest pre-alpha 2020/03/29. There is one Hub in fsxnet that is running this version, the others running 2020/03/12 and are still wrapping the long lines at 79 characters.

    I'm not using Mystic, but people discovered that they receive dupes of my mails
    and one copy of my mails has paragraphs that are cut at character 255. I think that we tracked the problem down to the hub running 2020/03/26.


    * Origin: kakistocracy (2:280/464.47)
  • From mark lewis@1:3634/12 to Oli on Wed Apr 1 09:58:14 2020
    Re: > 255 character long lines (paragraphs)
    By: Oli to All on Wed Apr 01 2020 10:15:56

    I wonder if newer versions of Mystic cut all long lines (paragraphs) after
    255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right,
    this line should be
    cut off right now. If I'm wrong, you still can read this.

    i've not wrapped the above but yes, the long line is broken in two between "be"
    and "cut" as you can see above... my terminal window is 226 columns wide...


    )\/(ark
    --- SBBSecho 3.10-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Bud Spencer@3:770/3 to Oli on Wed Apr 1 22:29:09 2020
    On Wed, 1 Apr 2020, Oli wrote:

    I wonder if newer versions of Mystic cut all long lines (paragraphs) after
    255
    characters. So I'm writing some more words until I reach 256 chars to test,
    if
    this is really the case. Bla bla bla bla .... If I'm right, this line should
    be
    cut off right now. If I'm wrong, you still can read this.

    Yeah. Happens outside of the BBS-realm:

    https://i.imgur.com/CfayWxW.png

    I have 80 x 25-and-over terminals.

    This is from Alpine running on FBSD goodness ...

    But as you see, bad behaviours is easily rehabilated just by replying :D



    /
    Bud
    /

    a1=S0
    b1=[1..2,'L0L']
    a2=2*a1
    a3=S1.4#b1
    a4=(a2,a3)
    a5=64*a4

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Oli@2:280/464.47 to mark lewis on Thu Apr 2 10:06:10 2020

    01 Apr 20 09:58:14, mark lewis wrote to Oli:

    I wonder if newer versions of Mystic cut all long lines (paragraphs) after 255 characters. So I'm
    writing some more words until I reach 256 chars to test, if this is really
    the case. Bla bla bla bla
    .... If I'm right, this line should be cut off right now. If I'm wrong, you
    still can read this.

    i've not wrapped the above but yes, the long line is broken in two between
    "be" and "cut" as you can
    see above... my terminal window is 226 columns wide...

    Thanks for the replies guys.

    I think I haven't provided enough informations in my mail.

    With cut after 255 characters I mean that everything from character 256 just vanishes into digital nirvana, it's not there anymore. I think truncated is the
    better word. It seems to happen when a mail passes through Mystic pre-alpha from 2020/03/26 and maybe versions after that (unknown).

    Everyone else who doesn't have a Mystic node with that version in their path or
    running that version themself should see my messages intact :).


    * Origin: (2:280/464.47)
  • From Oli@2:280/464.47 to Bud Spencer on Thu Apr 2 08:02:02 2020
    01 Apr 20 22:29:09, Bud Spencer wrote to Oli:

    I wonder if newer versions of Mystic cut all long lines (paragraphs) after 255
    characters. So I'm writing some more words until I reach 256 chars to test, if
    this is really the case. Bla bla bla bla .... If I'm right, this line should
    be
    cut off right now. If I'm wrong, you still can read this.

    Yeah. Happens outside of the BBS-realm:

    https://i.imgur.com/CfayWxW.png

    I have 80 x 25-and-over terminals.

    This is from Alpine running on FBSD goodness ...

    But as you see, bad behaviours is easily rehabilated just by replying :D

    That looks like it went through Mystic, which applies word wrapping at column 79 (adding CRs) and then the nntp gateway or alpine wraps the lines again. That
    is a known thing with Mystic, but it looks like something changed in the pre-alpha from 2020/03/26 and lines (=paragraphs in ftn) now get truncated after 255 characters. I'm not saying I'm 100% confident about it, it is just what our limited data suggests (we did some tests in fsxnet).

    --- gossipEd-linux/arm .0.21-18496a58
    * Origin: (2:280/464.47)
  • From g00r00@1:129/215 to Oli on Fri Apr 3 02:13:32 2020
    My suspicion is that it started with 2020/03/26 and it might even be
    fixed in th e latest pre-alpha 2020/03/29. There is one Hub in fsxnet
    that is running this v ersion, the others running 2020/03/12 and are
    still wrapping the long lines at 7 9 characters.

    There have been two versions of the tosser one that word wraps and one that doesn't since February, so the date itself wouldn't be a factor it would
    depend on which tosser they are using.

    Sometime during A46 in March I removed the optional non-wrapping tosser and
    now its the only tosser available.

    They shouldn't be getting cut off at 256 characters, the line length is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that would be a bug.

    --- Mystic BBS v1.12 A46 2020/03/26 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From Al@1:153/757 to g00r00 on Fri Apr 3 12:28:22 2020
    Hello g00r00,

    They shouldn't be getting cut off at 256 characters, the line length
    is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that
    would be a bug.

    That does seem to be the case currently. I've seen it in my own testing and it's happened to a few messages in fsxNet.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Paul Hayton@3:770/100 to g00r00 on Sat Apr 4 14:09:33 2020
    On 03 Apr 2020 at 02:13a, g00r00 pondered and said...

    They shouldn't be getting cut off at 256 characters, the line length is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that would be a bug.

    What I'll work to do is update all three HUBs running Mystic to the latest pre-alpha so everything is on the same playing field. Then we can see what's happening and let you know. Cheers.

    --- Mystic BBS v1.12 A46 2020/03/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Oli@2:280/464.47 to Paul Hayton on Sat Apr 4 08:14:40 2020
    04 Apr 20 14:09, you wrote to g00r00:

    On 03 Apr 2020 at 02:13a, g00r00 pondered and said...

    They shouldn't be getting cut off at 256 characters, the line
    length is unlimited (or at least that is the intention) with the
    latest pre-alpha. If you find otherwise please let me know
    because that would be a bug.

    What I'll work to do is update all three HUBs running Mystic to the
    latest pre-alpha so everything is on the same playing field. Then we
    can see what's happening and let you know. Cheers.

    Now everything's really messed up in fsxnet. I told you so ;)


    * Origin: kakistocracy (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Fri Apr 10 14:13:52 2020

    *** Answering a msg posted in area BAD_MSGS.

    Hi Paul,

    On 1980-01-01 00:00:00, you wrote to and:

    Hmmm... :-(

    AREA:MYSTIC
    @FMAIL BAD: Message too old (2020-04-10 14:10:26)
    @FMAIL SRC: 2:292/854
    @FMAIL DEST: 2:280/464
    @TID: Mystic BBS 1.12 A46
    @MSGID: 3:770/100 651d79ff
    @REPLY: 1:129/215 5faf9ad6
    @TZUTC: 1300
    @DATE: 00 00 03:00:00
    On 03 Apr 2020 at 02:13a, g00r00 pondered and said...

    [...]

    --- Mystic BBS v1.12 A46 2020/03/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100) SEEN-BY: 203/0 221/1 229/426 261/38 280/464 292/140 854 8125 335/364 SEEN-BY: 801/188 189 190 194 197
    @PATH: 770/100 1 317/3 229/426 292/854 261/38 801/189 188 292/854

    Or is this a hickup on that system that shows up twice in the path?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Fri Apr 10 14:18:02 2020
    Hi Paul,

    On 2020-04-10 14:13:52, I wrote to you:

    @MSGID: 3:770/100 651d79ff

    @PATH: 770/100 1 317/3 229/426 292/854 261/38 801/189 188 292/854

    Or is this a hickup on that system that shows up twice in the path?

    It was. I noticed there already was a message in this area with the above MSGID... Sorry for the noice. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Fri Apr 10 17:04:23 2020
    10 Apr 20 14:18, you wrote to Paul Hayton:

    Hi Paul,

    On 2020-04-10 14:13:52, I wrote to you:

    @MSGID: 3:770/100 651d79ff

    @PATH: 770/100 1 317/3 229/426 292/854 261/38 801/189 188
    292/854

    Or is this a hickup on that system that shows up twice in the
    path?

    It was. I noticed there already was a message in this area with the
    above MSGID... Sorry for the noice. ;)

    Interesting. At least two nodes in fsxnet received bad packages with scrambled messages. The origin line of 292/854 were in the To, From or Subject field. There were also some empty messages in this area with 2:292/854 in the origin line, but otherwise completely empty. But how do we know that 292/384 is causing the problems? It could be 261/38 too (less likely though).

    Btw, 4:801/189, which is in the path between 2:292/854 and 2:292/854, is running an older version of Mystic that
    - writes incorrect SEEN-BY lines
    - ignores SEEN-BYs
    - modifies mails in-transit (line breaking)
    - doesn't recognized modified and unmodified mails with the same MSGID as dupes.

    Using something like this with fidoweb-style echo routing has to create some problems at some point. Like loops and dupes.


    * Origin: kakistocracy (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Oli on Fri Apr 10 18:06:08 2020
    Hi Oli,

    On 2020-04-10 17:04:23, you wrote to me:

    Interesting. At least two nodes in fsxnet received bad packages with scrambled messages. The origin line of 292/854 were in the To, From or Subject field. There were also some empty messages in this area with 2:292/854 in the origin line, but otherwise completely empty. But how do
    we
    know that 292/384 is causing the problems? It could be 261/38 too (less likely though).

    It happend when 2:292/854 reset his PC earlier this week when he returned from the hospital, that caused some problematic pkts to be exported from his system. Today there was another event with the same symptoms. This happend before several times when he returned from his holidays in the states for example...

    Using something like this with fidoweb-style echo routing has to
    create some problems at some point. Like loops and dupes.

    Some are caught on my system when they have an older date (like >60 days). And dupes are of course also caught. Everything else that is more or less a legit message (although from:, subject: and body are empty for instance) passes through... But this caused irex to crash on one of my downlinks.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From John Smith@1:153/757 to g00r00 on Fri Apr 10 13:54:40 2020
    Hello g00r00,

    They shouldn't be getting cut off at 256 characters, the line length
    is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that
    would be a bug.

    This is indeed the case. I did some testing yesterday with..

    Mystic BBS v1.12 A46 Linux/64 Compiled 2020/04/09 22:56:56.

    Please let us know if you would like further testing/input.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to John Smith on Sat Apr 11 08:10:29 2020

    This is indeed the case. I did some testing yesterday with..

    Mystic BBS v1.12 A46 Linux/64 Compiled 2020/04/09 22:56:56.

    Please let us know if you would like further testing/input.

    Ttyl :-),
    Al

    what happened to the subject and your name?



    * Origin: kakistocracy (2:280/464.47)
  • From Al@1:153/757 to Oli on Sat Apr 11 12:52:46 2020
    Hello Oli,

    what happened to the subject

    I'm not sure why suject lines get a little mixed up. It might be a slackware thing but I haven't been able to figure out why that happens.

    and your name?

    I haven't had any replies so I'm just trying to be sure my mail got through since it was in important feedback.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Sun Apr 12 00:04:25 2020
    This is indeed the case. I did some testing yesterday with..

    Mystic BBS v1.12 A46 Linux/64 Compiled 2020/04/09 22:56:56.

    Please let us know if you would like further testing/input.

    Thanks for letting me know.

    I have uploaded a 4/11 version which should/may address this issue. I found a function that was using an old 255 character string type, so the line of text was accidentally getting cut off when passed to that function.

    --- Mystic BBS v1.12 A46 2020/04/11 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From John Smith@1:153/757 to g00r00 on Sat Apr 11 22:20:20 2020
    Hello g00r00,

    Thanks for letting me know.

    No problem, thanks for looking into this.

    I have uploaded a 4/11 version which should/may address this issue. I found a function that was using an old 255 character string type, so
    the line of text was accidentally getting cut off when passed to that function.

    I just tested this and long lines are still being truncated at about 255 characters.

    Let us know if an update is available to test.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Sun Apr 12 17:40:03 2020
    I have uploaded a 4/11 version which should/may address this issue. found a function that was using an old 255 character string type, so the line of text was accidentally getting cut off when passed to that function.

    I just tested this and long lines are still being truncated at about 255 characters.

    Can you send me a pkt which you are using to test with to mysticbbs@gmail.com?

    --- Mystic BBS v1.12 A46 2020/04/11 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From John Smith@1:153/757 to g00r00 on Sun Apr 12 15:04:02 2020
    Hello g00r00,

    I just tested this and long lines are still being truncated at
    about 255 characters.

    Can you send me a pkt which you are using to test with to mysticbbs@gmail.com?

    Can do, it'll be in your email shortly.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Mon Apr 13 14:25:18 2020
    Can you send me a pkt which you are using to test with to mysticbbs@gmail.com?

    Can do, it'll be in your email shortly.

    I didn't have a chance to run the packet through to test yet, but I did end up finding one more place that used an old DOS type where it would potentially cause it to get truncated at 255 characters. That should be fixed now in the latest build on the prealpha area.

    I'll try to get a test done sometime soon as well, if you don't beat me to it.

    --- Mystic BBS v1.12 A46 2020/04/13 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From John Smith@1:153/757 to g00r00 on Mon Apr 13 13:44:02 2020
    Hello g00r00,

    I didn't have a chance to run the packet through to test yet, but I
    did end up finding one more place that used an old DOS type where it
    would potentially cause it to get truncated at 255 characters. That should be fixed now in the latest build on the prealpha area.

    I'll try to get a test done sometime soon as well, if you don't beat
    me to it.

    The current prealpha v1.12 A46 Linux/64 Compiled 2020/04/13 15:00:48 is working
    well in my tests.

    Messages look good in Mystic when reading and replying and outgoing .pkt's also
    look good to me.

    Thank you for this and all you do with Mystic.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Mon Apr 13 18:07:22 2020
    The current prealpha v1.12 A46 Linux/64 Compiled 2020/04/13 15:00:48 is working well in my tests.

    Messages look good in Mystic when reading and replying and outgoing
    .pkt's also look good to me.

    Thanks for your help with this! Glad to have it fixed up!

    I'm going to enable some tossing optimizations in the next build so if you notice anything weird coming from Mystic systems after the build you tested with please let me know.

    Thanks again.

    --- Mystic BBS v1.12 A46 2020/04/13 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From Robert Wolfe@1:261/20 to John Smith on Mon Apr 13 17:40:00 2020
    *** Quoting John Smith from a message to g00r00 ***

    The current prealpha v1.12 A46 Linux/64 Compiled 2020/04/13 15:00:48 i
    well in my tests.

    Messages look good in Mystic when reading and replying and outgoing .p
    look good to me.

    Just curious to see if the latest build has been compiled for OS/2 as well :)

    --- Telegard/2 v3.09.g2-sp4/mL
    * Origin: Omicron Theta/2 * Southaven, MS * os2bbs.org:2300 (1:261/20)
  • From John Smith@1:153/757 to g00r00 on Sun Apr 19 09:30:48 2020
    Hello g00r00,

    I'm going to enable some tossing optimizations in the next build so if
    you notice anything weird coming from Mystic systems after the build
    you tested with please let me know.

    We have noticed that when Mystic is tossing incoming mail to connected links it
    doesn't seem to be looking in the seen-bys. Even if a link is listed in the SEEN+BYs Mystic is still tossing that mail to the linked node anyway.

    Aside from that that though I think all is well.. :)

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Sun Apr 19 16:21:01 2020
    We have noticed that when Mystic is tossing incoming mail to connected links it doesn't seem to be looking in the seen-bys. Even if a link is listed in the SEEN+BYs Mystic is still tossing that mail to the linked node anyway.

    It used to at one point but I believe people seemed to think it should be done using the PATH instead, which is what it does now.

    It looks like I still have the SEEN-BY checking code in there commented out, although I have no idea if it still works with the current code.

    Maybe one reason for this is that some systems and many tossers have the
    option to modify or remove SEEN-BY?

    --- Mystic BBS v1.12 A46 2020/04/17 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From John Smith@1:153/757 to g00r00 on Sun Apr 19 14:24:14 2020
    Hello g00r00,

    It used to at one point but I believe people seemed to think it should
    be done using the PATH instead, which is what it does now.

    The path does have a role to play but path lines are not the same as seen-bys. Every node who has seen the message should be listed in the seen-bys but not necessarily the path lines. Once a node has seen a message we don't want to send that message there anymore.

    Mystic doesn't seem to be looking at the path now either.

    It looks like I still have the SEEN-BY checking code in there
    commented out, although I have no idea if it still works with the
    current code.

    My details are sketchy at best. I'm sure there is an FTSC doc that talks about SEEN+BYs that could give you better direction that I can. I'll take a look and see what I can find and pass the filename to you.

    Maybe one reason for this is that some systems and many tossers have
    the option to modify or remove SEEN-BY?

    Yep, we don't want any of that.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From John Smith@1:153/757 to g00r00 on Sun Apr 19 14:59:30 2020
    Hello g00r00,

    I'm sure there is an FTSC doc that talks about SEEN+BYs that could
    give you better direction that I can. I'll take a look and see what I
    can find and pass the filename to you.

    There is fts-0004.001. It's quite an old document from around 1987!

    It talks about the old conference mail system that I think is more or less what
    we still use today.

    That and other docs can be found at the FTSC website..

    http://ftsc.org

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Sun Apr 19 18:13:28 2020
    We have noticed that when Mystic is tossing incoming mail to connecte links it doesn't seem to be looking in the seen-bys. Even if a link i listed in the SEEN+BYs Mystic is still tossing that mail to the linke node anyway.

    It used to at one point but I believe people seemed to think it should
    be done using the PATH instead, which is what it does now.

    It looks like I still have the SEEN-BY checking code in there commented out, although I have no idea if it still works with the current code.

    I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32 and Linux64 version of the tosser which has the SEEN-BY checking on if you'd like to test it. This also leaves on the PATH checking too so it does both plus
    the typical CRC stuff.

    --- Mystic BBS v1.12 A46 2020/04/17 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From g00r00@1:129/215 to John Smith on Sun Apr 19 18:32:45 2020
    The path does have a role to play but path lines are not the same as

    Thanks for the explaination, but please realize I wrote a tosser and multiple mailers from scratch that implement these things so I do understand what they are. :)

    Mystic doesn't seem to be looking at the path now either.

    It does check path when tossing against the address associated to the message base being processed, as long as the address associated is a 3D address only. I can see the logging in my test network from circular PATH checking. If you have a specific situation where you think that isn't the case then let me know.

    My details are sketchy at best. I'm sure there is an FTSC doc that talks about SEEN+BYs that could give you better direction that I can. I'll
    take a look and see what I can find and pass the filename to you.

    I am not looking for any direction on SEEN-BY lines at the moment.

    They are implemented correctly in Mystic, but as said the dupe checking based on them was intentionally disabled a while back (a long long time ago). They don't work well past 3D addresses and at least back in the day they were commonly stripped or trimmed.

    The PATH checking and CRC is mostly sufficient in dupe loops unless you're intentionally setting up a situation (which I think you guys are) that creates a "bad topology" as defined in FTSC. Ironically the FTSC for SEEN-BY and PATH will actually tell you that their purpose is to identify and dissolve those "bad" topologies.

    Anyway I don't mind re-enabling it though if you're willing to test it.

    --- Mystic BBS v1.12 A46 2020/04/17 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From John Smith@1:153/757 to g00r00 on Sun Apr 19 16:46:52 2020
    Hello g00r00,

    The path does have a role to play but path lines are not the same
    as

    Thanks for the explaination, but please realize I wrote a tosser and multiple mailers from scratch that implement these things so I do understand what they are. :)

    No one is questioning your knowledge or experience.

    The PATH checking and CRC is mostly sufficient in dupe loops unless
    you're intentionally setting up a situation (which I think you guys
    are) that creates a "bad topology" as defined in FTSC. Ironically the FTSC for SEEN-BY and PATH will actually tell you that their purpose is
    to identify and dissolve those "bad" topologies.

    I'm talking about the fsxNet hubs. They are linked together and meshing. I think they are doing all that right?

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From mark lewis@1:3634/12 to g00r00 on Sun Apr 19 20:34:44 2020
    Re: Re: >er ter ter ter long lines (paragraphs)
    By: g00r00 to John Smith on Sun Apr 19 2020 16:21:01


    It used to at one point but I believe people seemed to think it should be
    done using the PATH instead, which is what it does now.

    It looks like I still have the SEEN-BY checking code in there commented out,
    although I have no idea if it still works with the current code.

    tossers should do both... path checking is the CPD (Circular Path Detection) which was implemented to prevent dupe loops... it also works with VIA lines in netmail to detect and stop netmal routing loops...

    the seenby should always be checked to prevent sending dupes... always...

    seenbys should also be sorted in net order and the list of seenbys rewritten each time addresses are added to it...

    this is old school common knowledge... i don't know if there's a document covering it or not... possibly the only one is FTSC-0004 but it is possible there may be something in the historical library along the line of "this is what i found out"...


    )\/(ark
    --- SBBSecho 3.10-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From g00r00@1:129/215 to mark lewis on Mon Apr 20 01:10:49 2020
    the seenby should always be checked to prevent sending dupes... always...

    They shouldn't *always* be checked when tossing, but I agree with what you're getting at. Its good to apply it to all 3D scenarios. If its applied to point systems, 5D scenarios, or gating then it will break things.

    seenbys should also be sorted in net order and the list of seenbys rewritten each time addresses are added to it...

    Yep yep, I'm aware of how it works! :)

    --- Mystic BBS v1.12 A46 2020/04/19 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From Paul Hayton@3:770/100 to g00r00 on Mon Apr 20 19:38:43 2020
    On 19 Apr 2020 at 06:13p, g00r00 pondered and said...

    I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32 and Linux64 version of the tosser which has the SEEN-BY checking on if you'd like to test it. This also leaves on the PATH checking too so it does both plus the typical CRC stuff.

    Thank you, I am testing this with the fsxNet NET 1 HUB.

    --- Mystic BBS v1.12 A46 2020/04/13 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From John Smith@1:153/757 to g00r00 on Mon Apr 20 09:32:44 2020
    Hello g00r00,

    I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32
    and Linux64 version of the tosser which has the SEEN-BY checking on if you'd like to test it. This also leaves on the PATH checking too so
    it does both plus the typical CRC stuff.

    One of the hubs is running this version. Currently mail passing through that hub loses all it kludges. There are no header kludges at all, no msgid, no tzutc, nothing.

    The path line doesn't mention the originating node after that, it seems to originate at the hub.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to Paul Hayton on Mon Apr 20 11:56:33 2020
    I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32 Linux64 version of the tosser which has the SEEN-BY checking on if yo like to test it. This also leaves on the PATH checking too so it doe both plus the typical CRC stuff.

    Thank you, I am testing this with the fsxNet NET 1 HUB.

    Make sure you have the one dated 4/20. I made a mistake in the first one - the old code required a little update so the 4/19 dated one is probably horribly broken.

    Hopefully all of that happened while you were asleep though!

    Keep in mind if this is enabled, things like FidoNet or anything past 2D addressing will be problematic. For example a message in Fido that passes through 1:1/1 will never toss to 2:1/1 or 3:1/1 because "1/1" will be seen as already sent. I suspect this is one of the reasons we ended up turning it off to begin with.

    I will try to have another update that will detect that scenario when tossing and be smart enough to let those messages go through but the current version only does that for point systems (not intra-zone).

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From g00r00@1:129/215 to John Smith on Mon Apr 20 13:55:07 2020
    One of the hubs is running this version. Currently mail passing through that hub loses all it kludges. There are no header kludges at all, no msgid, no tzutc, nothing.

    I have also been running the same tosser. Are you seeing those issues here?

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From g00r00@1:129/215 to John Smith on Mon Apr 20 14:08:53 2020
    One of the hubs is running this version. Currently mail passing through that hub loses all it kludges. There are no header kludges at all, no msgid, no tzutc, nothing.

    Rather than wait to hear back from the test message I sent you, I decided to set up a test here and I can see the issue.

    Its unrealted to the SEEN-BY changes, it was related to some optimizations I did before that. I've backed out those optimizations for now and they're showing up again.

    I am going to update the prealphas now which will have the tosser it in with the seen-by and this fix.

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From John Smith@1:153/757 to g00r00 on Mon Apr 20 11:13:08 2020
    Hello g00r00,

    One of the hubs is running this version. Currently mail passing
    through that hub loses all it kludges. There are no header
    kludges at all, no msgid, no tzutc, nothing.

    I have also been running the same tosser. Are you seeing those issues here?

    No, I don't see that here. Hopefully Paul can check the date of the one he is using and will be able to update.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From John Smith@1:153/757 to g00r00 on Mon Apr 20 11:58:58 2020
    Hello g00r00,

    I am going to update the prealphas now which will have the tosser it
    in with the seen-by and this fix.

    Awesome. Let us know when those are ready.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From g00r00@1:129/215 to John Smith on Mon Apr 20 17:22:41 2020
    I am going to update the prealphas now which will have the tosser it in with the seen-by and this fix.

    Awesome. Let us know when those are ready.

    Sorry I might not have been clear but they were uploaded right when I posted that! The should be dated 4/20/2020.

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
    * Origin: Sector 7 (1:129/215)
  • From Paul Hayton@3:770/100 to g00r00 on Tue Apr 21 16:10:53 2020
    On 20 Apr 2020 at 11:56a, g00r00 pondered and said...

    Make sure you have the one dated 4/20. I made a mistake in the first
    one - the old code required a little update so the 4/19 dated one is probably horribly broken.

    Hopefully all of that happened while you were asleep though!

    I'd just pulled down the stand alone zip that had the x 2 MUTIL's in them James.. so yeah perhaps I did get an earlier one. Just reading some of the threads here and I'll look to pull down the latest pre-alpha and update the
    HUB to that ASAP. Thanks for looking at this.

    --- Mystic BBS v1.12 A46 2020/04/13 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)