@MSGID: 1:153/153 0a000719
@PID: Oblivion/2 v2.40beta1
@USERNOTE: Sysop
@PATH: 153/153 757 280/464 103/705 218/700 229/426
test
Autosig...?
--- Oblivion/2 v2.40beta2
* Origin: silentnode.ddns.net:6400 (1:153/153)
@MSGID: 1:153/153 0a000719
@PID: Oblivion/2 v2.40beta1
@USERNOTE: Sysop
test
Autosig...?
--- Oblivion/2 v2.40beta2
* Origin: silentnode.ddns.net:6400 (1:153/153)
SEEN-BY: 103/705 124/5016 134/100 153/135 143 148 149 151 153 757 7083 SEEN-BY: 154/10 30 203/0 221/0 6 240/1120 5832 263/1 280/464 5003 5006 SEEN-BY: 280/5555 292/854 8125 301/1 310/31 341/66 234 396/45 423/120 SEEN-BY: 460/58 467/888 633/280 712/848 770/1 3634/12 5020/400
@PATH: 153/153 757 280/464
test
Autosig...?
123
123
456? possibly?
123
456? possibly?
Dont forget 789 though.
123
456? possibly?
Dont forget 789 though.
Dont forget 789 though.
@TZUTC: -0500
@MSGID: 12.fidonet_fidotest@1:123/4040 2cfcf3fd
@PID: Synchronet 3.20d-Win32 master/500ef7050 Mar 03 2025 MSC 1942
@TID: SBBSecho 3.23-Win32 master/500ef7050 Mar 03 2025 MSC 1942
@COLS: 80
@BBSID: THUNDER
@CHRS: ASCII 1
@NOTE: SlyEdit 1.89e (2025-02-09) (ICE style)
@PATH: 123/4040 3634/12 154/10 280/464 103/705 218/700 229/426
Having some issues with fido out of the blue sending test.
--- SBBSecho 3.23-Win32
* Origin: Thunder-Line BBS - thunder.synchro.net (1:123/4040)
--- SBBSecho 3.23-Win32154/10 280/464 103/705 218/700 229/426 Having some issues with fido outGot you here.
07 Sep 25 12:46:57 Matthew Asham (1:153/149.42) wrote:
==== begin of the message ====
@TZUTC: -0700
@MSGID: 1:153/149.42 1E389012
Noticed a response I sent on Saturday didn't make its way out - hopefully not shadow banned by the gods of upstream!
-+- BinktermPHP v1.4.5
+ Origin: myPoint System (1:153/149.42)
SEEN+BY: 19/10 134/100 153/135 143 148 149 151 153 757 7083 154/10 218/840
SEEN+BY: 221/1 6 360 280/464 301/1 335/364 341/66 234 460/58 3634/12 5020/1042
@PATH: 153/149 757 221/6
==== end of the message ====
Noticed a response I sent on Saturday didn't make its way out - hopefully n shadow banned by the gods of upstream!
Noticed a response I sent on Saturday didn't make its way out - hopefully shadow banned by the gods of upstream!
What does that mean, "shadow banned"
What does that mean, "shadow banned"
It means silently discarded. Like if someone sets up a filter to silently discard posts from a certain sender.
From: Matthew Asham
Date: 2025-09-08 12:42:43.323958
Subject: Re: test
What does that mean, "shadow banned"
It means silently discarded. Like if someone sets up a filter to silently discard posts from a certain sender.I suppose in fidonet parlance that would be a twit filter?
Noticed a response I sent on Saturday didn't make its way out -
hopefully not shadow banned by the gods of upstream!
testing
--- SBBSecho 3.29-Win32
* Origin: Wicked Garden - wgbbs.ddns.net - Melbourne, Vic. (3:633/414)
testing
testing
Test failed. You do not exist.
https://nodehist.fidonet.org.ua/?address=3:633/414
27 Sep 25 16:37, you wrote to Hdt:
testing
Test failed. You do not exist.
https://nodehist.fidonet.org.ua/?address=3:633/414
Does on my list:
,414,Wicked_Garden_BBS,Burnside_Vic,Hung_Tran,-Unpublished-,300,CM,IBN:w gbbs.ddns.net
%-;
testing
--- SBBSecho 3.29-Win32
* Origin: Wicked Garden - wgbbs.ddns.net - Melbourne, Vic. (3:633/414)
testing
@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)
Here is a reply via Synchronet's NNTP service. Maybe someone can let me know if there is two PATH kludge lines here, too.
If not, it could be specific to Golded accessing the Synchronet message bases (full support is nowhere near, and Golded uses very old SMB libraries, if I'm not mistaken).
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?
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 14 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 125:50:14 |
| Calls: | 184 |
| Files: | 21,502 |
| Messages: | 81,962 |
