I have a chap in Xxxxxx looking to contact someone in Z2 to get help to...
set up with a Fidonet address.
You just sent me a netmailed message about a possible node in Z2.
I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".
Can you have a look please?
Hi Paul,
You just sent me a netmailed message about a possible node in Z2.
I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".
I responded to your message and your system dumps the netmail back on
my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".
Looks like someone's system is trying to use a ZoneGate from Z2 to Z3.
Of course, these haven't existed for quite some time...
The ZoneGate option is normally selected on the sending system. When it is selected, the destination address in the message header is changed from the actual destination to the ZoneGate system, (origin zone:origin zone/destination zone) with the actual destination remaining in the INTL kludge line. With most connections in FidoNet being made over the internet these days, the ZoneGates were considered unnecessary overhead and thus removed from the nodelist.
In this case, I wonder if Ward accidentally selected the ZoneGate option when replying to your message. Your system apparently saw that the incoming packet was addressed to 2:2/3 and sent it back to Ward based
on your routing rules.
Looks like someone's system is trying to use a ZoneGate from Z2
to Z3. Of course, these haven't existed for quite some time...
Hi Andrew
is this something I need to check on my end?
If so where do I need to look?
Thanks for your reply. Let's see if Ward can shed any further light.
As far as I can tell you are sending me netmail addressed to 2:2/3.0 ...
In this case, I wonder if Ward accidentally selected the ZoneGate option when replying to your message.
Yes, it looked to me like the incoming message from him was addressed to 2:2/3 so my system just routed it back to him as per my routing rules.
Hey Paul,
Thanks for your reply. Let's see if Ward can shed any further
light.
I was hoping to avoid a Roy Witt scenario, but here we are anyway.
But it's Sunday, I haven't had my morning coffee yet. Traditionally on Sunday mornings we eat a soft-boiled egg with a "pistolet", I don't
know how to translate that into english, it's not a gun but a small
French bread. Americans would call it "a bun" but they're sometimes
such culinary bastards as that would remind me immediately of
McDonalds, BK etc ... Think of the same bun, but fresh and crunchy.
A "roll". we call it a "roll".
Thank you for looking into this, but after this one single line you've already de-railed ... For test-purposes I created a new message and it is addressed to 3:770/100 .... This is how it looks ...
Any chance you can make a new message, but instead of "delivering it", capture the packet that gets created and make it available? Paul and I
run a very similar setup and I wasnt aware that hpt did that - so I'd be keen to understand if it does, under what cirmcustances it does and how
it's controlled.
Can you zip the packet up and drop it to me please ? 3:633/509.
Yes, it looked to me like the incoming message from him was addressed 2:2/3 so my system just routed it back to him as per my routing rules.
Did you examine the inbound pkt-file?
Mu bet is on "no" ...
Hey Paul,
Thanks for your reply. Let's see if Ward can shed any further light.
I was hoping to avoid a Roy Witt scenario, but here we are anyway.
Hey Paul,
As far as I can tell you are sending me netmail addressed to 2:2/3.0 .
Thank you for looking into this, but after this one single line you've already de-railed ... For test-purposes I created a new message and it
is addressed to 3:770/100 .... This is how it looks ...
So, yes, there is a problem at your site and I suspect it is software related.
Zonegates are not an issue here, I have never used them, you cannot find them anywhere here, they were dropped from the nodelist here in March 2009.
It "is" a software-problem, or a case of set-up, on your side, Paul.
For the ones loving discussions, here's the log of my system delivering that netmail at Paul's system and the immediate return of the altered version.
************************************************************************** Please, Paul, no Roy Witt stuff here by turning the issue around, I've been too long in this business to not understand it.
And don't take this personal ..
Can you zip the packet up and drop it to me please ? 3:633/509.
I've just tried in good faith to get your email contact details confirmed via netmail so I can pass them along to a chap who is in Z2 wanting to
talk to someone in Fido about getting a node number.
Why you feel the need to invoke this sentiment and his name in a thread that you kicked off and I am just doing my best to respond to lord knows.
That RC is Bjorn Felten and he can be reached by netmail at b@felten.se. If your guy sends email overthere it will be handled.
Any chance you can make a new message, but instead of "delivering it", capture the packet that gets created and make it available? Paul and I
run a very similar setup and I wasnt aware that hpt did that - so I'd be keen to understand if it does, under what cirmcustances it does and how it's controlled.
At some point in time, I coined the phrase "Pulling a Witt" meaning that when confronted with an issue the other side by definition must be wrong without looking into the matter. Roy was a master in that, especially in turning the argument around.
So when I got totally confused at what was happening and went to
echomail, here was Andrew Leary suggesting I was accidentally the
culprit anyway by unknowingly triggering a zonegate ... something which doesn't exist in D'Bridge.
And remember, I wrote "Don't take it personal". When someone calls me an asshole, I don't take it personal either, after all that person may even be right.
Can you zip the packet up and drop it to me please ? 3:633/509.
I just delivered it at your system.
Also I released the message to Paul and it came back within a second.
Can you zip the packet up and drop it to me please ? 3:633/509.
I just delivered it at your system.
Also I released the message to Paul and it came back within a second.
Got it, thank you.
And indeed, from your side it seems to be addressed correctly - so I think I would also be able to process it (if my hpt system was servicing my fido feed).
Validated on my site:
https://clrghouz.bbs.dege.au/pkt
Paul, indeed it looks like it might be your side that is modifying and doing something to that packet? Certainly does seem odd whats going on...
It infers you think I am motivated to act in some negative fashion
towards you and I was not. I fail to see why I should not take it personally when you write to me so explicitly in this manner.
I was wrong...
Ward, I didnt read my dump fully.
Ward, it does appear to be your system, that is addressing the "packet" to Paul at 3:770/1, but the "netmail" inside the packet file, is addressed to "2/3".
So it would appear to be from your side...
Ward Dossche wrote to Paul Hayton <=-
Why you feel the need to invoke this sentiment and his name in a thread that you kicked off and I am just doing my best to respond to lord knows.
That is a very good question.
deon wrote to Ward Dossche <=-
Ward, I didnt read my dump fully.
Ward, it does appear to be your system, that is addressing the
"packet" to Paul at 3:770/1, but the "netmail" inside the packet
file, is addressed to "2/3".
So it would appear to be from your side...
Hi Paul,
You just sent me a netmailed message about a possible node in Z2.
I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".
**************************************************************************** Date: 21 Jan 23 23:37:52
From: Ward Dossche on 2:292/854 Many-Glacier (020) in Mortsel
To: Paul Hayton on 2:2/3 Unlisted node in B
Subj: Your question ____________________________________________________________________________ INTL 2:2/3 2:292/854
TZUTC: 0100
FLAGS A/S
I have a chap in Xxxxxx looking to contact someone in Z2 to get help to set up with a Fidonet address...
Via 2:292/854@Ward_Dossche @20230121.223859.UTC O/T-Track+ 2.85
Via 3:770/1 @20230121.224349.UTC hpt/lnx 1.9 2022-07-03
Via 2:292/854 @20230121.234424 D'Bridge 4 *****************************************************************************
Can you have a look please?
Sorry, pressed send by mistake:
I was wrong...
Ward, I didnt read my dump fully.
Ward, it does appear to be your system, that is addressing the
"packet" to Paul at 3:770/1, but the "netmail" inside the packet
file, is addressed to "2/3".
So it would appear to be from your side...
Sorry, pressed send by mistake, here is the detail:
00000030: 03 00 00 00 00 00 00 00 00 00 02 00 56 03 03 00 [............V...]
00000040: 24 01 02 00 01 00 00 00 32 32 20 4a 61 6e 20 32
[$.......22 Jan 2]
00000050: 33 20 20 32 33 3a 32 32 3a 30 33 00 50 61 75 6c [3 23:22:03.Paul]
More info, for those interested:
A packet message starts after the packet header (which finishes at
0x3a) and starts with 0x02 0x00 (FTS-0001.16)
Then:
* 0x56 0x03 (0x356 = 854) - Ward originating node
* 0x03 0x00 (0x003 = 3) - designation node
* 0x24 0x01 (0x124 = 292) - Ward originating net
* 0x02 0x00 (0x002 = 2) - destination net
Ward, it seems you are packing the message incorrectly.
It appears that the version of D'Bridge 4 that Ward is using
(01-01-2023?) is packing messages as if they were to be sent through a zonegate. The packet header is properly addressed to the destination,
but the message(s) in the packet are addressed to the zonegate
address. This appears to happen regardless of whether or not you
select the "Use Zonegate" flag in D'Bridge's editor. It also seems to happen even on messages flagged as Crash or Direct.
That is a very good question.
One which is very easy to answer. It's because you're a cratchety old asshole, through and through.
Ward, it does appear to be your system, that is addressing the "packet"
to Paul at 3:770/1, but the "netmail" inside the packet file, is
addressed to "2/3".
Sorry, pressed send by mistake:
I was wrong...
Ward, I didnt read my dump fully.
This was the same question that I asked of Paul, but really needs to be asked of Scott. I too am curious why his system is forwarding it on...
Yes, sure. I expect it will be the same, but lets confirm...
No sweat ... now what I am mystified about is that when I send a message to Paul routed via Scott, it arrives at destination while following the same phylosophy it would have to be sent back ... same as the hundreds of netmails I exchanged with Janis for example.
Question: can I fabricate a dummy message for Paul to be routed via Scott and send it to you, zipped, to see how it looks there?
Even more interesting ... how come my netmail to you is not sent back with an undeliverable inexistant zonegate address ? Your system also should be sending mails addressed to you back then ...
Well, lets have some facts before we come to a conclusion. We have
confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included
or not.
If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of)
and if it doesnt, then we'll go down a different avenue of questions I'm sure :)
Are you connected here and reading?
This seems to be a D'Bridge bug in that case ...
Well, lets have some facts before we come to a conclusion. We have
confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included
or not.
Ward Dossche wrote to deon <=-
Well, lets have some facts before we come to a conclusion. We have confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included or not.
If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of) and if it doesnt, then we'll go down a different avenue of questions I'm sure :)
Isn't this exciting? Back to the old days of the pioneers ... :-)
This seems to be a D'Bridge bug in that case ...
This seems to be a D'Bridge bug in that case ...
Fixed.
If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of) and if it doesnt, then we'll go down a different avenue of questions I'm sure :)
Isn't this exciting? Back to the old days of the pioneers ... :-)
So your netmail to me was "zonegated" - and SBBS imported it.
Ward Dossche wrote to Mike Miller <=-
A "roll". we call it a "roll".
Ah yes, I was looking for the word but it didn't dawn.
Nevertheless, crunchy, not soft ...
Crousant (sp?). Based on the description, I suspect that is what many North Americans would call it. Those are, too, sometimes all soft.
Fancier ones are crisp on the outside, while flakey on the inside.
If you overbake, or let one sit out too long, they get crunchier inside.
On 23 Jan 23 09:06:54, Ward Dossche said the following to Nick Andre:
This seems to be a D'Bridge bug in that case ...
Fixed.
I can confirm a netmail from Ward arrived today that was processed
without issue. I'll reply to it in a minute. I have made no changes to settings at my end.
I can confirm a netmail from Ward arrived today that was processed
without issue. I'll reply to it in a minute. I have made no changes
to settings at my end.
And the reply got here as well. Seems there was an issue in D'Bridge which got dealt with rather immediately.
My appologies, Paul, for getting you upset ... the problem was elsewhere than what I expected.
We also found out that HPT seems to processes netmail differently
than other tossers. It seems to prevail the data in the message
header over that in the INTL kludge line. If either is more correct
than the other I don't know. And how do zonegates factor in to this?
We also found out that HPT seems to processes netmail differently than other tossers. It seems to prevail the data in the message header over that in the INTL kludge line. If either is more correct than the other I don't know. And how do zonegates factor in to this?
The INTL control paragraph shall be used to give information aboutthe zone numbers of the original sender and the ultimate
addressee of a message.
Notice the 'ultimate addressee'. Since the message already arrived in Z3 on Paul's system and Paul's system probably knows were to route/deliver mail for Z3 nodes. The address in the header (of the zonegate) shouldn't be used over the ultimate destination address in the INTL kludge. So in my opinion the behaviour of HPT is wrong here.
I was going to refresh my memory from the standards, but it seems that ftsc.org has not been renewed and now replaced by a common parked
page?
The INTL control paragraph shall be used to give information aboutthe
zone numbers of the original sender and the ultimate
addressee of a message.
Notice the 'ultimate addressee'. Since the message already arrived in Z3
on Paul's system and Paul's system probably knows were to route/deliver
mail for Z3 nodes. The address in the header (of the zonegate) shouldn't
be used over the ultimate destination address in the INTL kludge. So in
my opinion the behaviour of HPT is wrong here.
But what is the responsibilty of the destination address in the packed message header?
Since the wording is "shall be used to give information", and not "must be used to determine routing" its not definitive in my mind.
That just refers to the _addition_ of the INTL kludge which is not mandatory (I think). But when it's present there is no reason not to use it as intended...
It's just stupid when the INTL kludge shows the message is destined for your system (as the ultimate destination by defintion) to forward it to the address in the header.
That just refers to the _addition_ of the INTL kludge which is not
mandatory (I think). But when it's present there is no reason not to
use it as intended...
It's just stupid when the INTL kludge shows the message is destined for
your system (as the ultimate destination by defintion) to forward it to
the address in the header.
True.
But I also think that the 'router' should "route" it to the correct destination in the first place.
So if the sender intended it to go to a zone gate (or some other
system for "special processing" - and by definition in the current
zone), then the packed message header could be used to indicate that.
But if it is intended to processed by the destination system (ie: the address in the INTL kludge) then the packed message header should have that
address in it.
Otherwise, why have a destination in the packed message header? Make
it nulls, especially if intermediate systems are not going to look at
it anyway, or rather are only going to look at it if an INTL kludge
isnt present.
I was going to refresh my memory from the standards, but it seems that ftsc.org has not been renewed and now replaced by a common parked page?
But I also think that the 'router' should "route" it to the correct destination in the first place.
True but that was a different matter and a (fixed) bug in d'Bridge.
It's more redundant to also fill the message header fields with the destination address, just in case there is very old software on the route, that doesn't know about INTL kludges. And it's probably against the standards to put nulls in the message header for the destination address.
Notice the 'ultimate addressee'. Since the message already arrived in
Z3 on Paul's system and Paul's system probably knows were to
route/deliver mail for Z3 nodes. The address in the header (of the zonegate) shouldn't be used over the ultimate destination address in
the INTL kludge. So in my opinion the behaviour of HPT is wrong here.
So if the sender intended it to go to a zone gate (or some other system
for "special processing" - and by definition in the current zone), then
the packed message header could be used to indicate that.
Notice the 'ultimate addressee'. Since the message already arrived in
Z3 on Paul's system and Paul's system probably knows were to
route/deliver mail for Z3 nodes. The address in the header (of the
zonegate) shouldn't be used over the ultimate destination address in
the INTL kludge. So in my opinion the behaviour of HPT is wrong here.
When you input bad information you get bad results. I can't call hpt wrong because it followed the information it was given in the header, where one would expect to find the needed information.
No you have to consider both the header destination and INTL kludge destination before making the decision where to route or deliver
(locally) the message.
But if the ultimate destination in the INTL kludge is the local
system, there is no need to even look at what is in the header.
No you have to consider both the header destination and INTL kludge
destination before making the decision where to route or deliver
(locally) the message.
The address in the header is standard and INTL kludges are not.
It's more redundant to also fill the message header fields with the
destination address, just in case there is very old software on the
route, that doesn't know about INTL kludges. And it's probably against
the standards to put nulls in the message header for the destination
address.
I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists).
I generally dont like filling stuff in, if its not intended to be used
- perhaps that's just me.
What is clear though, the standard must be vague, given more than 1 software developer has implemented a different process logic for processing
netmails with those fields filled. (And hence why some of Ward's messages were being processed and delivered, and some were being sent on somewhere else to be delivered - but failed.)
I would normally say, lets get it clear and fixed up - but then that normally leads to a different discussion that normally doesnt end well :(
Mike Powell wrote to Ward Dossche <=-
A "roll". we call it a "roll".
Ah yes, I was looking for the word but it didn't dawn.
Nevertheless, crunchy, not soft ...
Crousant (sp?). Based on the description, I suspect that is what many North Americans would call it. Those are, too, sometimes all soft. Fancier ones are crisp on the outside, while flakey on the inside.
Ward Dossche wrote to Mike Powell <=-
If you overbake, or let one sit out too long, they get crunchier inside.
Gotta love that burned campfire-taste.
Trivia ... during the summer months of July and August there's a mass migration in Europe of tourists to the south ... Spain, Portugal,
Italy, Greece, Turkey ... and France.
Suddenly in the south of France there's an influx of 2 million tourists and bakeries simply cannot keep up with the demand for croissants at breakfast.
So industrial bakeries in Belgium bake humongous anounts of croissants, every day for 2 months, sometime during the afternoon. they are trucked
in a system timed like a Swiss clockwork to brussels airport, containerized and flown to the south of France in 4 freight 747s one to Marseille, one to Nice and the 2 others also go somewhere. They arrive after midnight, are immediately unloaded and the goodies are devived
over an army of delivery vans setting off to supermarkets, hotels, restaurant chains etc so that by 8am the vacationers can enjoy a
freshly baked typical French croissant.
I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists).
Non of the FTSC documents say that.
FTS-0001 is quite clear about what is supposed to be in the packed message header.
There is currently an election on going for FTSC standing members, maybe you should apply? ;-)
So if the sender intended it to go to a zone gate (or some other system for "special processing" - and by definition in the current zone), then the packed message header could be used to indicate that.
There are no zonegates.
I know, there was once - so the design was setup to use them right? I
dont know if the design has been "revised" since they are no longer in
used. (I couldnt go and validate).
Actually, in a properly set-up system a netmail addressed to a zonegate should be bounced by a tracker as those addresses don't exist.
If a person has no tracker installed, that person should not even process in-transit netmail.
No you have to consider both the header destination and INTL kludge
destination before making the decision where to route or deliver
(locally) the message.
The address in the header is standard and INTL kludges are not.
INTL kludges are described in FTS-4001, that's a standard!
I would normally say, lets get it clear and fixed up - but then that
normally leads to a different discussion that normally doesnt end well :(
There is currently an election on going for FTSC standing members, maybe you should apply? ;-)
I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists).
Non of the FTSC documents say that.
The address in the header is standard and INTL kludges are not.
INTL kludges are described in FTS-4001, that's a standard!
Yes, but they may or may not be present.
The error here is that the packet header was incorrect. That header should indicate the destination of the message if INTL kludges are present or not.
I'm not sure it would be against a standard to put nulls in afield
that a standard would describe "dont use in this case" (and in this
particular scenario, I think we are talking about if an INTL kludge
exists).
Non of the FTSC documents say that.
Actually, I think they do. Just found a copy of FTS-0001.016 (1995) and there are several references to fields being null if not used:
serialNo (* binary serial number (otherwise null)*)
password (* session password (otherwise null) *)
origZone (* zone of pkt sender (otherwise null) *)
destZone (* zone of pkt receiver (otherwise null)*)
So the concept of using null if a field is not used has been set.
I can confirm a netmail from Ward arrived today that was processed without issue. I'll reply to it in a minute. I have made no changes to settings at my end.
And the reply got here as well. Seems there was an issue in D'Bridge
which got dealt with rather immediately.
My appologies, Paul, for getting you upset ... the problem was elsewhere than what I expected.
Ward Dossche wrote to Mike Powell <=-
So industrial bakeries in Belgium bake humongous anounts of croissants, every day for 2 months, sometime during the afternoon. they are trucked
in a system timed like a Swiss clockwork to brussels airport, containerized and flown to the south of France in 4 freight 747s one to Marseille, one to Nice and the 2 others also go somewhere. They arrive after midnight, are immediately unloaded and the goodies are devived
over an army of delivery vans setting off to supermarkets, hotels, restaurant chains etc so that by 8am the vacationers can enjoy a
freshly baked typical French croissant.
... so that by 8am the vacationers can enjoy a
freshly baked typical French croissant.
And none the wiser, unless they know what you know. :)
I'm not sure it would be against a standard to put nulls in afield
that a standard would describe "dont use in this case" (and in this
particular scenario, I think we are talking about if an INTL kludge
exists).
Non of the FTSC documents say that.
So I was going to re-view the standard (but the website is down).
Does it say ignore the packed message header and use INTL if it exists instead?
So we are left with common sense and logic, how to apply them. ;-)
So we are left with common sense and logic, how to apply them. ;-)
Common sense and logic dictates that the address in the header is correct.
I am not against the INTL kludge. I like the INTL kludge as kludges go but the address in the header serves a purpose, and it should be correct.
Common sense and logic dictates that the address in the header is correct.
I am not against the INTL kludge. I like the INTL kludge as kludges go but >> the address in the header serves a purpose, and it should be correct.
The header doesn't contain the zone for the destination, so what is in the header is by definition incomplete, so it can't be the only source for the destination of the message, so you need what is in the INTL kludge, to be able to route a netmail.
So we are left with common sense and logic, how to apply them. ;-)
And it's not logical to forward a routed netmail to a zone-gate when it has already arrived at it's ultimate destination! Or has arrived in the destination zone.
And if you apply the reality of the modern fidonet, without zone-gates. You could just ignore the message header fields, if an INTL kludge is present.
Ward Dossche wrote to Mike Powell <=-
And none the wiser, unless they know what you know. :)
As with so many other things in Life ... 8-)
* The US is boycotting products from Russia
* Russia delivers oil to Europe
* In the refinery part of the Antwerp harbor JETA1 fuel is produced
from
Russian oil
* Every week two 75.000 tonnes fuel tankships leave from here for North
America to deliver jetfuel for JFK and EWR airports
1) Zone-gates are no longer used, or even exist. So something is wrong,
and the message shouldn't be forwarded to a non existent address when the address in the INTL kludge does exist, and is even the local system.
2) When the message is already outside of the zone of the sender, it's
not logical to send it back to the zone-gate in the zone of the sender.
1) Zone-gates are no longer used, or even exist. So something is
wrong,
and the message shouldn't be forwarded to a non existent address when
the address in the INTL kludge does exist, and is even the local
system. 2) When the message is already outside of the zone of the
sender, it's not logical to send it back to the zone-gate in the zone
of the sender.
The time-stamp and the INTL-kludge were also changed..
| Sysop: | Fercho |
|---|---|
| Lugar: | La Plata, Buenos Aires |
| Usuarios: | 33 |
| Nodos: | 10 (0 / 10) |
| Uptime: | 33:32:28 |
| Llamadas: | 118 |
| Archivoss: | 15,607 |
| Mensajes: | 33,523 |