*** Answering a msg posted in area 'ftsc_public'.

06 Jul 19 16:34, Andrew Leary wrote to Alan Ianson:

770/1 is running Fastecho. I believe FE is also a known good entity,
although it strips seen-bys when tossing to an out of zone link.

FastEcho also has a problem with the .PKT forwarding function.

Oh? Can you tell more about this?

I sent details to Tobias Burchhardt a few months back, but he wasn't hopeful that he would be able to fix it.

:(

'Tommi

--- GoldED+/EMX 1.1.5-b20180707
* Origin: rbb.fidonet.fi (2:221/360)

Hello Tommi!

07 Jul 19 19:46, you wrote to me:

FastEcho also has a problem with the .PKT forwarding function.

Oh? Can you tell more about this?

Basically, if you receive a .PKT file destined for one of your downlinks, it should be placed unaltered in the temporary outbound, to be archived for the destination along with any other mail you are tossing. However, it appears from my testing that certain .PKT header fields (including the .PKT password) are overwritten with the password you have defined for that downlink. Of course, this causes an issue if the originating node has a different password defined for the destination. There is also a minor issue with .PKT endings, as the forwarded .PKTs end up with an extra 2 NUL bytes tacked onto the end.

I sent details to Tobias Burchhardt a few months back, but he
wasn't hopeful that he would be able to fix it.

:(

It's too bad, because other than the cross-zone SEEN-BY stripping and these issues with forwarding .PKTs, the software is virtually bullet-proof.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

 AL>> FastEcho also has a problem with the .PKT forwarding function.

 TK> Oh? Can you tell more about this?

Basically, if you receive a .PKT file destined for one of your
downlinks, it should be placed unaltered in the temporary outbound,
to be archived for the destination along with any other mail you are
tossing. However, it appears
from my testing that certain .PKT header fields (including the .PKT
password) are overwritten with the password you have defined for that downlink. Of course, this causes an issue if the originating node
has a different password defined for the destination.

Ok, I see. I was using that .pkt forwarding thing between my tossers,
but there were no pkt passwords, so I never noticed that.

It's too bad, because other than the cross-zone SEEN-BY stripping and these issues with forwarding .PKTs, the software is virtually bullet-proof.

It sure is. But knowing these two issues, it still can be used.

'Tommi

--- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.
* Origin: - nntp://rbb.fidonet.fi - Lake Ylo - Finland - (2:221/360)

On 2019 Jul 07 20:18:16, you wrote to Tommi Koivula:

There is also a minor issue with .PKT endings, as the forwarded .PKTs
end up with an extra 2 NUL bytes tacked onto the end.

that shouldn't be any real problem... it isn't that different than transferring
with xmodem or a variant which tacks on padding CTRL-Z characters... some software is, however, overly sensitive ;)

It's too bad, because other than the cross-zone SEEN-BY stripping and these issues with forwarding .PKTs, the software is virtually bullet-proof.

yup!

)\/(ark

And to this end they built themselves a stupendous super-computer which was
so amazingly intelligent that even before its data banks had been connected
up it had started from "I think therefore I am" and got as far as deducing
the existence of rice pudding and income tax before anyone managed to turn
it off.
... I enjoy every step of food prep, particularly as my wife does it.
---
* Origin: (1:3634/12.73)