= Сообщение: 4768 из 7124 ====================================== FTSC_PUBLIC = От : mark lewis 1:3634/12.73 26 Jun 19 13:40:14 Кому : Alexey Vissarionov 26 Jun 19 13:40:14 Тема : FTSC's "job" FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.73+5d13b8db На : area://FTSC_PUBLIC?msgid=2:5020/545+5d1369ee = Кодировка сообщения определена как: CP437 ================================== ==============================================================================
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)
