@MSGID: 2:341/234.5885 692333cc
@PID: GED+W64 1.1.5-b20250409
@TID: SBBSecho 3.23-Win32 master/500ef7050 Mar 03 2025 MSC 1942
@BBSID: CYBNOT
@TZUTC: 0100
@CHRS: CP850 2
@PATH:
Hi,
Playing with SBBS...
Carlos
--- SBBSecho 3.23-Win32
* Origin: cyb synchronet point (2:341/234.5885)
^^^^^^@MSGID: 2:341/234.5885 692333cc
@PID: GED+W64 1.1.5-b20250409
@TID: SBBSecho 3.23-Win32 master/500ef7050 Mar 03 2025 MSC 1942
@BBSID: CYBNOT
@TZUTC: 0100
@CHRS: CP850 2
@PATH:
@MSGID: 2:341/234.5885 692333cc
@PID: GED+W64 1.1.5-b20250409
@TID: SBBSecho 3.23-Win32 master/500ef7050 Mar 03 2025 MSC 1942
@BBSID: CYBNOT
@TZUTC: 0100
@CHRS: CP850 2
@PATH:
^^^^^^
This is what I wanted to check. Messages exported from my SBBS point
have two PATH kludge lines, one of them empty (and inserted before the SEEN+BYs). :-m
Tommi's robot did not display it, so I guess some tosser removed it.
Thank you Sean!
23 Nov 2025 16:29, you wrote to me:
^^^^^^@MSGID: 2:341/234.5885 692333cc
@PID: GED+W64 1.1.5-b20250409
@TID: SBBSecho 3.23-Win32 master/500ef7050 Mar 03 2025 MSC 1942
@BBSID: CYBNOT
@TZUTC: 0100
@CHRS: CP850 2
@PATH:
This is what I wanted to check. Messages exported from my SBBS point
have two PATH kludge lines, one of them empty (and inserted before
the SEEN+BYs). :-m
Tommi's robot did not display it, so I guess some tosser removed it.
It is not in the msgbase here, so I think my hpt removed it.
This is what I wanted to check. Messages exported from my SBBS point
have two PATH kludge lines, one of them empty (and inserted before the SEEN+BYs). :-m
This is what I wanted to check. Messages exported from my SBBS point
have two PATH kludge lines, one of them empty (and inserted before the SEEN+BYs). :-m
It is not in the msgbase here, so I think my hpt removed it.
If you could, please check my last message and this one. This one is directly from the BBS itself.
I correct myself. My SBBS point does not export 2 PATH lines - only one (and empty one)
It seems that it's FMail adding another one.
So it seems that SBBS with point address sends PKTs with empty PATH kludge. FMail (the tosser at my bossnode) doesn't like it and adds
another PATH line.
I correct myself. My SBBS point does not export 2 PATH lines - only
one (and empty one) Sorry.
It seems that it's FMail adding another one.
So it seems that SBBS with point address sends PKTs with empty PATH
kludge. FMail (the tosser at my bossnode) doesn't like it and adds
another PATH line.
So it seems that SBBS with point address sends PKTs with empty
PATH kludge. FMail (the tosser at my bossnode) doesn't like it
and adds another PATH line.
Is it really a kludge line? Starting with a Ctrl-A (0x01) character?
Is it really a kludge line? Starting with a Ctrl-A (0x01) character?
Yes. This is how my node receives the PKTs from the SBBS point (I'm changing
0x01 to ^a, etc):
-+- SBBSecho 3.23-Win32
# Origin: cyb synchronet point (2:341/234.5885)
SEEN+BY: 341/234
^aPATH:
And this is how my node's FMail exports that to my links (including you):
-+- SBBSecho 3.23-Win32
# Origin: cyb synchronet point (2:341/234.5885)
^aPATH:
SEEN+BY: 341/234
^aPATH: 341/234
I found it, and I can confirm your findings. I can also see it's still present in .pkt files that left my system to my other links. But it
isn't present in my messagebase!?
BTW: I don't know if there is something to improve, it might just be a matter of GIGO. ;-)
BTW2: .pkt files that leave my point system don't have a path line at
all.
I found it, and I can confirm your findings. I can also see it's still
present in .pkt files that left my system to my other links. But it
isn't present in my messagebase!?
Difference between stored and forwarded, maybe?
BTW: I don't know if there is something to improve, it might just be a
matter of GIGO. ;-)
BTW2: .pkt files that leave my point system don't have a path line at
all.
That is what I was wondering..
1) Should a system setup as a point be sending an empty PATH kludge?
2) Should a system setup as a boss node be appending it's address to
an existing PATH kludge (even if it is empty),
rather than creating a new one?
Difference between stored and forwarded, maybe?
Of course, but I was just wondering why that happens.
BTW: I don't know if there is something to improve, it might just be
a matter of GIGO. ;-)
1) Should a system setup as a point be sending an empty PATH
kludge?
No, an empty path doesnt' add anything compared to no path at all, it
just takes up space.
2) Should a system setup as a boss node be appending it's address
to an existing PATH kludge (even if it is empty),
Or delete the empty one and create a new one. But the end result would
be the same. ;-)
rather than creating a new one?
Leaving the empty one in and create a new one, is the worse thing to do
I suppose.
^aPATH:
SEEN+BY: 341/234
^aPATH: 341/234
SEEN+BY: 221/6
^APATH: 221/6
Fmail seems to put the boss address to the PATH and SEENBY lines when exporting the msg.
Playing with SBBS...
^^^^^^@PATH:
This is what I wanted to check. Messages exported from my SBBS point have tw
Tommi's robot did not display it, so I guess some tosser removed it.
Difference between stored and forwarded, maybe?
Of course, but I was just wondering why that happens.
Since this is only Synchronet (point) -> FMail (boss), it might be nice to see
how other tossers setup as a boss handle the situation before creating a ticket anywhere.
BTW: I don't know if there is something to improve, it might just be
a matter of GIGO. ;-)
The beauty of kludge lines. ;)
1) Should a system setup as a point be sending an empty PATH
kludge?
No, an empty path doesnt' add anything compared to no path at all, it
just takes up space.
Although, one could argue the originating system creates the PATH kludge, and
all others after would append it. At one time I think there was an issue where
the originating system (as a point) would put it's 3D address in the PATH, which would screw with the boss node being seen as a dupe or an already processed message.
2) Should a system setup as a boss node be appending it's address
to an existing PATH kludge (even if it is empty),
Or delete the empty one and create a new one. But the end result would
be the same. ;-)
Sure, but should that be done with the boss node?
rather than creating a new one?
Leaving the empty one in and create a new one, is the worse thing to do
I suppose.
If there wasn't one to begin with, this wouldn't be an issue. I just don't know if there is /supposed/ to be an empty one created by the point (originating system), or not (per standards or whatever).
If not, it should be a Synchronet/sbbsecho issue, not something FMail needs to work around. Especially if the issue has never been seen
before this.
Well, a 3D address in a path line is not according to the standard and
as such a real bug...
I found it, and I can confirm your findings. I can also see it's still present in .pkt files that left my system to my other links. But it
isn't present in my messagebase!?
-+- SBBSecho 3.23-Win32
# Origin: cyb synchronet point (2:341/234.5885)
^aPATH:
SEEN+BY: 341/234
^aPATH: 341/234
Odd, it switches the order of the original Path line and the seen-by!?
Can you send me the original .pkt file from your SBBS point? So I can
try to reproduce it?
BTW2: .pkt files that leave my point system don't have a path line at
all.
SEEN+BY: 221/6
^APATH: 221/6
Fmail seems to put the boss address to the PATH and SEENBY lines
when exporting the msg.
There seems to be setting for that..
"Do not add the node number of the boss to the PATH kludge on point systems"
I found it, and I can confirm your findings. I can also see it's
still present in .pkt files that left my system to my other links.
But it isn't present in my messagebase!?
I can see the empty PATH kludge with GoldED, but just before the message text,
instead of after the SEENBY lines.
-+- SBBSecho 3.23-Win32
# Origin: cyb synchronet point (2:341/234.5885)
^aPATH:
SEEN+BY: 341/234
^aPATH: 341/234
Odd, it switches the order of the original Path line and the seen-by!?
Yes, it's weird.
Can you send me the original .pkt file from your SBBS point? So I can
try to reproduce it?
Ok, check your inbound.
BTW2: .pkt files that leave my point system don't have a path line at
all.
Mine neither...
I can see the empty PATH kludge with GoldED, but just before the
message text, instead of after the SEENBY lines.
So on top of the message where all the regular kludge lines are?
BTW2: .pkt files that leave my point system don't have a path
line at all.
Mine neither...
Except for your Synchronet point system...
So it seems that SBBS with point address sends PKTs with empty PATH
kludge. FMail (the tosser at my bossnode) doesn't like it and adds
another PATH line.
As a point, should it send no PATH kludge at all then?
As a point, should it send no PATH kludge at all then?
Not sure what is correct. Some tossers and point packages do, while
others don't.
I've checked .PKT's from several points I'm using or have tested.
These don't insert a PATH kludge:
- Winpoint
- OpenXP
- Crashmail II
- FMail (default, but can be enabled)
These insert a PATH kludge (including the bossnode's 2D address):
- HotdogEd
- Aftershock
- D'Bridge
I can see the empty PATH kludge with GoldED, but just before the
message text, instead of after the SEENBY lines.
So on top of the message where all the regular kludge lines are?
Yes, see here: https://www.cyberiada.org/fido/tmpfiles/fidotest-sbbs-point-snapshot.png
Not sure what is correct. Some tossers and point packages do, while
others don't.
This way, if FMail appends to that line, rather than creating a new
one and leaving the original alone, we know this should be the fix,
and can report it to Rob.
The simplest fix is to not create empty PATH lines at all (with or
without space)! ;-)
The simplest fix is to not create empty PATH lines at all (with or
without space)! ;-)
Is /not/ creating a PATH kludge covered anywhere in the holy grail of documented standards and/or proposals?
So far, all that has been pointed out is a document that shows the proper format of the PATH kludge.
Is /not/ creating a PATH kludge covered anywhere in the holy grail of documented standards and/or proposals?
As a point, should it send no PATH kludge at all then?
Not sure what is correct. Some tossers and point packages do, while
others don't.
I would imagine an empty PATH kludge would be better than inserting
the bossnode's 2D address *before* it gets to the bossnode!
I've checked .PKT's from several points I'm using or have tested.
Well done on the testing! You're absolutely killing it lately. ;)
These don't insert a PATH kludge:
- Winpoint
- OpenXP
- Crashmail II
- FMail (default, but can be enabled)
These insert a PATH kludge (including the bossnode's 2D address):
- HotdogEd
- Aftershock
- D'Bridge
Do messages coming from these display at the boss node if it's address
is already in the PATH?
Or do they get forwarded on without being stored in the message base?
So on top of the message where all the regular kludge lines are?
Yes, see here:
https://www.cyberiada.org/fido/tmpfiles/fidotest-sbbs-point-snaps
hot.png
It kind of makes sense, because the "^APATH:" line without the <space> after the ':' is just a kludge line. So I can see the logic in placing
it on top with the other kludge lines.
Not sure what is correct. Some tossers and point packages do, while
others don't.
Is there a way you could edit the raw message that Synchronet creates,
and add a space to the PATH kludge before it gets sent off to FMail?
This way, if FMail appends to that line, rather than creating a new
one and leaving the original alone,
we know this should be the fix, and can report it to Rob.
So on top of the message where all the regular kludge lines are?
Yes, see here:
https://www.cyberiada.org/fido/tmpfiles/fidotest-sbbs-point-snaps
hot.png
It kind of makes sense, because the "^APATH:" line without the <space>
after the ':' is just a kludge line. So I can see the logic in placing
it on top with the other kludge lines.
Yes.
BTW, did you check if you can also see that in GoldED, like in the screenshot?
Or do they get forwarded on without being stored in the message base?
They are stored and also get forwarded. This has never been an issue,
IIRC.
Hmm... IMO that would be more of a workaround than a fix. I think it would be better to just not add an empty PATH kludge.
This issue has now been addressed:
A bug report (at gitlab.synchro.net) would've been nice to have. :-)
A bug report (at gitlab.synchro.net) would've been nice to have. :-)
Sorry, I intended to... O:-)
 > A bug report (at gitlab.synchro.net) would've been nice to have. :-)
