Subj : Re: test
To   : Nick Boel
From : Wilfred van Velzen
Date : Mon Nov 24 2025 18:15:54

Hi Nick,

On 2025-11-24 08:06:40, you wrote to me:

 >>> Difference between stored and forwarded, maybe?

 >> Of course, but I was just wondering why that happens.

 NB> Since this is only Synchronet (point) -> FMail (boss), it might be nice to see
 NB> how other tossers setup as a boss handle the situation before creating a
 NB> ticket anywhere.

And nothing seems to be breaking anyway. It's just a bit annoying to see the empty path line. ;-)

 >>>> BTW: I don't know if there is something to improve, it might just be
 >>>> a matter of GIGO. ;-)

 NB> The beauty of kludge lines. ;)

 >>> 1) Should a system setup as a point be sending an empty PATH
 >>> kludge?

 >> No, an empty path doesnt' add anything compared to no path at all, it
 >> just takes up space.

 NB> Although, one could argue the originating system creates the PATH kludge, and
 NB> all others after would append it. At one time I think there was an issue where
 NB> the originating system (as a point) would put it's 3D address in the PATH,
 NB> which would screw with the boss node being seen as a dupe or an already
 NB> processed message.

Well, a 3D address in a path line is not according to the standard and as such a real bug...

 >>> 2) Should a system setup as a boss node be appending it's address
 >>> to an existing PATH kludge (even if it is empty),

 >> Or delete the empty one and create a new one. But the end result would
 >> be the same. ;-)

 NB> Sure, but should that be done with the boss node?

Where else? (Given the point system creates the empty path line, which it shouldn't)

 >>> rather than creating a new one?

 >> Leaving the empty one in and create a new one, is the worse thing to do
 >> I suppose.

 NB> If there wasn't one to begin with, this wouldn't be an issue. I just don't
 NB> know if there is /supposed/ to be an empty one created by the point
 NB> (originating system), or not (per standards or whatever).

Of course not.

 NB> If not, it should be a Synchronet/sbbsecho issue, not something FMail
 NB> needs to work around. Especially if the issue has never been seen
 NB> before this.

No software should create an empty path line. But it doesn't seem to break anything if it does, so I'm not going to change FMail to handle this exception more gracefully...

Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
 * Origin: FMail development HQ (2:280/464)

.