Subj : Re: Problem at your system
To : deon
From : Wilfred van Velzen
Date : Tue Jan 24 2023 01:31 pm
Hi deon,
On 2023-01-24 22:45:57, you wrote to me:
>> 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.
de> True.
de> But I also think that the 'router' should "route" it to the correct
de> destination in the first place.
True but that was a different matter and a (fixed) bug in d'Bridge.
de> So if the sender intended it to go to a zone gate (or some other
de> system for "special processing" - and by definition in the current
de> zone), then the packed message header could be used to indicate that.
That is how it should be done as I understand it. (But Ward's system, because of the bug, didn't route it to the (non existent) zonegate.)
de> But if it is intended to processed by the destination system (ie: the
de> address in the INTL kludge) then the packed message header should have that
de> address in it.
That's the case for non gated messages (normally).
de> Otherwise, why have a destination in the packed message header? Make
de> it nulls, especially if intermediate systems are not going to look at
de> it anyway, or rather are only going to look at it if an INTL kludge
de> isnt present.
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.
Bye, Wilfred.
--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)
