Nope, I'm direct to 320/219.
P@TH: 320/219 292/854
Hi DM,
A discussion in fido was started based on the PATH kludge on one of my echomails.
My system 3:632/509, exported a message and sent it directly to 1:320/259 - and from there would have been forwarded on to other systems.
Nope, I'm direct to 320/219.
P@TH: 320/219 292/854
A downstream system asked, (their view of the PATH kludge is above) why isnt my node address the first in the PATH statement?
Should it be?
I suspect that in your example, one of the echomail systems along the path (most likely 1:320/219) stripped the incoming PATH line(s) when the message was re-packed for a foreign zone.
I suspect that in your example, one of the echomail systems along the path (most likely 1:320/219) stripped the incoming PATH line(s) when the message was re-packed for a foreign zone.
So to understand if it did do that, can you confirm that you add "my" FTN address to the PATH during sbbsecho export (and thus by definition, it is the only address in the PATH, since I originated the message) ?
Re: PATH kludge on exported echomail
By: Digital Man to deon on Wed Feb 02 2022 04:56 pm
Hey DM
Thanks...
I suspect that in your example, one of the echomail systems along the path (most likely 1:320/219) stripped the incoming PATH line(s) when the message was re-packed for a foreign zone.
So to understand if it did do that, can you confirm that you add "my" FTN address to the PATH during sbbsecho export (and thus by definition, it is the only address in the PATH, since I originated the message) ?
Re: PATH kludge on exported echomail
By: deon to Digital Man on Thu Feb 03 2022 12:33 pm
I suspect that in your example, one of the echomail systems along the path (most likely 1:320/219) stripped the incoming PATH line(s) when the message was re-packed for a foreign zone.
So to understand if it did do that, can you confirm that you add "my" FTN address to the PATH during sbbsecho export (and thus by definition, it is the only address in the PATH, since I originated the message) ?
So I caught the packet that I export - and indeed I do not have a PATH kludge on the exported mail.
Is it a setting I have?
So I caught the packet that I export - and indeed I do not have a PATH kludge on the exported mail.
Is it being exported to a foreign zone?
Is it a setting I have?
Most likely. Check that ZoneBlind = true in your sbbsecho.ini file if you want your PATH and SEEN-BY lines to retain addresses when crossing zone boundaries.
You probably also want to set ZoneBlindThreshold = 4 (4 zones in FidoNet).
* (I assume the above is yes) - is the SEEN-BY scrubbed as well ? (my address *was* in the SEEN-BY, but I guess that makes sense, so the (foreign zone) system I'm exporting too doesnt send the message back to me?)
It depends on what rules you're following. When zones were introduced to FidoNet and for a long time after, the norm was strip PATH and SEEN-BY lines when the message crossed a zone boundry (because there could be ambiguity between 3:632/509 and 2:632/509, since neither the zone information is not included in the addresses on these lines).
Re: PATH kludge on exported echomail
By: Digital Man to deon on Wed Feb 02 2022 07:18 pm
Hey DM,
So I caught the packet that I export - and indeed I do not have a PATH kludge on the exported mail.
Is it being exported to a foreign zone?
Is it a setting I have?
Most likely. Check that ZoneBlind = true in your sbbsecho.ini file if you want your PATH and SEEN-BY lines to retain addresses when crossing zone boundaries.
You probably also want to set ZoneBlindThreshold = 4 (4 zones in FidoNet).
Thanks - Indeed, I had ZoneBlind = false, and ZoneBlindThreshold = 65535.
So this has raised a couple of questions:
* Does zoneblind=true result in the PATH being scrubbed when a message is being exported to another zone?
* (I assume the above is yes) - is the SEEN-BY scrubbed as well ? (my address *was* in the SEEN-BY, but I guess that makes sense, so the (foreign zone) system I'm exporting too doesnt send the message back to me?)
* When you scrub the PATH, do you add any other kludges to show that the scrubbing occured by me? (I've seen others with zonegating software create a GATE kludge that I guess could indicate which system the message was gated through (and thus that system reset the PATH/SEEN-BY kludges).
On 2022 Feb 02 16:56:08, you wrote to deon:
It depends on what rules you're following. When zones were introduced to FidoNet and for a long time after, the norm was strip PATH and SEEN-BY lines when the message crossed a zone boundry (because there could be ambiguity between 3:632/509 and 2:632/509, since neither the zone information is not included in the addresses on these lines).
seenbys were stripped... paths were not unless maybe when gated between othernets...
So this has raised a couple of questions:
* Does zoneblind=true result in the PATH being scrubbed when a message is being exported to another zone?
I'm not sure what you mean by "scrubbbed" in this context. The PATH lines will be *retained* even when crossing zone boundaries when zoneblind=true and the zones in question are both <= ZoneBlindThreshold
http://wiki.synchro.net/config:sbbsecho.ini
* When you scrub the PATH, do you add any other kludges to show that the scrubbing occured by me? (I've seen others with zonegating software create a GATE kludge that I guess could indicate which system the message was gated through (and thus that system reset the PATH/SEEN-BY kludges).
No. And again, not really sure what you mean by "scrub" here. You mean remove/delete?
Re: PATH kludge on exported echomail
By: Digital Man to deon on Thu Feb 03 2022 11:08 am
So this has raised a couple of questions:
* Does zoneblind=true result in the PATH being scrubbed when a message is being exported to another zone?
I'm not sure what you mean by "scrubbbed" in this context. The PATH lines will be *retained* even when crossing zone boundaries when zoneblind=true and the zones in question are both <= ZoneBlindThreshold http://wiki.synchro.net/config:sbbsecho.ini
"scrubbed" = delete, ie: remove all existing entries.
So with zoneblind = false:
sbbsecho removes all *existing* PATH items and SEEN-BY items and thus the resulting exported message has no "PATH" items, and only has the SEEN-BY of any exported nodes in the target zone. (which by definition doesnt include itself)?
* When you scrub the PATH, do you add any other kludges to show that the scrubbing occured by me? (I've seen others with zonegating software create a GATE kludge that I guess could indicate which system the message was gated through (and thus that system reset the PATH/SEEN-BY kludges).
No. And again, not really sure what you mean by "scrub" here. You mean remove/delete?
How do "downstream" systems know that *my* system is the one that cleared the PATH/SEEN-BY, especially when it's obious the message originated from a different zone (because it has a different zone number in the Origin)?
Perhaps it would be worthwhile using the GATE kludge (or something else appropraite) to record that, especially if somebody was trying to debug circular paths or duplicate messages?
* Does zoneblind=true result in the PATH being scrubbed when a message is being exported to another zone?
I'm not sure what you mean by "scrubbbed" in this context. The PATH lines will be *retained* even when crossing zone boundaries when zoneblind=true and the zones in question are both <= ZoneBlindThreshold http://wiki.synchro.net/config:sbbsecho.ini
"scrubbed" = delete, ie: remove all existing entries.
So with zoneblind = false:
sbbsecho removes all *existing* PATH items and SEEN-BY items and thus the resulting exported message has no "PATH" items, and only has the SEEN-BY of any exported nodes in the target zone. (which by definition doesnt include itself)?
No. In ZoneBlind mode, the PATH and SEEN-BY items are retained and amended, as if the message was inter-zonal.
Re: PATH kludge on exported echomail
By: mark lewis to Digital Man on Thu Feb 03 2022 07:02 am
On 2022 Feb 02 16:56:08, you wrote to deon:
It depends on what rules you're following. When zones were introduced to FidoNet and for a long time after, the norm was strip PATH and SEEN-BY lines when the message crossed a zone boundry (because there could be ambiguity between 3:632/509 and 2:632/509, since neither the zone information is not included in the addresses on these lines).
seenbys were stripped... paths were not unless maybe when gated between othernets...
SBBSecho stripped the PATHs (and still does) when crossing zone boundaries, except for the ZoneBlind cases.
2. Any existing PATH nodes that are not in *your* system's zone are removed from existing PATH lines. If you have an AKA address in the same zone as the destination, that AKA address will be added to the last PATH line.
This is based on my own analysis of the source code (https://gitlab.synchro.net/main/sbbs/-/blob/master/src/sbbs3/sbbsecho.c) but you can check my understanding if you like (search for "foreign_zone").
Actually, now that I look look at that code more closely, it's not that the PATH lines are "stripped" but rather "filtered" (points and nodes with foreign zones are removed).
Re: PATH kludge on exported echomail
By: Digital Man to deon on Thu Feb 03 2022 06:30 pm
Howdy,
2. Any existing PATH nodes that are not in *your* system's zone are removed from existing PATH lines. If you have an AKA address in the same zone as the destination, that AKA address will be added to the last PATH line.
This is based on my own analysis of the source code (https://gitlab.synchro.net/main/sbbs/-/blob/master/src/sbbs3/sbbsecho.c) but you can check my understanding if you like (search for "foreign_zone").
Line 3792: if(foreign_zone(addr.zone, paths.addr[u].zone) || paths.addr[u].point)
Is sbbsecho allowing for a 3D/4D/5D item in the PATH kludge?
(I'm wondering how you get a "zone" (or a "point") from the PATH kludge, which I've only ever seen as a 2D address - but then it seems gen_psb() can parse 4D addresses in the PATH?)
The rest of the code looks like it only ever writes a 2D address.
Did I understand that right?
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 232:16:55 |
| Calls: | 55 |
| Calls today: | 1 |
| Files: | 50,127 |
| D/L today: |
35 files (4,430K bytes) |
| Messages: | 275,422 |