Sorry, I intended to... O:-)
Next time. :-)
There'll certainly more opportunities (bugs created/found) in the
future. lol
@MSGID: 72.fidonet_fidotest@2:341/234.5885 2da17d3c
@REPLY: 15424.fidotest@1:103/705 2da0aec8
@PID: Synchronet 3.21a-Win32 master/d27b45adf Dec 12 2025 MSC 1944
@TZUTC: 0100
@TID: SBBSecho 3.33-Win32 master/d27b45adf Dec 12 2025 MSC 1944
@BBSID: CYBNOT
@CHRS: UTF-8 4
@FORMAT: flowed
@NOTE: Mozilla Thunderbird
11/12/2025 22:50, Rob Swindell (1:103/705):
… > A bug report (at gitlab.synchro.net) would've been nice to have. :-)
Sorry, I intended to... O:-)
Next time. :-)
There'll certainly more opportunities (bugs created/found) in the
future. lol
Sure ;-)
I've just upgraded my Synchronet point to the dev version. This message should go out without that empty PATH kludge.
Carlos
--- SBBSecho 3.33-Win32
* Origin: cyb synchronet point (2:341/234.5885)
SEEN-BY: 103/705 124/5016 153/757 154/10 30 203/0 221/0 6 240/1120 5832 SEEN-BY: 263/1 280/464 5003 5006 5555 292/854 8125 301/1 310/31 341/66 SEEN-BY: 341/234 396/45 423/120 460/58 633/280 712/848 770/1 5020/400 @PATH: 341/234 280/464
@TZUTC: 0100
@MSGID: 72.fidonet_fidotest@2:341/234.5885 2da17d3c
@REPLY: 15424.fidotest@1:103/705 2da0aec8
@PID: Synchronet 3.21a-Win32 master/d27b45adf Dec 12 2025 MSC 1944
@TID: SBBSecho 3.33-Win32 master/d27b45adf Dec 12 2025 MSC 1944
@BBSID: CYBNOT
@CHRS: UTF-8 4
@FORMAT: flowed
@NOTE: Mozilla Thunderbird
11/12/2025 22:50, Rob Swindell (1:103/705):
 > A bug report (at gitlab.synchro.net) would've been nice tohave. :-)
Sorry, I intended to... O:-)
Next time. :-)
There'll certainly more opportunities (bugs created/found) in the
future. lol
Sure ;-)
I've just upgraded my Synchronet point to the dev version. This
message should go out without that empty PATH kludge.
Carlos
--- SBBSecho 3.33-Win32
* Origin: cyb synchronet point (2:341/234.5885)
SEEN-BY: 221/6 280/464 341/66 234
@PATH: 341/234
I've just upgraded my Synchronet point to the dev version. This
message should go out without that empty PATH kludge.
Confirmed! ;-)
I've just upgraded my Synchronet point to the dev version. This
message should go out without that empty PATH kludge.
Yep!
I've just upgraded my Synchronet point to the dev version. This
message should go out without that empty PATH kludge.
Yep!
But your tosser removed it anyway, didn't it?
You'd have to check the PKT my node sent to you... (No need to, I've already done)
I've just upgraded my Synchronet point to the dev version. This message should go out without that empty PATH kludge.
Confirmed! ;-)
I sure did before reporting. :)
| Sysop: | KJ5EKH |
|---|---|
| Location: | Siloam Springs, Ar. |
| Users: | 9 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 37:35:45 |
| Calls: | 31 |
| Files: | 75,986 |
| Messages: | 42,868 |
