Text 11204, 139 rader
Skriven 2019-06-26 13:40:14 av mark lewis (1:3634/12.73)
  Kommentar till text 11203 av Alexey Vissarionov (2:5020/545)
Ärende: FTSC's "job"
====================
 On 2019 Jun 26 14:44:44, you wrote to me:

 ml>> it isn't software that is causing the main issue reported (characters
 ml>> being stripped from message bodies)... it is the specifications in
 ml>> use, how the wording they use is understood, and how multiple
 ml>> specifications interact with other specifications due to the way they
 ml>> are worded... eg: does "blah is to be ignored" mean that blah is
 ml>> dropped from the processing stream (one form of ignored) or does it
 ml>> mean that blah is to not be acted on but must remain in the
 ml>> processing stream and passed on to other systems (another form of
 ml>> ignored)...

 AV> The phrase "%s must be ignored" in technical documentation could mean only
 AV> "despite of all possible special meanings, any special processing of %s is
 AV> 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"...




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

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

 AV> That means two weeks with "Hold" status, two weeks with "Down" status and,
 AV> finally, kicking such system from the nodelist. Oh yes, there also should
 AV> 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...

 ml>> it was easier back in the day when the nodelist was required for a
 ml>> FTN system to operate properly... *Cs could get an operators
 ml>> attention by putting a node on HOLD status or even removing said node
 ml>> from the nodelist... removal generally garnering the best response
 ml>> since the node wouldn't run properly if its number didn't appear in
 ml>> the nodelist...

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

 ml>> it was at that time the problem could be explained and the operator
 ml>> could downgrade to an approved version of their software or upgrade
 ml>> to a fixed version if one was available...

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