Everything is as it should be ... SNAFU.
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.
what are the paths being taken to your system?
are you familiar with the non-entity known as the fidoweb?
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?
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? ;-)
what are the paths being taken to your system?
i have a direct connection with him for several echos
you understand the premise behind it? multiple feed links for
each area?
on my main system, ASIAN_LINK is connected to these systems:
digging that i'm just not going to do unless there's a real
problem that i need to solve...
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.
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.
msgon my main system, ASIAN_LINK is connected to these systems:
I recognize a number of those, none of which ever reformatted any of my
bodies to my knowledge.
at least one of those systems is running mystic
it is not too hard to imagine that it may also be reformatting
messages
like when a link goes down for some time
the main one being the stripping of moderator's control/rights
over their echo...
@MSGID: 1:153/7001.2989 5ca3cfb1
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
2 Different node/point numbers?
nodelist.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
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. :-)
at least one of those systems is running mystic
This is starting to sound familiar.
fixedit 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
by now. There is really no good reason for it ... is there?
For instance if someone wants to send a reply by netmail which of
the two should be used?
I use a more or less default golded configuration regarding
charsets.
systems anyway that need the CHRS kludge for this.
normal processing and passing on of messages should not do that
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.
Are you seeing messages getting changed along the way?
we could test things with if you are interested in doing that.
theFor 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
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?
So it doesn't seem like a good idea to add a random point number
to the MSGID
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
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 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:::
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.
Just as a point of focus for me, what changes are you seeing?
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.
@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.
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) 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
my old system used to archive both inbound and outbound PKTs
specifically for research like this...
i see it here but GoldEd's reflowing corrects it
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...
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...
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.
From what I've been able to gather messages are being changed
somewhere along the path, lines being wrapped at 80 columbs.
From what I've been able to gather messages are being changed somewhere along the path, lines being wrapped at 80 columbs.
If I see anything I'll let you know, in any case we'll get to the bottom of it.
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?
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.
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?
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...
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...
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 157:53:06 |
| Calls: | 162 |
| Files: | 5,334 |
| Messages: | 221,585 |