Subj : FTSC's "job"
To   : mark lewis
From : Alan Ianson
Date : Wed Jun 26 2019 03:56 pm

>> It would be best to report issues direcly with the author of the software
>> causing issues (if known) or the project when possible.

> it isn't software that is causing the main issue reported (characters being
> stripped from message bodies)... it is the specifications in use, how the
> wording they use is understood, and how multiple specifications interact with
> other specifications due to the way they are worded...

>eg: does "blah is to be ignored" mean that blah is dropped from the processing
> stream (one form of ignored) or does it mean that blah is to not be acted on
> but must remain in the processing stream and passed on to other systems
> (another form of ignored)...

I've seen that happen. What is obvious to those in sector 1 is not so obvious
to those in sector 2 and needs to be discussed for clarity and a good outcome.
It's not an issue to those in sector 3, yet.. :)

> the secondary issue of software messing with the message bodies of in-transit
> mail on intermediate systems in the path is well known... the problem is 1)
>getting that software up/downgraded until a fix is released and 2) getting the
>maintainer's attention so it can be fixed... both are neigh on impossible to d
> these days when you have operators that simply do not respond to echomail or
> netmail and may take weeks to respond to messages written on their own boards
> which requires that someone go set up an account there and write said
> message...

This issue is a bad one that negatively affects the network.

> it was easier back in the day when the nodelist was required for a FTN system
> to operate properly... *Cs could get an operators attention by putting a node
> on HOLD status or even removing said node from the nodelist... removal
> generally garnering the best response since the node wouldn't run properly if
> its number didn't appear in the nodelist... it was at that time the problem
> could be explained and the operator could downgrade to an approved version of
> their software or upgrade to a fixed version if one was available...

Good or bad I think those days are over now.

--- BBBS/Li6 v4.10 Toy-4
 * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

.