TIP: Click on subject to list as thread! ANSI
echo: ftsc_public
to: mark lewis
from: Alan Ianson
date: 2019-06-26 15:56:22
subject: FTSC`s `job`

>> 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)
SEEN-BY: 57/0 103/705 153/250 154/10 203/0 220/70 221/0 1 6 360 229/426
SEEN-BY: 240/5832 267/800 280/464 5003 5006 5555 292/854 310/31 320/219 393/68
SEEN-BY: 396/45 423/120 633/0 267 280 281 412 509 640/1321 1384 712/848 770/0
SEEN-BY: 770/1 10 100 330 340 772/0 1 210 500 2452/250 5020/545
@PATH: 153/757 250 770/1 280/464 221/1 640/1384 633/280 267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.