Maurice Kinal wrote to Maurice Kinal <=-

What exactly is the job of the FTSC?

From http://ftsc.org/docs/fta-1000.002:

===
The Fidonet Technical Standards Committee (FTSC) is responsible for
providing a thorough technical definition of FidoNet and its
protocols sufficient to maintain it as a compatible electronic mail
system, specifically by:

1. Documenting current practice in technical standards.
2. Encouraging new technologies in Fidonet software development.
3. Reassessing and revising FTS documents regularly.
4. Being publicly accessible to Fidonet sysops.
5. Distributing Technical Standards and Proposals.
6. Providing FTS document interpretations on software compatibility.

The FTSC shall maintain a publication which documents only the
minimum acceptable protocol for a Fidonet node to receive mail as
referred to in the current FidoNet Policy Document (Policy 4.07 at
this writing) The FTSC shall not take upon itself any right to
increase or decrease this requirement without express direction to
do so from the International Coordinator (IC).
===

TLDR: we document standards, we don't create them.

Hope this helps.

Later,
Sean




--- MultiMail/Win
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hey Sean!

we document standards, we don't create them.

Where can the flaw be reported?

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

we document standards, we don't create them.

Where can the flaw be reported?

This is probably a good place to report issues that you see in general.

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

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

On 2019 Jun 25 21:01:26, you wrote to Maurice Kinal:

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)...


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 do
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...

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...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I need accurate, brief, and non-redundant information.
---
* Origin: (1:3634/12.73)

Good ${greeting_time}, mark!

26 Jun 2019 05:43:00, you wrote to Alan Ianson:

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)...

The phrase "%s must be ignored" in technical documentation could mean only "despite of all possible special meanings, any special processing of %s is prohibited".

Examples:
1. The $shell_variable_name enclosed in 'single quotes' must be ignored.
2. The /* comments in a C/C++code */ must be ignored by compiler.
etc.

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 do 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...

"You should also on occasion send a message to every node in your network to ensure that they are operational. If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist."

That means two weeks with "Hold" status, two weeks with "Down" status and, finally, kicking such system from the nodelist. Oh yes, there also should be some reasonable time to wait for an answer before "Hold" - a week or so.

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...

Exactly same thing for now. Even if some node may explicitly put connection parameters into the mailer configuration file, all these parameters must be obtained only from 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...

Banning people with incompatible software from echoareas works just fine.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

On 2019 Jun 26 14:44:44, you wrote to me:

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)...

The phrase "%s must be ignored" in technical documentation could mean only "despite of all possible special meanings, any special processing of %s is prohibited".

agreed... "special processing" being the keywords... "normal processing" should
still take place which, in this case, would leave the characters in question alone so they remain in the data stream... in the case of UTF-8 characters, the
8bit character in question will still remain and the multibyte UTF-8 characters
will be valid instead of invalid as they are when the 8bit character in question is stripped due to "special processing"...

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 do 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...

"You should also on occasion send a message to every node in your network to ensure that they are operational. If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist."

That means two weeks with "Hold" status, two weeks with "Down" status and, finally, kicking such system from the nodelist. Oh yes, there also should be some reasonable time to wait for an answer before "Hold" - a week or

so.

we're not talking about that... this point is about *Cs enforcing the disallowance of broken software in the network once the FTSC has determined that it is broken and detrimental to the smooth operation of the network... the
FTSC cannot do the enforcing... only the *Cs and they do that by removing the node numbers in cases where the operators of the broken software are not responding to hails about the problem...

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...

Exactly same thing for now. Even if some node may explicitly put

connection

parameters into the mailer configuration file, all these parameters must

be

obtained only from nodelist.

true but the problem is that once they are put into a system's configuration, the node may be removed from the nodelist and still remain in the operator's configs... they'll still be operational, pulling echomail, and participating in
whatever echos all the while completely oblivious to the situation and lack of nodelist entry... all because the software has FTN bolted on and nodelist compliance is not mandatory or builtin...

at one time, you had to get a nodelist and add yourself to it with a "/999" (or
"/9999") node entry so your mailer would work and you could send in your application for a node number... most software used in fidonet today doesn't even require a nodelist to work properly... not even the most widely used mailer software :/

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...

Banning people with incompatible software from echoareas works just fine.

we're not talking about banning them from the echos... that's a moderator's job
(which they can't even do any more because of the multi-link methodology being used today)... what we're talking about above is banning the non-compliant software from the network... that includes temp banning nodes, if need be, until they have compliant software installed and in operation... i remember times when binkleyterm and frontdoor were banned due to problems and interoperability failures... everyone running them had to drop back a version until a fix was released... some nodes were temp removed from the nodelist to prevent their operation due to lack of entry in the nodelist but they were restored as soon as they had the fix installed... they were removed because the
operator was asleep at the wheel or busy elsewhere in real life... either way, the problem was stopped...

[rant]
obviously you've not tried to get the attention of some Mystic BBS operators who are running with a default binkp server setting requiring secure mailer sessions... that setting disallows random systems from delivering direct/crash netmail to the Mystic BBS system... when this problem was discovered it was pointed out the the maintainer and the default was changed... unfortunately that didn't change the setting in systems already installed and newer updates to the software don't change existing settings either...

i've run into this in my own nets and region... some operators have responded to echomail postings about their setup... in others cases i had to actually log
into their boards and write a message to the operator... some responded to that
and others not... at least one individual knows about the situation because they responded to the echomail message addressed to them about the problem, they described the setting in question and then disappeared and have not responded any more...

i have no information on how to contact them outside of fidonet and i'm loath to have to dial into any BBS to yank their chains and get them to wake up about
the problem... policy doesn't cover that and i've already gone beyond what policy says i need to do... so i'm gonna start yanking node numbers and see who
wakes up and contacts me... i don't hold a lot of trust in that working, though, because of the various software packages not requiring the node be defined in the nodelist and complaining when the node definition is missing from the nodelist...

experiance says they likely won't even notice and it'll be some 3rd party trying to write them a netmail that'll notice they're not in the nodelist when they do a lookup on the name or address... and that's if nodes are actually updating to the most recent nodelists anyway... if they are using an old one, they won't even notice their friend's or their own entry is missing...
[/rant]

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I'm immortal... so far.
---
* Origin: (1:3634/12.73)

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)