Subj : Re: Problem at your system
To   : Wilfred van Velzen
From : deon
Date : Fri Jan 27 2023 10:20 am

 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)

You are viewing proxied material from vert.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.