@MSGID: 2:280/464 692497f3
@REPLY: 1:154/10 6924687a
@TID: FMail-lnx64 2.3.2.4-B20240523
@RFC-X-No-Archive: Yes
@TZUTC: 0100
@CHRS: CP850 2
@PID: GED+LNX 1.1.5-b20240604
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)
SEEN-BY: 19/10 50/109 103/705 104/117 124/5016
134/101 153/757 154/10 30
SEEN-BY: 201/0 203/0 218/840 221/0 1 6 360
240/1120 5832 263/1 280/464 5003
SEEN-BY: 280/5006 5555 292/854 8125 301/1 310/31
320/119 219 335/364 341/66
SEEN-BY: 341/234 396/45 423/81 120 460/58 463/68
633/280 712/848 770/1
SEEN-BY: 5000/111 5015/46 5020/400 715 846 848
1042 4441 12000 5030/49 1081
SEEN-BY: 5058/104 5060/900 5061/133 5075/128
5083/444
@PATH: 280/464 221/1 6 5020/1042 4441