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