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? ;-)

Deon is, or was an FTSC member at one time.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: Re: Problem at your system
By: Wilfred van Velzen to deon on Tue Jan 24 2023 04:15 pm

Howdy,

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.

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.


...ëîåï
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Hi Alan,

On 2023-01-24 16:25:50, you wrote to me:

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.

Yes but they should be handled differently if the INTL kludge is present.

Bye, Wilfred.

--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)

Hi deon,

On 2023-01-25 11:29:16, you wrote to me:

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.

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.

Indeed, and it doesn't say so for any of the node and net fields in the pkt and message header. So null is not an option for those.


Bye, Wilfred.

--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)

On 24 Jan 2023 at 10:12a, Ward Dossche pondered and said...

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.

Thank you Ward.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

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.

And none the wiser, unless they know what you know. :)

Mike


... Spelling is a sober man's game
--- MultiMail/DOS
* Origin: possumso.fsxnet.nz * SSH:2122/telnet:24/ftelnet:80 (1:2320/107)

... so that by 8am the vacationers can enjoy a
freshly baked typical French croissant.

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

8-)

\%/@rd

--- DB4 - 20220519
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Hi deon,

On 2023-01-25 08:34:56, you wrote to me:

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.

So I was going to re-view the standard (but the website is down).

It's up again. ;)

Does it say ignore the packed message header and use INTL if it exists instead?

It doesn't say either way, if anything at all about how to apply the INTL kludge in conjuction with the message header fields. You should consider the INTL kludge was "invented", when zones (and zone gates) were introduced in fidonet, and they needed a way to sent netmail to other zones. Since the message header doesn't contain zone information.

So FTS-0001 just says:

o INTL <dest z:n/n> <orig z:n/n> - used for inter-zone address

FTS-0004 doesn't say much more.

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.


Bye, Wilfred.

--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)

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.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hi Alan,

On 2023-01-26 14:26:14, you wrote to me:

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.

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.
(Except when there is no INTL kludge, then the destination is in the same zone as the origin address, and it should never leave the zone. But I think such netmails haven't existed for at least 3 decades in fidonet)

Further the only known use case, where the header and INTL kludge contain a different address is when the message is sent to a zone-gate in the same zone as 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.


Bye, Wilfred.

--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)

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.

Sure, that is all true and always has been.

What I am saying is that the address in the header should be correct, no?

Question: When FMail sends a netmail out with the INTL kludges what address does it put in the header? Why?

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: Re: Problem at your system
By: Wilfred van Velzen to deon on Thu Jan 26 2023 04:15 pm

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.

Sorry, we can't go from "its not mentioned so you can't do that", to "its not mentioned so you need to use (my understanding of) common sense". I'd argue that the common sense is to follow the instructions in the packed message header as it was designed in FTS-0001.

But reading FTS-4001 - it states the purpose of the INTL kludge:

"The INTL control paragraph shall be used to give information about the zone numbers of the original sender and the ultimate addressee of a message."

This is a confusing sentence in English, because I can read it as "zone numbers of the sender and recipient", or I can read it as "zone number of the sender and address of the recipient". I believe the intention was the former, although I can see how some folks may argue for the later.

And further it mentions

"This gives both the originating system and the destination system as well as any intermediate routing systems unambiguous zone information even in a situation where one system may be active in a number of different (possibly non-FidoNet) zones."

(Hence why I believe it is the former intention above.)

It does not say, the address in the INTL kludge should be used for routing (outside of determining the ultimate destination zone), nor being authoritative that the address is to me, or a system I know.

Certainly, I agree that could be a "short cut" (after all we do like to take short cuts), if the function of a system to do special processing (eg: a zone gate) is to be bypassed. (And yes I know there are no defined ones at the moment/anymore.)

We have to remember that processing power back in the 90s was much less than it was today, and the goal (especially for hubs) was to process mail quickly.

Parsing a binary object, looking at a packet header to confirm that a packet is destined to me, is a quick way to see if I should process the rest of the contents. I have many packets in my inbound that have been rejected because somebody having a bad config and my tosser ignoring them "not to us". (Should my tosser have processed the contents anyway?)

If the packet is to us, its easy to identify packed messages (enclosed between 0x02 0x00 and the 4th 0x00 after 0x0e chars.) If the destination in the packed header message is not my 2D, forward the whole data to the next system in the path to that 2D destination. I do agree, now that there are no zonegates that 2D address is probably always the recipients 2D.

If the packed message header is me, then import the message that I've just read.

The only difference was a zone gate, who would recognised the {srczone}/{dsgzone} syntax in the packed message header and then look for the string INTL and the string contents, probably convert them to integers, and determine the next destination zone and route it appropriately (after repacking it with update headers). (I don't think a zonegate had any reason to import messages?). A more expensive processing activity that a general hub wouldn't have needed to do.

So, since Scotts system correctly forwarded the message onto Paul, and Scott is Z3C, I can only assume is RNTrack did that (since he is logically the right person to run with address 2/3)? Paul's didn't, because he has no reason to run with that address. And while zonegates are no longer in use, only he can answer why his system correctly forwarded on the message. We know why Paul's didn't.

So as this network has evolved, and processing power has got faster, its no longer an issue for every system to read a message fully and do what it thinks it should do to an incoming mail packet (there are less of them too as well). If we are going to change the "accepted way" of doing that, we should revise those documents - and perhaps even update the packet format, since the packed header source and destination are irrelevant if we are to depend on an INTL kludge.

I'll get some popcorn now...


...ëîåï
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

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

Yeah, over here there has been some skepticism regarding how much we are
really boycotting Russian products. ;)



... Tell me, is something eluding you, Sunshine?
--- MultiMail/DOS
* Origin: possumso.fsxnet.nz * SSH:2122/telnet:24/ftelnet:80 (1:2320/107)

Wilfred,

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..

\%/@rd

--- DB4 - 20220519
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Hi Ward,

On 2023-01-27 01:17:54, you wrote to me:

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..

If that's so, then there are 2 other bugs in hpt... There's no reason to ever change those on in transit netmails.

Bye, Wilfred.

--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)