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)

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)

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)

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)

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)

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)

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)

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)

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. I
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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 I
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)

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)

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)

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)

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)

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)

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)

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)

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)