| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.