• a sense of belonging

    From Maurice Kinal@1:153/7001 to All on Tue Apr 2 21:10:09 2019
    Hey All!

    One minor little change. Nothing to be alarmed about.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@2:280/464.113 to Maurice Kinal on Tue Apr 2 21:24:42 2019
    Hallo Maurice!

    Looks good from this angle, including the phoney-baloney ftn datetime stamp. Everything is as it should be ... SNAFU.

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Maurice Kinal@1:153/7001 to Maurice Kinal on Tue Apr 2 22:03:55 2019
    Hey Maurice!

    Everything is as it should be ... SNAFU.

    No and yes. I see your long line got reformatted close to home. I already know who isn't doing that so it remains to be seen who it is ... not that I plan to do anything about it but as usual it is always nice to know. This message should narrow it down and I believe the last time we tried this we narrowed it down to two possible nodes.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@2:280/464.113 to Maurice Kinal on Tue Apr 2 22:39:37 2019
    Hallo Maurice!

    This message should narrow it down and I believe the last time
    we tried this we narrowed it down to two possible nodes.

    I can confirm from this angle that your message also got reformatted and near as I can tell we're back to those same two nodes. One of them I am wondering why the heck it is even on the PATH at all given it's nodelisted location. Anyhow the other is definetly closer to home.

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Tue Apr 2 22:26:38 2019

    On 2019 Apr 02 22:39:36, you wrote to you:

    I can confirm from this angle that your message also got reformatted and near as I can tell we're back to those same two nodes. One of them I am wondering why the heck it is even on the PATH at all given it's
    nodelisted
    location. Anyhow the other is definetly closer to home.

    what are the paths being taken to your system?

    are you familiar with the non-entity known as the fidoweb?

    FWIW: sometimes, round-the-world links are faster than those within your own net, region, zone...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The four northern seasons: Winter, Spring, Summer, and Hunting.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to mark lewis on Wed Apr 3 02:54:02 2019
    Hey mark!

    what are the paths being taken to your system?

    For the one I am replaying to it's "PATH: 3634/12 154/10" but that isn't the one in question. I have yet to see your post show up on what is supposed to be the usual suspects.

    are you familiar with the non-entity known as the fidoweb?

    I've heard of it.

    round-the-world links are faster than those within your own net,
    region, zone...

    If that is the case then why isn't your message to me here yet? ;-)

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@2:280/464.113 to Maurice Kinal on Wed Apr 3 03:02:25 2019
    Hallo Maurice!

    If that is the case then why isn't your message to me here yet?

    Heh, heh. Both his message and your reply made it to the Netherlands and back and we still haven't seen his message on the supposed super speedy web dealie.

    Kids these days, eh?

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Tue Apr 2 23:12:44 2019

    On 2019 Apr 03 02:54:02, you wrote to me:

    what are the paths being taken to your system?

    For the one I am replaying to it's "PATH: 3634/12 154/10"

    that would be via nick boel's system, then... i have a direct connection with him for several echos and files areas...

    but that isn't the one in question.

    true :)

    I have yet to see your post show up on what is supposed to be the
    usual suspects.

    ok...

    are you familiar with the non-entity known as the fidoweb?

    I've heard of it.

    you understand the premise behind it? multiple feed links for each area?

    round-the-world links are faster than those within your own net,
    region, zone...

    If that is the case then why isn't your message to me here yet? ;-)

    i dunno... PKTs are generally processed and sent on within a few seconds on this new installation... some systems may process mail on a schedule like my old setup used to do... this new setup processes ASAP and fires the mail off right quickly...

    on my main system, ASIAN_LINK is connected to these systems:

    1:116/116
    1:123/25
    1:123/50
    1:123/150
    1:123/755
    1:135/300
    * 1:153/7715
    * 1:154/10
    * 1:261/38
    1:3634/12.73
    * 1:3634/15
    1:3634/27
    1:3634/50

    the ones with '*' are known to have multiple links for echos... they may or may not have multiple feed links for ASIAN_LINK... there may be a few more in the above list that have multiple links but i'm not sure without doing some extensive digging... digging that i'm just not going to do unless there's a real problem that i need to solve...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... A little greed can get you lots of neat stuff.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to mark lewis on Wed Apr 3 03:07:53 2019
    Hey mark!

    what are the paths being taken to your system?

    Here we go; "PATH: 3634/12 154/10 280/464 770/1 153/250 757". Sorry about the delay. I've got it narrowed down to two possiblities - 770/1 or 153/250. The rest I am sure are okee-dokee ... as far as reformatiing msg bodies are concerned that is.

    We've been through this before.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to mark lewis on Wed Apr 3 03:41:56 2019
    Hey mark!

    i have a direct connection with him for several echos

    It appears that I do too.

    you understand the premise behind it? multiple feed links for
    each area?

    I could see that being handy in certain situations.

    on my main system, ASIAN_LINK is connected to these systems:

    I recognize a number of those, none of which ever reformatted any of my msg bodies to my knowledge.

    digging that i'm just not going to do unless there's a real
    problem that i need to solve...

    Not to worry then.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Wed Apr 3 00:05:46 2019

    On 2019 Apr 03 03:07:52, you wrote to me:

    what are the paths being taken to your system?

    Here we go; "PATH: 3634/12 154/10 280/464 770/1 153/250 757". Sorry
    about
    the delay. I've got it narrowed down to two possiblities - 770/1 or 153/250.

    unless i'm mistaken, at least one of those systems is running mystic which we know from recent discussions has not been properly writing seenby lines to the messages it processes... it is not too hard to imagine that it may also be reformatting messages... i don't understand why things that have been working properly in it since v1.10 or v1.11 are being changed now and breaking stuff...

    The rest I am sure are okee-dokee ... as far as reformatiing msg
    bodies are concerned that is.

    true...

    We've been through this before.

    yeah, i believe we have...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Zucchini is NOT the name of an Italian auotmatic weapon!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Wed Apr 3 00:08:54 2019

    On 2019 Apr 03 03:41:56, you wrote to me:

    i have a direct connection with him for several echos

    It appears that I do too.

    :)

    you understand the premise behind it? multiple feed links for
    each area?

    I could see that being handy in certain situations.

    yep... like when a link goes down for some time... however, it also leads to other problems... the main one being the stripping of moderator's control/rights over their echo...

    on my main system, ASIAN_LINK is connected to these systems:

    I recognize a number of those, none of which ever reformatted any of my
    msg
    bodies to my knowledge.

    good... i know that one or two of them run mystic but i don't recall which version and i don't know if they feed fidoweb-style...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Desperate times call for cheap shots.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to mark lewis on Wed Apr 3 04:43:52 2019
    Hey mark!

    at least one of those systems is running mystic

    This is starting to sound familiar.

    it is not too hard to imagine that it may also be reformatting
    messages

    I now recall the last time pondering this and I really don't have an answer. All I can say is it is very annoying and it should have been fixed by now. There is really no good reason for it ... is there?

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to mark lewis on Wed Apr 3 04:49:13 2019
    Hey mark!

    like when a link goes down for some time

    That is exactly what I was thinking.

    the main one being the stripping of moderator's control/rights
    over their echo...

    Sometimes that could be a good thing. :::patent pending:::

    Anyhow thanks for the insight and although I am not 100% convinced that it is a mystic issue I am content there is no purposeful bad intention, not that I believed there was. I am still annoyed though.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 3 14:18:25 2019
    Hi Maurice,

    On 2019-04-02 21:10:09, you wrote to All:

    @MSGID: 1:153/7001.2989 5ca3cfb1
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

    2 Different node/point numbers?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 3 15:40:36 2019
    Hey Wilfred!

    2 Different node/point numbers?

    Why not? As far as I can tell there could be 65536 different node/point numbers if the MSGID were to use them for different processes and/or users while the Origin only uses the actual address of the node wrt the nodelist. I don't see where that breaks with current standards. If it does please feel free to illuminate.

    Speaking of standards, what about "CHRS: UTF-8 2"? Even in the pure fantasy land of fts-5003.001 that appears to be bogus. :-)

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 3 18:06:53 2019
    Hi Maurice,

    On 2019-04-03 15:40:36, you wrote to me:

    2 Different node/point numbers?

    Why not? As far as I can tell there could be 65536 different node/point numbers if the MSGID were to use them for different processes and/or
    users
    while the Origin only uses the actual address of the node wrt the
    nodelist.
    I don't see where that breaks with current standards. If it does please feel free to illuminate.

    I just don't think it's good practice. It's confusing to both humans and software. For instance if someone wants to send a reply by netmail which of the two should be used?

    Speaking of standards, what about "CHRS: UTF-8 2"? Even in the pure fantasy land of fts-5003.001 that appears to be bogus. :-)

    Yeah, I know, it's been pointed out to me before. I use a more or less default golded configuration regarding charsets. I'll have to look into this to fix it somewhere. But I don't care too much, most of my messages just contain plain ascii, so there's nothing to translate for software on receivers systems anyway that need the CHRS kludge for this.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Wed Apr 3 12:18:48 2019

    On 2019 Apr 03 04:43:52, you wrote to me:

    at least one of those systems is running mystic

    This is starting to sound familiar.

    i'm sure...

    it is not too hard to imagine that it may also be reformatting
    messages

    I now recall the last time pondering this and I really don't have an answer. All I can say is it is very annoying and it should have been
    fixed
    by now. There is really no good reason for it ... is there?

    there is not... in fact, the spec says that messages passing through a system are not to be modified i nany way other than adding seenby and path entries... it is possible that rescanned messages may be otherwise modified since they come from the rescanned system's message base and the messages may have been reformatted for that message storage format but normal processing and passing on of messages should not do that...

    )\/(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 cannot antagonize and influence at the same time.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 3 16:33:35 2019
    Hey Wilfred!

    For instance if someone wants to send a reply by netmail which of
    the two should be used?

    netmail is totally different but offhand I think you are probably right about the confusion software may or may not have about this issue. However, if the purpose of the MSGID is to facillitate dupechecking, and nothing else, then I would think any node that uses point addressing to avoid false dupes on a multiuser system would be a good thing even when the pont address is not included in the Origin and perhaps shouldn't be. But that is just echomail and netmail has it's own checks and balances as far as addressing is concerned. No?

    I use a more or less default golded configuration regarding
    charsets.

    Seems to me somebody had a fix for the CHRS kludge years ago not too long after fts-5003 reared it's ugly head.

    systems anyway that need the CHRS kludge for this.

    I seriously doubt there ever will be a need, especially for UTF-8. So far for translating characters to/from 8 bit character sets, glibc's iconv works great. So far the CHRS kludge does nothing to facilitate that need and that is a good thing. :::patent pending:::

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to mark lewis on Wed Apr 3 18:18:40 2019
    Hey mark!

    normal processing and passing on of messages should not do that

    Agreed. The someone doing this should fix it pronto or not be on the PATH. It has been happening for far too long now.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Alan Ianson@1:153/757 to Maurice Kinal on Wed Apr 3 12:01:28 2019
    Hello Maurice,

    normal processing and passing on of messages should not do that

    Agreed. The someone doing this should fix it pronto or not be on the PATH.
    has been happening for far too long now.

    I've been trying to follow what's going on but not sure if I'm up to speed.

    Are you seeing messages getting changed along the way? That is certainly unwanted behavior.

    I can certainly test things with BBBS and I also have a Mystic BBS setup here that we could test things with if you are interested in doing that.

    Mystic BBS is actively developed by James Coyle and if we could get details to him I'm sure he would agree that messages should not be changed and if that is happening is not by design and he would appreciate a bug report.

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Maurice Kinal@1:153/7001 to Alan Ianson on Wed Apr 3 19:36:45 2019
    Hey Alan!

    Are you seeing messages getting changed along the way?

    Yes, including yours - the one I am currently replying to "MSGID: 1:153/757.0 4e505c01" - when it shows up along this path -> "PATH: 153/757 250 770/1 280/464 154/10" has been tampered with. The same message "MSGID: 1:153/757.0 4e505c01" I got directly from you - "PATH: 153/757" - looks perfect. Also on tne EuroPoint message "MSGID: 1:153/757.0 4e505c01" with "PATH: 153/757 250 770/1 280/464" is buggered up as well. Bottomline is that it isn't your node that is buggering it up. Also while we're at it, when this was first noticed way back when it wasn't 1:153/7715 doing it either. That was before any recent changes to the local status quo in net 153.

    we could test things with if you are interested in doing that.

    At the moment I am distracted with wireless connectivity but if there is a need I will do what I can to help. As far as fidonet software is concerned I grow my own. I call it a hobby. :::evil grin:::

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Thu Apr 4 10:30:36 2019
    Hi Maurice,

    On 2019-04-03 16:33:35, you wrote to me:

    For instance if someone wants to send a reply by netmail which of
    the two should be used?

    netmail is totally different but offhand I think you are probably right about the confusion software may or may not have about this issue. However, if the purpose of the MSGID is to facillitate dupechecking, and nothing else, then I would think any node that uses point addressing to avoid false dupes on a multiuser system would be a good thing even when
    the
    pont address is not included in the Origin and perhaps shouldn't be. But that is just echomail and netmail has it's own checks and balances as far as addressing is concerned. No?

    When I reply by netmail to that message with the point number, GoldEd automatically uses the point address as the destination. So since the header of a packed message doesn't have room for the point number part of the FTN address, it seems the address from the MSGID is used for this. So it doesn't seem like a good idea to add a random point number to the MSGID, unless it really exists in the nodes system configuration, or it is ignored by the systems software...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@2:280/464.113 to Wilfred van Velzen on Thu Apr 4 15:05:54 2019
    Hallo Wilfred!

    So it doesn't seem like a good idea to add a random point number
    to the MSGID

    I wouldn't make it random but like the UID in a user database instead. That way on a multiuser BBS there would be a way to keep MSGID's unique if and when the serial number collides with another user of the BBS when serial numbers are unixtime based, which in many cases it is.

    a packed message doesn't have room for the point number part of
    the FTN address, it seems the address from the MSGID is used for
    this

    I always look to the Origin for the address. In the case of this reply it is the same as the MSGID's ftn address simply because this is an actual point which doesn't use the resources of the mothership 2:280/464 to post or reply to echomail or netmail. However a BBS recieving a message with it's node number plus a point number ought to know that the point number is part of a user database it has onboard and that it corresponds to a user ... or process such as a robotized application used for administrative purposes. I don't see why this would be an issue, even in the case of actual points off a system such as the EuroPoint.

    For the record, the message I am replying to - "MSGID: 2:280/464 5ca5c283" - shows up twice on Little Mikey's Brain since it has two links to this particular echoarea, not counting the EuroPoint. On this path - "PATH: 280/464 154/10" - your message is fine and shows no sign of any jiggery-pokery, whereas this path - "PATH: 280/464 770/1 153/250 757" - there is obvious word wrapping applied with a few of the sentences having a space at the start of the line.

    It isn't just my messages that are getting fscked up.

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Alan Ianson@1:153/757 to Maurice Kinal on Thu Apr 4 12:53:58 2019
    Are you seeing messages getting changed along the way?

    Yes, including yours - the one I am currently replying to "MSGID:
    1:153/757.0
    4e505c01" - when it shows up along this path -> "PATH: 153/757 250 770/1 280/464 154/10" has been tampered with. The same message "MSGID:
    1:153/757.0
    4e505c01" I got directly from you - "PATH: 153/757" - looks perfect.

    Also on tne EuroPoint message "MSGID: 1:153/757.0 4e505c01" with "PATH: 153/757 250 770/1 280/464" is buggered up as well. Bottomline is that it isn't your node that is buggering it up.

    That is a quick path that I see here a lot. I chat at times with the first two nodes in that path and haven't noticed any problems but maybe I just wasn't looking. I'll investigate.

    Also while we're at it, when this was first noticed way back when it wasn't 1:153/7715 doing it either. That was before any recent changes to the local status quo in net 153.

    153/7715 was the first node this area was connected to here when I setup this area so you will likely see that node in the path also.

    we could test things with if you are interested in doing that.

    At the moment I am distracted with wireless connectivity but if there is a nee
    I will do what I can to help. As far as fidonet software is concerned I
    grow
    my own. I call it a hobby. :::evil grin:::

    Just as a point of focus for me, what changes are you seeing? I can't make any changes myself but I don't mind doing some testing and report my findings to those who can.

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Maurice Kinal@1:153/7001 to Alan Ianson on Thu Apr 4 20:03:15 2019
    Hey Alan!

    153/7715 was the first node this area was connected to here when
    I setup this area so you will likely see that node in the path
    also.

    I see it in the SEEN-BY but not in the PATH. As far as the PATH is concerned there is only you in the message I am replying to and it looks unscathed. It's
    only messages from further afield where the message body gets altered.

    Just as a point of focus for me, what changes are you seeing?

    Shoddy word wrapping. If I have to guess I'd say it was via one of those NNTP gateways. They are the usual source of longtime screwed up messages, including
    messing with datetime stamps as well as replacing valid node numbers with their own. Beats me what they see in that crap but they shouldn't be allowed on a PATH given their track record.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From mark lewis@1:3634/12.73 to Alan Ianson on Thu Apr 4 16:23:58 2019

    On 2019 Apr 04 12:53:58, you wrote to Maurice Kinal:

    Also on tne EuroPoint message "MSGID: 1:153/757.0 4e505c01" with "PATH:
    153/757 250 770/1 280/464" is buggered up as well. Bottomline is that
    it isn't your node that is buggering it up.

    That is a quick path that I see here a lot. I chat at times with the
    first two nodes in that path and haven't noticed any problems but
    maybe I just wasn't looking. I'll investigate.

    it'll be hard to see on a standard 80x25 terminal screen... if the terminal is wider than 80 columns, it should be easier to see since it is forced wordwrapping to fit within 80... i'd guess that 120x25 would work to try to see it as long as the BBS software doesn't try to format it for you on transmission...

    of course, having the raw PKTs would tell the real story, too... especially the one coming in and one going out where the message could be compared at a digital level...

    my old system used to archive both inbound and outbound PKTs specifically for research like this... it is harder to do with my current setup on my main system but it is something i've been thinking about doing and how to go about doing it... i may have to (re)learn some C to do it, though... especially if i do it the easiest and most direct way by adding the capability to sbbsecho to copy the PKTs before processing the inbound ones after they are possibly unarchived and then to also copy the freshly generated outbound PKTs before they are placed into the BSO... hummm...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Yellowknife, a really cool place!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Thu Apr 4 16:36:10 2019

    On 2019 Apr 04 20:03:14, you wrote to Alan Ianson:

    @MSGID: 1:153/7001 5ca66303
    @REPLY: 1:153/757.0 6dcfa5e3
    Hey Alan!

    153/7715 was the first node this area was connected to here when
    I setup this area so you will likely see that node in the path
    also.

    I see it in the SEEN-BY but not in the PATH. As far as the PATH is concerned there is only you in the message I am replying to and it looks unscathed. It's only messages from further afield where the message
    body gets altered.

    i see it here but GoldEd's reflowing corrects it... i would not have known that i was seeing it here if you had not mentioned that there's a space added to the beginning of the line that's being force-wrapped by the intermediate system... i've added the space back to the above... here it showed up before "only"...

    Just as a point of focus for me, what changes are you seeing?

    Shoddy word wrapping. If I have to guess I'd say it was via one of those NNTP gateways. They are the usual source of longtime screwed up
    messages,
    including messing with datetime stamps as well as replacing valid
    node numbers with their own. Beats me what they see in that crap but
    they shouldn't be allowed on a PATH given their track record.

    in the above, it showed up before "messing"...

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001) SEEN-BY: 57/0 153/250 7001 154/10 20 30 40 700 203/0 221/0 6 227/400 229/426
    SEEN-BY: 240/5832 267/800 280/464 5003 310/31 317/2 340/800 393/68 396/45 SEEN-BY: 423/120 712/848 770/0 1 10 100 330 340 772/0 1 210 500 3634/12 SEEN-BY: 116/116 123/25 150 755 135/300 153/7715 261/38 3634/15 27 50 123/50
    SEEN-BY: 3634/0 18/0 123/0 1/120
    @PATH: 153/7001 757 250 770/1 280/464 154/10 3634/12



    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Grinin' Like A Mule Eatin' Briars.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to mark lewis on Thu Apr 4 21:06:51 2019
    Hey mark!

    my old system used to archive both inbound and outbound PKTs
    specifically for research like this...

    I am still doing that. That is exactly where I am getting the PATH information
    from as I strip it for display purposes. In the case of your last two message
    here, the path is "PATH: 3634/12 153/7715 757" and both are unscathed. Note that the one you seem to think is the culprit is not in that path so your 'guess' is probably better than mine. I still have it narrowed down to two simply because I've never had any dealings with those two so I cannot say for sure.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to mark lewis on Thu Apr 4 21:14:59 2019
    Hey mark!

    i see it here but GoldEd's reflowing corrects it

    When reading on a console I do that with 'fold -s' which wraps on spaces so that they aren't at the start of a line. I am guessing GoldEd is doing something similar. Also 'fmt' but I've never been able to make it work properly with multibyte characters.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Alan Ianson@1:153/757 to mark lewis on Fri Apr 5 12:51:20 2019
    it'll be hard to see on a standard 80x25 terminal screen... if the terminal is
    wider than 80 columns, it should be easier to see since it is forced
    wordwrapping to fit within 80... i'd guess that 120x25 would work to try to se
    it as long as the BBS software doesn't try to format it for you on transmission...

    Ah.. my terminal is 80x30 lines so I wouldn't see that. I can set the width and
    length of my screen in BBBS so I'll try that out in a wider screen in an xsession and have a look.

    of course, having the raw PKTs would tell the real story, too... especially th
    one coming in and one going out where the message could be compared at a digital level...

    Yes, I did that at one time for reasons I don't remember anymore. When I was looking at seen by lines in Z21 I was running my buns off trying to get to pkt's befor the tosser got to them. :)

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Paul Hayton@3:770/100 to mark lewis on Sun Apr 7 09:53:48 2019
    On 03 Apr 2019 at 12:05a, mark lewis pondered and said...

    the delay. I've got it narrowed down to two possiblities - 770/1 or 153/250.

    unless i'm mistaken, at least one of those systems is running mystic
    which we know from recent discussions has not been properly writing
    seenby lines to the messages it processes... it is not too hard to
    imagine that it may also be reformatting messages... i don't understand why things that have been working properly in it since v1.10 or v1.11
    are being changed now and breaking stuff...

    770/1 is not presently running Mystic. It has been using FastEcho and BinkD since it was first set up some 4+ years ago.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alan Ianson@1:153/757 to Paul Hayton on Sat Apr 6 18:35:46 2019
    770/1 is not presently running Mystic. It has been using FastEcho and BinkD since it was first set up some 4+ years ago.

    From what I've been able to gather messages are being changed somewhere along the path, lines being wrapped at 80 columbs.

    When I get a bit of spare time I'll stop the tosser here for a bit and see if
    can get a .pkt from 153/7715 and the same from 153/250 and we can see if there
    is a difference.

    If I see anything I'll let you know, in any case we'll get to the bottom of it.

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Sean Dennis@1:18/200 to Alan Ianson on Sat Apr 6 21:49:52 2019
    Hello Alan,

    06 Apr 19 18:35 at you wrote to Paul Hayton:

    From what I've been able to gather messages are being changed
    somewhere along the path, lines being wrapped at 80 columbs.

    FE is known to strip out seen-bys with international mail. I don't remember exactly why but Andrew Leary was explaining it to me a while back. Maybe something's happening there?

    Later,
    Sean

    ... The motor will rotate in the wrong direction.
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Outpost BBS * Limestone, TN, USA (1:18/200)
  • From Paul Hayton@3:770/100 to Alan Ianson on Sun Apr 7 14:26:35 2019
    On 06 Apr 2019 at 06:35p, Alan Ianson pondered and said...

    From what I've been able to gather messages are being changed somewhere along the path, lines being wrapped at 80 columbs.

    Ak OK

    If I see anything I'll let you know, in any case we'll get to the bottom of it.

    Sure thing Al. I'm not aware of anything like that happening with either FastEcho or Mystic so would be interested to hear how you get on.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Sean Dennis on Sun Apr 7 14:27:48 2019
    On 06 Apr 2019 at 09:49p, Sean Dennis pondered and said...

    FE is known to strip out seen-bys with international mail. I don't remember exactly why but Andrew Leary was explaining it to me a while back. Maybe something's happening there?

    That is true the system I run is doing that, it's a hard coded feature in FE from days before the fidoweb stuff we seem to do now. I plan to migrate the
    HUB to Mystic (as others also use) but have not made the time to do the hours of work required in set up as of yet.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alan Ianson@1:153/757 to Paul Hayton on Sat Apr 6 20:07:50 2019
    If I see anything I'll let you know, in any case we'll get to the bottom
    of it.

    Sure thing Al. I'm not aware of anything like that happening with either FastEcho or Mystic so would be interested to hear how you get on.

    I have a couple .pkt's that contain the same message, one from 153/7715 (using Squish I think) and one from 153/250 (using Mystic I think). The one from 153/250 has some ^M characters that I think are a carriage return that the one from 153/7715 doesn't have.

    A little early to draw conclusions but I think we are narrowing it down.

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Paul Hayton@3:770/100 to Alan Ianson on Sun Apr 7 15:15:18 2019
    On 06 Apr 2019 at 08:07p, Alan Ianson pondered and said...

    I have a couple .pkt's that contain the same message, one from 153/7715 (using Squish I think) and one from 153/250 (using Mystic I think). The one from 153/250 has some ^M characters that I think are a carriage
    return that the one from 153/7715 doesn't have.

    Yep if anything it should be reproducible, but if Mystic we need to confirm
    the version the node is running, else it may be trying to fix something that has been fixed already.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From mark lewis@1:3634/12.73 to Sean Dennis on Sun Apr 7 05:23:24 2019

    On 2019 Apr 06 21:49:52, you wrote to Alan Ianson:

    From what I've been able to gather messages are being changed
    somewhere along the path, lines being wrapped at 80 columbs.

    FE is known to strip out seen-bys with international mail. I don't remember exactly why but Andrew Leary was explaining it to me a while back.

    because of nets existing in more than one zone... by stripping the seenbys, then duplicate net/node in different zones can get the message instead of not because they were already listed in the seenby lines... FE wasn't the only tosser doing this, either... there were numerous ones that did this but they may have offered it as a configuration option instead of hardcoded...

    Maybe something's happening there?

    i don't believe so... AFAIK, FE doesn't reformat messages... i've never heard of it in all the years i ran FE...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Dateline NY: Enraged Cow Goes After Unsuspecting Farmer With Gun.
    ---
    * Origin: (1:3634/12.73)
  • From Carol Shenkenberger@1:275/100 to mark lewis on Sat Apr 13 11:12:12 2019
    Re: a sense of belonging
    By: mark lewis to Maurice Kinal on Tue Apr 02 2019 11:12 pm

    on my main system, ASIAN_LINK is connected to these systems:

    1:116/116
    1:123/25
    1:123/50
    1:123/150
    1:123/755
    1:135/300
    * 1:153/7715
    * 1:154/10
    * 1:261/38
    1:3634/12.73
    * 1:3634/15
    1:3634/27
    1:3634/50

    the ones with '*' are known to have multiple links for echos... they may or may not have multiple feed links for ASIAN_LINK... there may be a few more in the above list that have multiple links but i'm not sure without doing some extensive digging... digging that i'm just not going to do unless there's a real problem that i need to solve...

    1:261/38*
    1:275/100*
    1:275/89 91 98 96 93 95 362

    Feeds here from Janis

    xxcarol
    --- SBBSecho 2.12-Win32
    * Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)
  • From Carol Shenkenberger@1:275/100 to mark lewis on Sat Apr 13 11:16:48 2019
    Re: a sense of belonging
    By: mark lewis to Maurice Kinal on Wed Apr 03 2019 12:05 am

    Here we go; "PATH: 3634/12 154/10 280/464 770/1 153/250 757". Sorry
    about the delay. I've got it narrowed down to two possiblities -
    770/1 or 153/250.

    unless i'm mistaken, at least one of those systems is running mystic
    which
    we know from recent discussions has not been properly writing seenby
    lines
    to the messages it processes... it is not too hard to imagine that it may also be reformatting messages... i don't understand why things that have been working properly in it since v1.10 or v1.11 are being changed now
    and
    breaking stuff...

    All I know if I have several Mystic nodes here and they tend to flag netmail as
    'direct' then route it to me to deliver direct. When I was off Bob Seaborn, I could remove the direct flag and route it to him and he was able to delver, but
    something doesnt work that way with Janis's software so she sends it back to me
    as udeliverable.

    I deliver it after adding them in my mailer if not already there.

    xxcarol
    --- SBBSecho 2.12-Win32
    * Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)