F I D O N E W S -- Volume 14, Number 27 7 July 1997 +----------------------------+-----------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-904-409-7040 [1:1/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Christopher Baker 1:18/14 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: FidoNews Editor 1:1/23 | +----------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> cbaker84@digital.net | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +----------------------------------------------------------------------+ ONE YEAR AGO THIS ISSUE! AND DRIVING ON MARS! Table of Contents 1. EDITORIAL ................................................ 1 One Year Ago, this Issue! ................................ 1 2. GUEST EDITORIAL .......................................... 2 Gulp? .................................................... 2 3. LETTERS TO THE EDITOR .................................... 3 FTSC Chairman retires in office? ......................... 3 How Do I get a Node number in Hong Kong? ................. 3 A remark concerning FSC-0093 ............................. 4 Found it! ................................................ 5 FTPoint in Zone 1 Wanted ................................. 6 Where does FidoNews go in Zone 3? ........................ 7 4. ARTICLES ................................................. 9 FidoSpine Distribution System Pledge ..................... 9 Observational Titbits .................................... 10 5. TRUE STORIES OF FIDONET .................................. 11 A True Story of FidoNet .................................. 11 6. FIDONET HISTORY .......................................... 14 History of Echomail - Part 1 ............................. 14 7. GETTING TECHNICAL ........................................ 27 No more "Getting technical" ? ............................ 27 8. COORDINATORS CORNER ...................................... 35 Nodelist-statistics as seen from Zone-2 for day 185 ...... 35 9. ECHOING .................................................. 36 ELIST Suspended for July ................................. 36 And more! FIDONEWS 14-27 Page 1 7 Jul 1997 ================================================================= EDITORIAL ================================================================= This is the Issue number where I took over the Editorial operation of FidoNews last year. It's STILL fun. [grin] This is quite a full Issue with lots of Echomail-related stuff and some odds and ends that came in at the last minute. One of the items is a note about the resignation of the FTSC Chairman, David Nugent [who is also ZC3]. This was first reported in several Sysop Echos and is confirmed here. Nugent is indeed resigning and is also leaving FidoNet. Along these lines, I sent direct Netmail to each Zone Coordinator asking for information, comment, and publication permission for any replies. They will appear here or in subsequent Issues as they arrive and are released for publication. Nugent advises that he has a few unpublished Proposals to get out and list updates to make before his successor takes over the Chairmanship and that will be done in the next weeks. Another is a plea for assistance from a fellow in Hong Kong who can't seem to get a Node number over there. Somebody help him, please. Speaking of the Comix section, if any .CMX come in that are political in nature, they will be reassigned to the Guest Editorial [.GUE] section so as not to confuse anyone. It also puts them up front. I forgot to add the two new sections mentioned in 1424 to the ARTSPEC doc. That omission has been corrected and the updated ARTSPEC.DOC has been hatched into the pipeline for the FIDONEWS file echo and ARTSPEC.ZIP into the SDS area SOFTDIST for further distribution. The entire ARTSPEC.DOC will be reprinted next week [due to space constraints this week] for information. Look for it once a year or whenever updated. The two, new sections are the .TRU and .FIC sections for FidoNet-related true stories or fiction. Both ARTSPEC.DOC and ARTSPEC.ZIP can be file-requested from this system or found on the FidoNews webpage and many other FidoNet file sources. And now that we've successfully put a robot rover on the surface of the planet Mars, maybe someone can tell me why FidoNet still doesn't have an International Coordinator? [How about that MARS MISSION?!!] C.B. ----------------------------------------------------------------- FIDONEWS 14-27 Page 2 7 Jul 1997 ================================================================= GUEST EDITORIAL ================================================================= --------------------------------------------------------------------- /`. o .^\ \ \, o o { \ / `~~~--__ { \___----~~' `~~-_ ______ _____ \ FidoSpine / a '~._(_||___)________/___ / /~~~~-, ,__. , /// __,,,,) Zone 1 Backbone__/\ \/ \/ `~~~; ,---~~-_`~= \ \------o-' \ / / / / '._.' _/_/ ';|\ (Art stolen from Jack Sargeant) ----------------------------------------------------------------- FIDONEWS 14-27 Page 3 7 Jul 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= --- Following message extracted from NET_DEV @ 1:18/14 --- By Christopher Baker on Fri Jul 04 19:54:57 1997 From: Lisa Gronke To: Frank Ellermann Date: 02 Jul 97 14:18:32 Subj: Where O Where is the FTSC_Chair? 27-Jun-97, Frank Ellermann <2:240/5815.1> muttered to Christopher Baker in the NET_DEV echo: > BTW, you probably noticed it, 3:3/20 is not more listed, what > is the true FTSC now planning, elect another chair man ? Just > curious as always... greets, Frank Where O Where is the FTSC_Chair? I sent Internet email to David Nugent, davidn@csource.oz.au, and asked him. He said that he resigned as FTSC chair since he is leaving FidoNet at the end of July. His BBS is already offline due to lack of callers. He said he informed the other FTSC members of this fact about 3 weeks ago via the ftsc mailing list, but has gotten no response at all. He also says the ftsc web page will be disappearing at the end of July unless he finds a current member of the FTSC who is willing to maintain it. Origin: EastSide Data Services (1:105/61) -30- ----------------------------------------------------------------- Received: by yonet.org.hk (0.99.970109) From: any@yonet.org.hk (Chris Tang) Date: 06 Jul 97 12:10:17 +0800 Subject: fidonet Organization: YO!Net To: cbaker84@digital.net .o[-MAiL-FRoM-AnY-BoX-Of-Chris Tang-tO-cbaker84-]o. cd> yes. that is what the above means. send me your story and contact cd> info in an email msg and i will publish it in FidoNews tomorrow. ok..below are the details. (my English is not good actually :> ) btw, i hope u can give me a copy of fidonews which published FIDONEWS 14-27 Page 4 7 Jul 1997 this event via any@writeme.com, thanx.. --- Hi, i'm a sysop in Hong Kong, I met a problem of applying a fidonet node in Zone6 Host700. A few month before, I have tried to contact 6:700/0 via netmail, however, his system doesn't receive any netmail at all, I assumed that his mailer couldn't work properly. Later, luckily, i found his E-Mail address from fidonet nodelist and i sent him a E-Mail about apply a fidonet node in Z6H700 with my system information, he then replied within a day and told me that he would help me to do so. However, a few weeks later, i didn't get any reply from him any more. i then got a fidonet nodelist to see if my node had already inside or not, but it had no change at all in Z6H700 part of fidonet nodelist. So I tried to send him the second E-Mail to him about the applying of fidonet node, he has replied that he would do so. Again, no more reply was received from him. Luckily, i read Fidonews and find out some fidonet sysop contact methods from it for help. I wanna have a fidonet node because of the international purpose and the fidonet node is always required if being a bbs product oversea distro sites in order to prove that my system works properly. this is why i wanna join fidonet family. :) Now, i hope i can apply a fidonet node directly from ZC of Zone6 but i can't find his e-mail address (E-Mail is the unique contact method for me for contacting oversea). Anyone can help me about this? below are my contact methods. Name : Chris Tang E-Mail: any@who.net (text email only) any@writeme.com (file attach support) ICQ : 1251490 BBS : AnyWhere Board +852-2672-5505 [Hong Kong] -- Greetz, Chris Tang, any@who.net -= AnyW =- -30- ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Wed Jul 02 22:59:44 1997 From: Frank Ellermann @ 2:240/5815 FIDONEWS 14-27 Page 5 7 Jul 1997 To: Editor @ 1:1/23 Date: 03 Jul 97 04:18:00 Subj: fsc-0093.let A remark concerning FSC-0093 by Frank Ellermann, 2:240/5815.1@fidonet.org Hello Chris... I don't know how this *.LET submission type is meant to work, but at least I try to stay within the 70 columns limit. First an idea, how you could get more replies like this into FidoNews. Just replace the useless (?) publishing of pages in NEWSCHAT by posting of the complete articles there. Then whoever wants to answer can simply use the quote function of his news reader... et voila, a new article !? Two additions to your publishing of FSC-0093. Reduced seen-by lines are implemented in IMAIL version 1.85. If some users of this fine product weren't aware of it until today: Reduced seen-by lines are by far safer than tiny seen-by lines, because the vital informations to detect dup-rings automatically are preserved by reduced seen-by lines. So if you still use tiny seen-by lines today (and you're not by accident a zonegate :-), then please try reduced seen-by lines. Second point, it would be quite simple to extend FSC-0093 in a way that allows interzonal dup-ring detection. Still fully compatible with FSC-0074 (i.e. FTS-0004) of course, and mostly of interest for zonegates. Today it's almost impossible to detect multi-zone rings automatically, but based on the old SPTH-proposal it's possible to extend FSC-0093 in this direction... However, before I try it, there should be at least one zonegate (all those internet tunneling nodes, hi, that's you :-) really interested in using this method, if it's implemented in e.g. IMAIL or FASTECHO. "QOFM" to Chris, you probably know, that in practice FidoNews is the last working "official" glue keeping FidoNet together, don't you ? Tnx and bye, Frank -30- ----------------------------------------------------------------- Got my CRC problems solved... Anybody with a nodelist later than day 150 punch up Susana Baratta 4:851/7 The entry for this node contains high ascii characters at the end, some utils probably do not allow for this, so the CRC comes out incorrect! The bad file was NODEDIFF.157 which has a grunged entry. The CRC calculates correctly if the data type is changed from signed 8-bit FIDONEWS 14-27 Page 6 7 Jul 1997 (char) to unsigned char for the calculation... Therefore the CRC error message was correct because there was a problem, but incorrect because the checksum on the top line is accurate if you allow for the high-ASCII characters. I've really enjoyed figuring this out for myself. I've spent a lot of time testing my routines for CRC calculation, and come to the conclusion that any nodelist utility really should check a byte at a time for illegal characters. It may really slow things down, but it's probably for the best. L8r, Brainwave ... Yes, Socrates himself is particularly missed. -- |Fidonet: Brian Wood 1:362/903@fidonet.org |Internet: 903!Brian.Wood@river.chattanooga.net | | Standard disclaimer: The views of this user are strictly his own. | River Canyon Rd. BBS <=> Chattanooga OnLine! Gateway to the World. -30- ----------------------------------------------------------------- From: "Mikhail Ramendik" To: "cbaker84@digital.net" Date: Mon, 30 Jun 97 21:28:35 -0300 Reply-To: "Mikhail Ramendik" Subject: For FidoNews: FTPoint in z1 wanted This is for Fidonews. Please put it into the appropriate section. I am Mikhail Ramendik of Moscow, Russia, 2:5020/768.45, mikhram@dataforce.net I have a good command of English and want to receive some echos from the z1 backbone. Notably HOLY_BIBLE and company, HISTORY and MILHISTORY . Even though some of them do get to z2, they're SLOW!!! And HOLY_BIBLE is NOT here AFAIK... What I am searching for is a Point in Zone 1 with Mail transfer via FTP (or if impossible - via VMODEM). I am a Point since 1993, have software tuned OK, will never generate dupes and annoy the bossnode. (Yes I have seen the commercial hub list. I wish I could use such a hub, but transferring the bucks from Russia is impossible) If anyone can help me join Z1 please email! Thanks in advance! ---------------- Mikhail Ramendik -mikhram@dataforce.net FIDONEWS 14-27 Page 7 7 Jul 1997 FidoNet: 2:5020/768.45 Praise be to the Father, the Son and the Holy Spirit -30- ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Fri Jul 04 19:03:38 1997 From: John Gardeniers @ 3:632/360 To: Editor @ 1:18/14 Date: 28 Jun 97 20:56:50 Subj: Fidowhere.art Hi Editor, As I figure it's better in this format than none at all, and I do find artspec a little off-putting, I've decided to post this to you as a message. Do with it what you will. :-) regards, John ------------------------------------------------------------------ Fidowhere (Where can I get Fidonews?) by John "Fuse" Gardeniers (3:632/360.70) In FIDO1425 there was yet another comment about the unavailability of Fidonews, so I thought I'd share my own experiences in that regard. When I became a Fido point last late last year one of the things I looked forward to was getting a regular copy of Fidonews. This had always been intermittent, to say the least, on various local BBSes. Indeed, many BBSs around here don't even carry a single issue. :-( Having obtained lists of the available message and file areas I immediately proceeded to link to the Nodelist and Fidonews areas. "Great" I thought, I'll most likely get the first one within a few days. It was not to be. :-( After a couple of weeks I contacted my boss to try to find out why the news wasn't arriving. Not being a reader of it herself, my boss was a little surprised that Fidonews wasn't arriving at her system either. The system in question is a major mail hub, not just an end leaf. A few messages here an there soon revealed that Fidonews wasn't available locally, at least not via Fidonet. We did learn that it was readily available via Internet! The idea of having to use the Internet to obtain Fidonet's newsletter struck me as just a little absurd. Due to some persistence on the part of my boss we finally had Fidonews being delivered to these parts via Fidonet itself, as it always should have been. Am I the only one who finds at strange that so many sysops FIDONEWS 14-27 Page 8 7 Jul 1997 didn't bother chasing it up? We are in the largest network in the state, so many systems must have been affected by the unavailability of the newsletter. I wonder how many sysops currently believe that Fidonews has ceased to exist. On a slightly more critical note, the fact that so little effort appears to be put in by so many people to get a copy at all says quite a lot about it's value. :-/ -30- ----------------------------------------------------------------- FIDONEWS 14-27 Page 9 7 Jul 1997 ================================================================= ARTICLES ================================================================= FidoSpine Distribution System Pledge 1. The FidoSpine Distribution System recognizes all echoes as listed in the Echolist for June 1, 1997 (ELIST706.*) along with their first-listed moderator as the Moderator-of-Record. 2. The FidoSpine Distribution System will initially carry all Fidonet Zone one echoes that appear in the June 1997 echo listing, plus some that are not. The FidoSpine Distribution System will use it's own echo distribution list, FIDONET.NOW. The FidoSpine Distribution System does not require echo listing renewals or minimum traffic levels for any echo(s). 3. The FidoSpine Distribution System recognizes the Moderator-of- Record as the "owner" of their echo. As such all moderator requests for feed cuts are honored, provided that the moderator follows the path from the 'problem' system and works backwards. Any FidoSpine Distribution System hub retains the right to not distribute any echo who's moderator's actions causes too much of a burden on their system or well being. 4. The FidoSpine Distribution System recognizes the validity of Fidonet Policy 4.07 in determining the legality and appropriateness of messages carried in echomail. Since the Moderator-of-Record is the "owner" of the echo, The FidoSpine Distribution System recognizes the moderator's responsibility in maintaining the legality and appropriateness of message traffic in their echo(es). The FidoSpine Distribution System is not responsible for the content of echomail traffic. 5. The FidoSpine Distribution System will work toward establishing SuperHubs in each zone and region. The FidoSpine Distribution System does not mandate any specific routing scheme, and allows each zone, region, and net to adopt and use their own methods. The FidoSpine Distribution System, where netmail and other traffic is concerned, will use routing charts provided by recognized Fidonet Coordinators (as indicated in the Fidonet Nodelist). 6. The FidoSpine Distribution System distribution system will not interfere with any traffic in any echo, aside from eliminating duplicate messages ("dupes") and adding necessary routing information in accord with Fidonet Technical Standards. 7. The FidoSpine Distribution System will accept input from any moderator as to a request to carry his/her echo. We will NOT require multiple requests from various NEC's and REC's to 'authorize' distribution of any echo. All that is required is that the moderator have properly established an entry in the current Echolist, and make a request of the FidoSpine Distribution System to distribute his/her echo. 8. The FidoSpine Distribution System may, from time to time, FIDONEWS 14-27 Page 10 7 Jul 1997 establish, and distribute, technical criteria that messages must meet in order to be carried on FidoSpine. Such criteria may include, but not be limited to, definitions of character set, Origin Line length, age of messages, technical specifications of the SEEN-BY's, the PATH, the tearlines, and assorted control lines. Bob Seaborn, 1:140/1 Ed Georgen, 1:2222/258 Jerry Gause, 1:3651/9 Jim Balcom, 1:13/25 Peter Rocca, 1:2401/0 ----------------------------------------------------------------- Observational Titbits by Lee Kindness, 2:259/7 Well, just a couple of observations... 3:3/20, the FTSC Chair alias address is no-longer in the nodelist, what gives? A number of people have been trying to form a new FTSC (without an IC) but these guys should perhaps show a bit more common- sense (use NET_DEV rather than FTSC_PUBLIC due to NET_DEV having better distribution) and a bit more 'get-up-and-go' (like contact me about all those FTSC additions/revisions I published in Fidonews a couple of weeks back). I wonder if we'll ever see an FTSC entry in the nodelist ever again... Hell, a united world-wide Fidonet is looking very shakey... ftp.fidonet.org is now an alias for ftp.paonline.com rather than the IEEE server it used to be on. Interesting to note that only FSC documents up to fsc-0090 are on the site (up to fsc-0093 exist on ftp.blaze.net.au - the 'former' FTSC internet site) while the two 'fta' documents by the would be new FTSC are present... >From 2:259/7, In dis-united Scotland... -- Lee Kindness shazze@on.bright.yelly.bowls.com Fidonet 2:259/7 wangi@earthling.net hufunglun http://www.scms.rgu.ac.uk/students/cs_yr94/lk ----------------------------------------------------------------- FIDONEWS 14-27 Page 11 7 Jul 1997 ================================================================= TRUE STORIES OF FIDONET ================================================================= [This is the inaugural True Story of FidoNet. It's old but it's true. Send yours today!] Ed. [In 1989 I was injured on-the-job and had little and then no access to my FidoNet computer which was at work. The members of my Net at the time, built me a computer to use at home to operate the one at work remotely.] --Original post: This file is my way of expressing my gratitude to the members of my Net (FidoNet Net 1:135, SFLorida NET, Miami_FL_USA) for a holiday gift they presented me in mid-December. Composed on 5 Jan 89. A Holiday Ode to Net 135 by Christopher Baker RC 18 / NC 135 Twas two weeks before Christmas and all thru my house, my body was aching, I started to grouse. "If I don't dump this backache and get back to work my Users and Sysops will think I'm a jerk." I'd been laid up at home for many a week and I had no computer through which I could speak. It's tough to do business without a remote and I'm sure many NCs thought things I can't quote. All the while in the background quite unknown to me, the folks of my own Net were planning a spree. They talked and they chatted and gathered up parts to build me a system for home, bless their hearts. They Netmailed and Echoed and telephoned, too, deciding just which part was what and from who. They assembled a system that was based on a Tandy; with modem and hard drive, I mean, it's a dandy! I was tired and cranky the night it was due and had NO idea this dream would come true. I had pains in my back and a pain in my head but my wife kept insisting I not go to bed. It didn't seem normal the way she cajoled. It wasn't till later she said, "I was told." So unknown to me I was being prepared for a real demonstration of how my Net cared. It was close to eleven P.M. when I said, FIDONEWS 14-27 Page 12 7 Jul 1997 "I can't stay up longer. I'm going to bed." Then suddenly and very much to my shock came a tap on the door and then a loud knock. "Ho, Ho, Ho!", said a voice not too clear through the door. "Open up! I have presents for you by the score!" The door was thrown wide to allow the sprite in but he wasn't in red; not a hair on his chin. He was thin as a rail and no Santa was he. I recognized Peter; our own NEC. "What the heck's going on?" I exclaimed to the air. He said, "Just a token to show that we care." He said nothing else but went straight to his work and set up the system then he turned with a smirk. "No more excuses!", he said, "Now, get cracking!" "Your traffic's piled up and the stuff keeps on stacking!" I stood there dumbfounded, amazed and confused. My mind boggled speechless and he seemed amused. "What? How? Who and why?", I managed to say. "It's nothing", said he, "now, get back in the fray!" It wouldn't sink in that such things still take place that confirm all your faith in the rest of the race. The best I could do was to stammer my thanks and then write this poem to honor our ranks. I still can't believe it and simply must say, "All the folks in my Net, you made my whole day!" "I never can thank you enough for this gift." "Your generous act brings a permanent lift!" So, all of the rest out in FidoNet land, keep your faith that our concept continues to stand. The FidoNet concept of help and of sharing is here. Look around and you'll see people caring. It's never too late to put egos aside. Let go some bygones and take them in stride. This Network is people and people are kind. When your urge is to flame them, please keep that in mind. To all of my Net, I say "Thank you, nth times!" To the rest of the world who are sick of my rhymes I say "I hope the New Year will bring you much joy!" Now, I think I'll stop here and go play with my toy! [grin] The End Happy Holidays and Happy New Year to the wacky world of FidoNet! Christopher Baker MetroFire, 1:135/14(0), 305-596-8611 FIDONEWS 14-27 Page 13 7 Jul 1997 Miami_FL_USA SFLorida Net 135, Miami_FL_USA Roster of Net 135 Santas: 1 RAM-SOFT_Archive_Library, Miami_FL, David_Gilbert & James Gilbert 2 Eclectic_BBS, South_Miami_FL, Tark_Henderson 3 Medical_Software_Exchange, Miami_FL, Richard_Kaplan 4 The_Kendall_BBS, Miami_FL, Mike_Janke 5 CAP-BBS, Miami_FL, Duane_Ellis 6 Dungeons_of_Darkness_OPUS, Miami_FL, Mike_Jones 7 Miami's_First_Fido, Miami_FL, Al_DelaTorre 8 Coral_Gables_Medterm_BBS, Coral_Gables_FL, Mario_Diaz 9 EPICS_Opus, Hialeah_FL, Sandy_Schurtz 10 AMS_Support-Net_135_NEC, Miami_FL, Peter_Adenauer 11 Power_Station, North_Miami_FL, Mike_Lombana 12 Off-Duty_Inc._BBS, Miami_FL, Kathryn_Fanning 20 FrontDoor_Headquarters, Miami_FL, Joaquim_Homrighausen 24 TURBO-Soft, Homestead_FL, David_Kerley 27 Bitsy's_Place, Miami_Beach_FL, Henry_VanLeer 30 SMURFIT_Latin_America_Opus, North_Miami_Beach_FL, Jeff_Wolach 33 Byte_Size_Bits, Homestead_FL, Jean_Prophet & Buddy Prophet 34 The_Jailhouse, North_Miami_FL, Kenny_Star 35 The_Sober_Way_Out, Miami_FL, Robert_Egan 36 Town_Crier_Opus, Miami_Shores_FL, Orville_Bullitt 38 C-Board, Miami_FL, Jack_Bowman 39 The Expressions_BBS, Miami_Springs_FL, Daniel_Johnston 40 The_Cable_Connection, Miami_FL, Jerry_Iovine 41 BBS1-PC!, Miami_FL, John_Theed 43 Key's_Paradise, Key_West_FL, Steve_Froeschke 46 Bullitt_-_80_Opus, North_Miami_FL, Guy_Bullitt 47 MOBS_Opus_Humor_South, North_Miami_FL, Andrew_Adler 48 The_Road_Runner, Hialeah_FL, Luis_Hernandez 88 Chatterbox_BBS, Miami_FL, Marc_Moyantcheff 204 BerkShire_Board, Miami_FL, Bill_Kraski 901 Miami's_Personal_Consultant, Miami_FL, Dave_Steinman 942 wHy_bE_NoRmaL?, Miami_Fl, Tim_LaVan, 990 Friends_of_Dorothy, Miami_FL, Scott_Samet Thank you all for the fabulous Tandy T1000 w/20 meg hard drive, 1200 bps modem, 384K RAM, floppy drive and completely configured with DOS and programs! It is a gift I will always cherish and never forget. You ARE an amazing and generous bunch of people and Sysops! TTFN. Chris -30- [That was a long time ago but I haven't forgotten that most of the folks in our net are not rotten.] [grin] Ed. ----------------------------------------------------------------- FIDONEWS 14-27 Page 14 7 Jul 1997 ================================================================= FIDONET HISTORY ================================================================= [This an abortive chapter of FidoNet History from 1989. This is the original EchoPol that was 'ratified' and then revoked by the IC of the period {David Dodell} as non-representative. With the recent REC Echomail effort, it might be well to reflect upon that which has not been enacted for going on ten years after Policy4. It has been reformatted to 70 columns for FidoNews and the spelling and punctuation corrected where necessary. The original is available at 1:18/14 for file-request as ECHOPOL.] Ed. GENERAL ECHOMAIL POLICY 1 April 22nd, 1989 PROLOGUE This document sets forth policy governing Echomail conferences and their distribution. If any item in this policy is in conflict with any existing or subsequent General FidoNet Policy, then General FidoNet Policy will be in effect. This Policy applies to Zone One Backbone Echomail conferences and to any other conferences for which the Moderator desires it to be applicable. Future changes to Echo Policy may be proposed by any FidoNet Sysop by submitting the proposal to their REC. The REC will then determine if the proposal should be brought before the rest of the RECs. If an REC decides not to bring a proposed change before the rest of the RECs, a message stating why must be sent. If 10% or more of the NCs and NECs in a region request that a proposal be brought before the RECs then that proposal must be brought before the RECs. A majority vote of the Regional Echomail Coordinators is required in order for a proposal to be formally voted on. If 10% or more of the NCs and NECs in the Zone request that a proposal be formally voted on, then that proposal must be formally voted on. Those eligible to vote on any proposals made by the REC structure will be the ZEC, RECs, NECs, NCs, RCs and ZC. Only one vote per person is allowed. Adoption of changes will require a simple majority of those voting to pass. In this document, "a simple majority" means more than 50 percent of those voting. A good faith attempt must be made to make all potential voters aware that a vote is occurring and make available all necessary information. I. HISTORY FIDONEWS 14-27 Page 15 7 Jul 1997 Echomail consists of the sharing of message bases or conferences between various independent network addresses. The Echomail concept started with a series of programs by Jeff Rush. Since the original implementation, many authors have written programs improving on the original idea. In spite of worries that the flow of Echomail would increase Netmail traffic to the point that the Network would collapse under its own weight, Echomail has been a success. To simplify the distribution of Echomail, a national Echomail Backbone formed whose primary purpose is the distribution of Echomail at a national level. Of recent introduction to the Backbone system has been the generous contribution of the Echomail Stars. As a result of the growth of Fidonet and the increase in the volume of Echomail, it has become necessary to set forth a formal policy governing Echomail. II. DEFINITIONS 1. ECHOMAIL: The process of sharing message bases between independent systems with unique net/node addresses. 2. ECHOMAIL CONFERENCES: An Echomail conference is a message base of forum design distributed under a specified conference name dealing with a defined area of interest. Notable examples include TECH, the National Technical Conference and COMM, the National Telecommunications Conference. 3. MODERATED CONFERENCE: A moderated conference is an Echomail conference for which a moderator has been appointed to supervise the flow and content of the conference. All conferences carried on the Backbone must be moderated. 4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in which the Moderator has decided that the conference will be made available only to Sysops and not to users. 5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted distribution conference is one which is restricted only to eligible recipients. Notable examples include REGCON, the Regional Coordinators Conference, COORD, the National Echomail Coordinators Conference, and MAGICK, a pre-register Echomail Conference. 6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is responsible for coordination of Echomail on a FidoNet Zone level. 7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is responsible for coordination of Echomail within his region. 8. NET ECHOMAIL COORDINATOR (NEC): This individual is responsible for coordination of Echomail at the Local Net level. 9. ECHOMAIL Backbone: The Echomail Backbone consists of FIDONEWS 14-27 Page 16 7 Jul 1997 voluntary members who provide services to enhance the national distribution of Echomail. The Backbone consists of nodes which handle a high volume of Echomail traffic and are responsible for distribution of Echomail down to the regional level. 10. NATIONAL ECHOMAIL LIST: The National Echomail List identifies the available national conferences, the conference moderator and requirements of the specified conference. The ZEC will appoint the keeper of the National Echomail List. 11. AUTOMATED CENSORSHIP: The term Automated Censorship refers to programs which cause messages to be removed from the intended conference or have their content altered. 12. FIDONET POLICY: The document which governs Fidonet as adopted by Fidonet. The document as of this writing is Policy3 and is subject to change. This policy is intended to become a part of general Fidonet policy. Until it is incorporated into General Fidonet policy, this document shall serve to define policy violations occurring in Echomail. 13. OPEN ACCESS CONFERENCE: This is a non-restricted conference open to all users who are willing to follow the posted conference rules. 14. TERMINAL NODE: A system which does not process echomail for pickup by another system. III. DUTIES OF ECHOMAIL COORDINATORS 1. GENERAL: It is the duty of the *ECs to make available to any Fidonet Sysop, any conference which the Sysop is not prohibited from receiving by not meeting requirements as mandated by the conference moderator. If for any reason the *EC does not have access via recognized distribution channels to a specific conference, they can not be expected to pass it on. If a *EC fails to make available any conference to qualified lower distribution levels, this shall be deemed to have violated the outlined duties of the position held. Such violation is cause for the removal as provided by this document. Nothing in this provision requires that a *EC must import any conference to the extent of adverse economic impact. It is recommended that cost sharing arrangements be employed. Where financially feasible for the supplier any conference on the Backbone must be made available (other than restricted conferences) when requested. An exception is when a *EC cuts a link to end unauthorized distribution of a conference. In this case, some otherwise authorized nodes may temporarily lose their link. FIDONEWS 14-27 Page 17 7 Jul 1997 A *EC shall do everything in their power to insure that: 1. All downstream links are educated as to this policy. 2. Downstream links know how to properly link into conferences. 3. Acceptable and unacceptable behavior in echomail conferences is explained. 4. Downstream links are not engaging in topologies that increase the risk of duplicate messages. 2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the ZEC to coordinate the connections between the Echomail Backbone on both an inter-Zone and intra-Zone level as well as coordination of inter-regional connections. The ZEC will coordinate transmission of Echomail and to provide for routing in a manner that will avoid the transmission of duplicate messages within the same conference. It is also the duty of the ZEC to monitor compliance with this policy on both a national and international basis. 3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of the REC to provide for regional Echomail distribution. In addition, the REC will coordinate any inter-regional cross- linking of conference feeds with the REC of the participating region with the direct knowledge of the ZEC. The REC will provide for transmission and routing of Echomail within his/her region in a manner to avoid creation of duplicate messages within the same conference. It is the duty of the REC to monitor compliance with this policy at a regional level. 4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the NEC to coordinate the intra-net Echomail and to cooperate with the REC and NECs of other nets to arrange for the inter-net transmittal of echomail. The REC may require the NEC to provide links for independent (regional) nodes. The NEC shall maintain a list of available Echomail Conferences within the net as well as the requirements of each Conference area as supplied by the conference moderator (Echolist). The NEC shall also monitor compliance with this policy at a net level. 5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the Echolist Coordinator to compile and make available a listing of national and international Echomail conferences and, optionally, conferences at various local levels. The content and format of the Echomail listing shall be at the sole discretion of the Echolist Coordinator, but shall include the conference name and moderator for each conference. The Echolist Coordinator shall also maintain a list of requirements applicable to each listed conference. 6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the duty of the Echomail Conference Moderator to make in good faith every reasonable effort to insure that the moderated FIDONEWS 14-27 Page 18 7 Jul 1997 conference does not distribute or promote illegal activities or information as defined below in Section V Paragraph 2. The Moderator shall be responsible for insuring that messages contained in the conference corresponds to the conference theme. The Moderator shall report any violations of this policy to the proper Echomail coordinators and lodge any appropriate policy complaints as provided for in policy documents adopted by Fidonet. The Moderator shall post the conference rules in the conference at least once a month. The Moderator is to authorize the disconnection of the conference feed. Any Sysop the moderator believes is violating policy shall be reported to the offending node's nearest local echomail coordinator (may be a NEC, REC or in extreme situations, a ZEC); and the moderator shall formally authorize the feed to the offending node to be severed. The conference moderator is the sole judge - subject to review only by the ZEC (or his delegates) if a complaint is filed by the banished party. The Moderator may request in direct written form (netmail) that the *ECs disconnect a node from the conference when that node refuses to follow the published conference rules after at least 3 warnings. Knowingly feeding a conference to a node that has been severed by the Moderator is considered a violation of this echomail policy and is subject to suspension. The length of this suspension will be determined by a joint decision of the conference moderator and the nearest local echo coordinator of the node illegally feeding the conference to the original offending node or point. Echo conference complaints from a Sysop should be filed at the net level (NEC) or if the complaining party is an independent node then with their REC. The NEC or REC receiving such a complaint must take action in accordance with the provisions of this echomail policy. For severe or chronic infractions, the NEC, REC, or ZEC may file a complaint under general Fidonet policy for excessively annoying behavior. IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND MODERATORS. 1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail Coordinators and Echomail Coordinators currently holding these positions as of the date of acceptance of this Echomail Policy shall continue to service in said capacity until resignation or replacement under this policy. 2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be elected as follows: a) upon resignation or replacement of the existing ZEC, the FidoNet Zone Coordinator (ZC) shall nominate at least five individuals to be voted upon. FIDONEWS 14-27 Page 19 7 Jul 1997 b) 10 days after the nominees are selected, an election shall be held. The ZEC will be elected by a simple majority of IC, ZC, RCs, NCs, RECs, and NECs in their Fidonet zone. An individual holding more than one position can only cast one vote. That is, if an individual is both a NC and a NEC, they may cast only one vote. 3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be elected as follows: a) upon resignation or replacement of an existing REC, the ZEC shall nominate at least 3 individuals for election. b) 10 days after the nominees are selected, an election shall be held. The REC will be elected by a simple majority of the RC, NCs, and NECs in their FidoNet Region. An individual holding more than one position may only cast one vote. 4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the FidoNet Net Coordinator (NC) or in such alternative manner as determined by the NC. If a NEC is not appointed within 30 days, the REC will appoint the NEC. 5. REMOVAL OF A *EC: A *EC may be removed from their position by a simple majority of those allowed to vote for their successor. For a NEC, the members of the Net may vote by simple majority to remove the NEC. The position directly above (in the *EC structure) will oversee the recall election in the same manner as prescribed for electing successors. A *EC may only be subject to recall for failure to properly carry out their duties described above, or if they are no longer a member of Fidonet. A promise of 'free' echomail delivery from another source is *not* considered an acceptable reason for recall. A *EC maybe removed by the level above for continued violations of policy or for gross misconduct. 6. RECOGNITION OF CONFERENCES: The *EC corresponding to the appropriate level recognizes a conference at his level. Examples: The NEC recognizes a conference as local. The REC recognizes a conference to be regional. A ZEC recognizes a conference to be zonal. 7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail Conference Moderator may be removed from their position by a three fourths (3/4) vote of the *EC structure voting. This vote must be carried out in a fair and decent manner while giving at least ten (10) days notice to the entire *EC structure of the upcoming vote. The ZEC shall notify the RECs who in turn shall notify the NECs in their region of FIDONEWS 14-27 Page 20 7 Jul 1997 any upcoming vote. Notice must be given via NetMail. Additional postings in such conferences as COORD and regional conferences are encouraged. An Echomail Conference Moderator may only be subject to recall for failure to properly carry out their duties described above or continued pre-meditated violation of this documents section V. Statement of Policies as seen below. Failing to perform the above duties of a conference moderator for a period of 3 or more months and/or failing to designate a proxy in his absence shall be in violation of this policy and be subject to recall. A vote may only be callable by the ZEC (or his delegate). This delegate should not be from the region or net of the affected conference moderator. Membership in Fidonet need not be a paramount issue, but is highly recommended. V. STATEMENT OF POLICIES 1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to promote communication in Echomail Conferences in a lawful, friendly manner consistent with the general principles of FidoNet. 2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly distributes or allows to be entered into echomail conferences any messages containing or promoting illegal activities or information shall be deemed to have violated general FidoNet policy as being excessively annoying. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which would result in criminal prosecution. 3. AUTOMATED CENSORSHIP: The use of Automated Censorship in the passing or distribution of echomail will be considered a violation of this policy and will not be tolerated. Disciplinary action will be as referred to in General Fidonet policy as being excessively annoying. An exception to this provision shall be the deletion and not censorship of messages by any Sysop which may lead to legal action against that Sysop. No echomail shall be modified in any manner which could potentially cause duplicates. 4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall conform to general Fidonet policy as well as the provisions of this policy document in addition to any foreign network's provisions. Conferences which originate outside of FidoNet must be designated as such in the list of conferences kept by the Echolist Coordinator. FIDONEWS 14-27 Page 21 7 Jul 1997 5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit from the distribution (passing from system to system) of echomail shall be deemed to be excessively annoying and in violation of Fidonet policy subject to enforcement under existing Fidonet policy. Profit as defined in this paragraph is the charging for echomail distribution that exceeds actual cost to obtain and distribute the Echomail over a sustained period. The cost of the equipment used to obtain and distribute echomail may only be recovered on a strictly voluntary basis. A Sysop that charges users for access to their BBS shall NOT be in violation of this paragraph. Implementation of cost recovery plans may vary greatly. In general cost recovery plans should not be overly restrictive. 6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes shall honor and support the restrictions placed upon restricted distribution conferences. Violation of this restriction by individual nodes and points shall be a violation of this echomail policy and result in suspension of the violated echo in accordance with the above paragraph in Section III Duties of the Echomail Conference Moderators. A SYSOP only conference shall be made available only to the Sysops or Co-Sysops of Fidonet or other nets with which inter-net conferences exist. A violation of the restrictions placed on a RESTRICTED DISTRIBUTION CONFERENCE will be a violation of this policy if and only if the moderator has posted and specified the restrictions governing the conference. 7. PATHLINE OPTION: The PATHline (as defined in FTS-0004), originally implemented by SEA in the MGM package, is recommended for all nodes. If your current Echomail scanner supports the pathline you should enable it. While the pathline does not eliminate duplicate messages, it can be a very useful tool in determining where a topology problem exists. Systems operating as Echomail Stars, Backbone nodes, or Echomail Hubs must implement the PATHline option (as defined in FTS-0004 within 30 days of adoption of this policy. Since these system are operating beyond the scope of the typical FidoNet system, they are required to implement features that are otherwise optional. 8. SEEN-BY LINE: Under the current technology and topology (the routing structure of echomail), SEEN-BY lines play an important part in reducing duplicate messages. Tiny SEEN- BYs will not be allowed until the respective ZECs feel topology will allow their use. Nor will the stripping of SEEN-BYs (except Zone-Gates and Inter-Network EchoGates) be allowed unless approved by the ZEC. FIDONEWS 14-27 Page 22 7 Jul 1997 Violation of the above shall be excessively annoying behavior enforceable under general Fidonet policy. Zone- Gates and Inter-Network EchoGates SHOULD strip the SEEN-BYs of the exporting Zone or Network to reduce addressing conflicts. 9. COUNTERFEIT MESSAGES: Entering or knowingly distributing counterfeit messages shall be considered excessively annoying and a violation of Fidonet policy enforceable under the terms of Fidonet policy. As used in this paragraph, a counterfeit message is defined as any message entered using another person's name, handle or node address with the intent of deceiving others about the true author of the message. No handles shall be used to enter messages to knowingly provoke, inflame, or upset participants in a conference with the purpose of deceiving others about the true identity of the author. 10. SYSOP'S RESPONSIBILITY: It is the responsibility of each Sysop to make every reasonable effort to assure that the users on his board conform to the provisions of this policy document. A Sysop may be held responsible for the acts of his users unless the Sysop can show that a reasonable attempt was made to conform to this policy document. 11. ECHOMAIL SOFTWARE: Echomail software which does not conform to the minimum acceptable standards as defined by the Fidonet Technical Standards Committee (FTSC) shall lead to disciplinary action as described previously in this document. 12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without the prior consent of both the Sending and Receiving Hosts shall lead to disciplinary action as described previously in this document. See Section III. 13. INTER-NETWORK CONFERENCES: It is the general policy of Fidonet to encourage the development of INTER-NETWORK CONFERENCES. It shall be the duty of those providing the INTER-NETWORK CONFERENCE links to remove foreign net distribution identifiers which will adversely effect the distribution of the Echomail Conference while in Fidonet. The INTER-NETWORK CONFERENCE links maintained in Fidonet shall be operated in a manner not to interfere with the foreign network's distribution of Echomail. INTER-NETWORK CONFERENCE links maintained in FidoNet must also conform to General FidoNet Policy. 14. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE other than in conferences dedicated to this purpose (i.e. FLAME) shall lead to disciplinary action as described previously in this document. See Section III. The posting of substantiated facts shall not be considered a violation under this section. 15. ADDING OR REMOVING CONFERENCES FROM THE Backbone: A FIDONEWS 14-27 Page 23 7 Jul 1997 conference may be added to the Backbone only at the request of the RECOGNIZED Conference Moderator. A conference must be registered with the Echolist Coordinator before it can be added to the Backbone. A conference may be removed from the Backbone by lack of traffic. A committee composed of the ZEC and 4 RECs shall review the status of backbone echos every 3 months. At which time those echos which have not maintained a minimum 10 messages a week over the preceding 3 months will be noted and their Conference moderators will be contacted. These conferences will be given 1 months to improve their traffic or be withdrawn from Fidonet backbone distribution. The recognized conference moderator may request removal of their conference from the Fidonet backbone distribution at their discretion. 16. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links should be avoided as they increase the risk of improper linking and generation of duplicate messages. Cross Regional links may only be established with the knowledge of the REC in both regions. The REC must be notified prior to or at the time of the link being established. If an REC determines that a cross regional link is contributing to the creation of duplicate messages, the REC may request that the link be terminated. The use of the PATHline option is required for all out of region links. If a sysop has a prior history of creating duplicate messages because of out of region links, the REC may require prior notification and approval before an out of region link can be established. Cross Regional links are permitted without notification if one of those systems is a dead-end. Should the status of this link change, then notification is required. Each REC will do their best to make available high speed hubs, out of state hubs, PC Pursuit hubs, etc., to facilitate the low cost, efficient movement of mail within their respective Region. Any Sysop who willfully and knowingly establishes links that either create duplicate loops (topology that creates circular feeds) or who refuses to break such links upon request by their NEC, REC, or ZEC shall be subject to disciplinary action as described previously in this document. See Section III. 17. MESSAGE STANDARDS: Until the adoption of a superseding standard by the Fidonet Technical Standards Committee, the following Echomail message standards are recommended: a) Eight-bit characters (ASCII 128-255) and non- FIDONEWS 14-27 Page 24 7 Jul 1997 printing low-order codes (ASCII 2-31) are prohibited, except the use of 8Dh (soft character) per FTS- 0004. This is not intended to discourage participation of foreign zones or networks, which may permit said characters. Any echomail processor should pass information exactly as it was received, without stripping any non-standard characters. b) Origin lines should be limited to 79 characters including the required ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional). c) Tear lines should be limited to 35 characters including the required "---" lead-in. These should only contain packer or editor program identification. Tear lines for message editors are discouraged. If an editor adds a tear line, it should also add an origin line to avoid multiple tear lines. d) "Extra" origin lines (ZoneGating) are limited to essential information only. This consists of the required lead-in plus the network name "Gateway" and optionally the software ID followed by a Zone:Net/Node address. Example: " * Origin: FidoNet Gateway (TComm 88:372/666)" e) SEEN-BY addresses should be in sorted order. Multiple AKA's are not allowed in SEEN-BY lines unless you have more than one address which processes mail. Or for one month during change of an existing address (to avoid duplicates to the previous address). Node 0 addresses should not be used for echomail distribution. f) All current FTSC specifications must be followed. VI. ENFORCEMENT Enforcement of this policy document shall be under the provisions of General FidoNet policy. Complaints concerning Echomail violations defined under this policy may be filed by the aggrieved individual, the conference moderator or by any level of Echomail Coordinator to the appropriate *C level. All complaints made pursuant to this policy must be made within 60 days of the date of occurrence or discovery. Complaints shall be filed under the provisions of General Fidonet Policy, with a copy to the respective *EC. Enforcement is immediate, with any currently existing software allowed 60 days to conform (from the date EchoPol1 goes into effect). A 30-day extension may be granted solely at the discretion of the ZEC if efforts to bring about FIDONEWS 14-27 Page 25 7 Jul 1997 compliance are clear. Continued use of aberrant software after this period shall be deemed excessively annoying. VII. ADOPTION OF POLICY 1. ADOPTION: This policy shall become effective upon ratification by a simple majority of those voting. Those eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs, and NECs. Those individuals holding more than one position can cast only one vote. 2. GRANDFATHER CLAUSE: Within 60 days of adoption of this policy, moderators shall be appointed for all existing Echomail Conferences which do not now have a moderator. Moderators shall be appointed by the ZEC from those volunteering as moderator or if no volunteer is available then the ZEC shall request and appoint a moderator for the conference. In the case where more than one individual claims to be the conference moderator and no agreement can be reached, the ZEC may order the conference retired and ban the further use of the specific conference name. Failure of the individuals to retire the conference name shall be deemed excessively annoying behavior. VI. BACKBONE STRUCTURE This section is for information purposes only. It gives a plain English description of the current structure and operation of the Backbone. The ZEC may change this structure without amending this document. At the top of the Echomail distribution network, there are systems commonly called Stars. These systems are usually dedicated to passing Echomail. The stars operate at the discretion and direction of the ZEC. At the time of this writing there are 3 stars, each has a backup system/plan in the event of a failure. In general, the Stars link to one another and feed the RECs. The RECs are then responsible for distribution of the echomail within their Region. Normally, the REC will feed the NECs in that region. The NEC is responsible for distribution of Echomail to the individual Sysops within a net. Note that the RECs and NECs can appoint Hubs to help in the distribution of Echomail. That is, they do not have to directly feed the lower level. This is the distribution GOAL. Because of less expensive phone rates and other reasons, this distribution method is not followed exactly. Any change to the above requires agreement of the *EC's involved. All *ECs will use all the FIDONEWS 14-27 Page 26 7 Jul 1997 tools at their disposal, such as hubs, high speed modems, ROA, Wide Area Calling plans, PC Pursuit, corporate sponsorship, etc., to provide fast, efficient, and cost effective movement of echomail. Echopol Committee Mike Ratledge Norm Henke Rick McWilliams Barry Shatswell -30- [This may give the clamoring newbies and Echomail weenies an idea where some of the wacky ideas concerning Echomail came from. With something to compare it to, let's see them come up with one that makes sense in 1997.] [fnord] [And, folks, when you write these things, PLEASE DON'T right justify them. All that white space is a real pain to remove. And chip in for a spell-checker.] Ed. ----------------------------------------------------------------- FIDONEWS 14-27 Page 27 7 Jul 1997 ================================================================= GETTING TECHNICAL ================================================================= No more "Getting technical" ? by Frank Ellermann, 2:240/5815.1 I hate the idea, that now after all old FTSC documents the "Getting technical" corner could vanish from FidoNews. And there are lots of other interesting technical documents, which should be part of the FTSC library. So when my time allows it, I'll submit some texts I'm aware of. The first one is easy, a FSC proposal lost somewhere in cyber space between David Nugent and me... Fortunately, because here is the newest third edition: Z2C approved X2C and X2S as user flags in zone 2... :-) Document: FSC-???? | Version: 003 | Date: 03 July, 1997 Zone 2 nodelist flags Frank Ellermann, 2:240/5815.1 Introduction ------------ This document informs about known differences of FidoNet zone 2 nodelist flags from FTS-0005.003. The ultimate sources for these informations are the current zone 2 nodelist epilog and the setup for flag corrections at Z2C, but it may be difficult to get these sources for readers in other zones. FTS-0005 flags -------------- The following flags are used as specified in FTS-0005.003: CM Node accepts mail 24 hours a day MO Node does not accept human callers LO Node accepts calls only from valid listed node numbers in the current FidoNet nodelist V21 ITU-T V21 300 bps full duplex V22 ITU-T V22 1200 bps full duplex In zone 2 a value of 1200 in the former "baud rate" field implies V22. Today only two nodes not supporting at least V22bis or ISDN still exist in the zone 2 segment, therefore the flags V21 and V22 are obsolescent. Both flags should be dropped from FTS-0005. V29 ITU-T V29 9600 bps half duplex V33 ITU-T V33 V33 cannot be used in connecting Fido nodes over public dial-up lines and is most probably a historical error in FTS-0005. This flag should be removed from FTS-0005 a.s.a.p. A similar argument is applicable on V29, and few nodes flagging V29 today all support FIDONEWS 14-27 Page 28 7 Jul 1997 at least V32. The next version of FTS-0005 should drop V29. V32 ITU-T V32 9600 bps full duplex -> V32B ITU-T V32bis 14400 bps full duplex (implies V32) V34 ITU-T V34 28800 bps full duplex FTS-0005 specifies V32b and V42b (capital V and small b), current nodelist practice in FidoNet shows all combinations of small and capital letters for flags. This was no problem before FSC-0062 introduced case-sensitive flags. In zone 2 all old flags except from FSC-0062 flags are upper case, and a NODEDIFF changing this convention would be annoying. The best solution is to stick to the current practice and treat all old flags as case-insensitive. H96 Hayes V9600 HST USR Courier HST up to 9600 (implies MNP) H14 USR Courier HST up to 14400 (implies HST) -> H16 USR Courier HST up to 16800 (implies H14 and V42B) MAX Microcom AX/96xx series PEP Packet Ensemble Protocol CSP Compucom Speedmodem -> ZYX Zyxel series 16800 bps (implies V32B and V42B) -> V32T V.32 Terbo 19200 bps (implies V32B) VFC V.Fast Class 28800 bps If a flag directly or indirectly implies other flags, then these other flags are not shown in a nodelist entry, because this would be redundant. Unfortunately the rules for redundancies in zone 2 and FTS-0005 are different. Zone 2 continued to avoid redundancy with most "new" flags, but FTS-0005.003 specified no redundancies for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this context are flags approved by FidoNet International Coordinators since 1989, when FTS-0005.TXT, the predecessor of FTS-0005.003, was published. For details see the chapter "implications" below, for now only note, that in zone 2 H16 implies V42B, ZYX implies V32B and V42B, and V32T implies V32B. Zone 1 and zone 2 have introduced a user flag Z19 approved by the corresponding Zone Coordinator. User flags are discussed later, for now only note, that in zone 2 ZYX is specified as Zyxel 16k8, while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag for all Zyxel protocol speeds. | Today there is no more node in FidoNet still flagging MAX, this flag is obsolete and should be dropped from FTS-0005. The flags HST, H14, and CSP should be marked as obsolescent. MNP Microcom Networking Protocol error correction V42 ITU-T LAP-M error correction w/fallback to MNP 1-4 -> V42B ITU-T LAP-M error correction w/fallback to MNP 1-5 As mentioned above FTS-0005 specifies V42b (capital V, small b). In zone 2 all case-insensitive flags are listed in upper case. FIDONEWS 14-27 Page 29 7 Jul 1997 The next version of FTS-0005 will probably adopt the better V42B and MNP definitions of the zone 3 nodelist epilog. FTS-0005.003 specifies an implication of V42 by V42B, but the exact meaning of the flag MNP is unclear. Most probably this flag was meant to indicate support of MNP 1-4, and in this sense V42B implies MNP: MNP Microcom Networking Protocol 1-4 error correction V42 ITU-T LAP-M error correction w/fallback to MNP 1-4 V42B ITU-T V.42 LAP-M plus V.42bis BTLZ data compression In zone 2 MNP is considered as redundant, if V42B is flagged or implied by other flags like H16, ZYX, or Z19. | MN No compression supported in insecure inbound XA Bark and WaZOO file/update requests XB Bark file/update requests, WaZOO file requests XC Bark file requests, WaZOO file/update requests XP Bark file/update requests XR Bark and WaZOO file requests XW WaZOO file requests XX WaZOO file/update requests These flags are equivalent in FTS-0005 and in the zone 2 segment. Gx..x Gateway to domain 'x..x' Valid values for this flag are assigned by the Fido International Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2 only GUUCP gateways are flagged. #01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A #02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A -> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A #09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A #18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A #20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A The variants !01, !02, !08, !09, !18, and !20 indicate missing Bell 212A support. In zone 2 #02 or !02 would be obviously redundant. Today less than five 1200 modems (V22 or Bell 212A) are listed. A future version of FTS-0005 should drop !mn variants together with V21 and V22 flags. Further most non-CM systems flagging #mn or !mn today probably want to show additional online times instead of additional mail hours. As soon as FSC-0062 flags have been approved by the IC or adopted as FTS by the FTSC, the following version of FTS-0005 should mark #mn as obsolescent and recommend the more flexible FSC-0062 flags (see below). User flags ---------- An example for one of several problems in zone 2 with user flags: FIDONEWS 14-27 Page 30 7 Jul 1997 ...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC These flags indicate a modern Zyxel ISDN-modem and two additional user flags ENC and NEC. This possible user flags string contains 34 characters, but at most 32 characters are allowed in FTS-0005. ...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC During the period for the replacement of old by new ISDN flags (several months !) many nodes listed both old and new flags for maximal compatibility, and no problems with nodelist compilers or mailers caused by too long user flags strings were reported. Therefore the length limit in FTS-0005 is probably unnecessary and at least inconsequent: Other nodelist fields like the system name are unlimited, so why only restrict the user flags string? To help developers an upper limit of e.g. 255 characters for a nodelist line and 63 characters for fields 3 to 6 would be more useful. The next problem with user flag strings as specified in FTS-0005 is their introduction by the letter U with no comma following: Nodelist compilers could parse ...,UISDN,USR in user flags ISDN and USR. But USR cannot be approved as "real" flag, because the combination ...,USR,UISDN would then be parsed in SR and UISDN. Other side effects of the FTS-0005 specification are additional difficulties in finding flags. Almost all flags are separated by a comma, only the first user flag can be an exception to this simple rule. If the order of user flags has no meaning, then... ...,UV120L,V120H ...,UV120H,V120L ... are equivalent. A "simple" solution of this problem could be to treat UV120L as synonym for V120L, and UV120H as synonym for V120H. Similar problems show up, if user flags are counted, etc. Obviously a nodelist compiler looking for user flags has always to consider the case "user flag separated by comma". In zone 2 this idea was simply extended to the first user flag: All flags are separated by commas. Flags not yet approved by the International Coordinator or the FTSC (i.e. user flags only used experimentally or locally) are separated by a new pseudo flag U. -> U pseudo flag to the left of at least one user flag All flags following this pseudo flag U are user flags, all flags before this pseudo flag are "real" flags specified in FTS-0005 or approved by the International Coordinator. Because this definition should be compatible with any reasonable software implementation based on FTS-0005.003, and simplifies the handling of user flags significantly, a future FTS-0005 version FIDONEWS 14-27 Page 31 7 Jul 1997 will hopefully adopt it. Approved zone 2 user flags -------------------------- In zone 2 user flags have to be approved by the Zone Coordinator. Currently the following zone 2 user flags exist: -> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA) -> V110H ITU-T V.110 38k4 async 'High' (former ISDNB) -> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8 -> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8 -> X75 ITU-T X.75 SLP (single link procedure), 64kbit/s B channel; layer 2 max. framesize N1 = 2048, window size W = 2, frame numbering modulo 8; layer 3 transparent (no packet layer) -> ISDN Other configuration, used only if none of above fits These ISDN flags follow the specification in FSC-0091. -> Tyz Online time flags as specified in FSC-0062 The flag Tyz is used by non-CM nodes online not only during ZMH, y is a letter indicating the start and z a letter indicating the end of the online period as defined below (times in UTC): A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30, D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30, G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30, J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30, M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30, P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30, S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30, V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30. For example TuB shows an online period from 20:30 until 1:00 UTC. -> Z19 Zyxel series 19200 bps (implies ZYX) -> X2C x2 client w/ 56000 bps (should imply V34 and V42B) -> X2S x2 server w/ 56000 bps (should imply V34 and V42B) -> K12 Systems offering all educational K12-conferences -> ENC The node accepts inbound encrypted mail -> NC Network Coordinator (only if the NC is not the host) -> NEC Net Echomail Coordinator (at most one per net) -> REC Region Echomail Coordinator (at most one per region) -> ZEC Zone Echomail Coordinator (at most one per zone) Redundant AKAs used to indicate echomail coordination in zone 2 are no longer permitted. One *EC flag is valid for all AKAs of a given sysop. Flag implications ----------------- Flag implications directly or indirectly specified in FTS-0005: FIDONEWS 14-27 Page 32 7 Jul 1997 HST => MNP H14 => MNP HST H16 => MNP HST H14 V42b => V42 (MNP ?) V32b => V32 Flag implications specified in the zone 2 nodelist epilog: HST => MNP H14 => HST MNP -> H16 => V42 MNP V42B H14 HST -> V42B => V42 MNP -> ZYX => V42 MNP V42B V32B -> Z19 => V42 MNP V42B V32B ZYX V32B => V32 -> V32T => V32 V32B -> V110L => ISDN -> V110H => ISDN -> V120L => ISDN -> V120H => ISDN -> X75 => ISDN The latter ISDN flag redundancies are a consequence of FSC-0091. | Maybe some of the following implications could be added in zone 2: VFC => V32 V32B | or VFC => V32 V32B MNP V42 V42B | X2C => V34 | or X2C => V34 MNP V42 V42B | X2S => V34 | or X2S => V34 MNP V42 V42B Flag implications (i.e. not listing redundant flags) have several advantages: Some old nodelist tools are unable to handle too long lines. Old flags like HST, MNP, V42, or V32 vanish automatically, if they are implied by H16, V42B, V32B, or better. Redundancies defined globally for the whole nodelist help to avoid flag errors. "Baud rate" field ----------------- The former "baud rate" field 7 in the nodelist as specified in FTS- 0005 is nearly useless today: Except from a few remaining 1200 and 2400 nodes almost all nodelist entries show either 9600 for all modem protocols better than V22bis or 300 for ISDN only nodes. No more V21 or Bell 103 modems are listed today. Obscure "baud rate" values 19200 and 38400 specified in FTS-0005 have not been used in the FidoNet nodelist. So all a reasonable nodelist compiler can do today, is treat 300 as indicator for ISDN only, and treat unknown or missing values in field 7 like 9600. A new meaning for field 7 as speed field could be really useful. An example is ZYX, if we would have 16800, 19200, 28800, and 33600 as speed values, then their combination with ZYX is all we need technically, Z19 would be unnecessary. Another example is HST, FIDONEWS 14-27 Page 33 7 Jul 1997 flags H14 and H16 are unnecessary, if HST is combined with 9600, 14400, 16800, 28800, or 33600. Variants of PEP could be shown in the speed field without new flags. "Enhanced V32.terbo" could be shown by 21600. Most important: V34 may have the famous bug not allowing connects from new "V34+", unless the caller disabled symbol rate 3429. If "V34+" is indicated by speed 33600, then an appropriate setup for all kinds of V34 connects is possible. A future version of FTS-0005 hopefully allows the following speed values in field 7: 300 reserved for ISDN only (for historical reasons) 1200 V22 or Bell 212A (obsolete) 2400 implies V22bis 9600 default, used with V32, HST, H96, PEP, CSP 12000 rare variant of V32 14400 used with V32b or HST (obsoleting H14) 16800 used with ZYX or HST (obsoleting H16) 19200 used with V32T or ZYX (obsoleting Z19) 21600 rare variant of V32T (no "H21" needed) 28800 used with VFC or V34 33600 used with V34 (no V34+ or V34b needed) | 56000 used with X2C, X2S, or "K56FLEX" The following values should be specified in FTS-0005, because they are already used in nodelists of other FTNs: empty no value, useful for Pvt nodes or in point lists 19200 used with V110L, V32T, or ZYX (obsoleting Z19) 38400 used with V110H | 56000 used with V120L, X2C, X2S, or "K56FLEX" | 64000 used with V120H, X75, X2S, or other ISDN equipment Allowing more than 12 speed values or allowing ISDN speeds could break old software. Therefore the transition could be done in two steps, first add all non-ISDN speeds (ISDN only shown as 300). Later remove 300 (ISDN only) and 1200 (obsolete) replacing 300 by 19200, 38400, 56000, or 64000. Thanks to... ------------ Ben Baker St. Louis nodelist format Rick Moore FTS-0005.TXT David Nugent FTS-0005.003 and NLTOOLS Jonny Bergdahl ERRFLAGS 2.6 Ward Dossche Zone 2 nodelist epilog Arjen Lentz FSC-0091.001 David J. Thomas FSC-0062.003 Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV Jim Barchuk LNDL 2.7 Marius Ellen FASTV7 2.03j (but I still prefer 1.45b ;-) Jan Vermeulen, Jan Ceuleers, Ian Smith, and many others... FIDONEWS 14-27 Page 34 7 Jul 1997 - eof - ----------------------------------------------------------------- FIDONEWS 14-27 Page 35 7 Jul 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 185 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-157|Nodelist-164|Nodelist-171|Nodelist-178|Nodelist-185|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 8182| 8182 0 | 8182 0 | 8182 0 | 7828 -354 |30| | 2 | 15774|15703 -71 |15666 -37 |15640 -26 |15577 -63 |60| | 3 | 758| 758 0 | 758 0 | 743 -15 | 728 -15 | 3| | 4 | 519| 514 -5 | 514 0 | 519 5 | 517 -2 | 2| | 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0| | 6 | 1078| 1078 0 | 1079 1 | 1079 0 | 1079 0 | 4| +----+------+------------+------------+------------+------------+--+ | 26398|26322 -76 |26286 -36 |26250 -36 |25816 -434 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-27 Page 36 7 Jul 1997 ================================================================= ECHOING ================================================================= ECHOLIST The EchoMail Conference List 01 July 1997 Due to the proximity of my vacation, the July issue of the Elist will be dropped. The next regular issue will be 01 August 1997. My apologies for the inconvenience. Adrian Walker Echolist Coordinator 1:1/201 ---ooo000ooo--- ----------------------------------------------------------------- FIDONEWS 14-27 Page 37 7 Jul 1997 ================================================================= ADVERTISE YOUR FREE SERVICE/EVENT ================================================================= Don't risk being banned! Use FIDOTEST. Almost ALL other echoes FORBID posting TEST messages. Where do you and your users send test' posts to ensure they are leaving your system? Which Backboned echo can you use to ensure your posts are reaching the far corners of Z1, or to see if upstream/downstream systems are wrecking or loosing your message? Why not a specific echo devoted to testing echomail links? There is one! If you believe it to be beneficial for the Fidonet community to have a _dedicated_ and _authorized_ echo for testing, be sure to ask your REC to ensure that FIDOTEST - the Fidonet TEST echo and malfunction conference gets Z1-Backboned. For your edification, the complete echo rules follow: FIDOTEST Echo Rules and Information =================================== Revision 1, July 1997 (This document may be revised without prior notice.) >> Description: Fidonet TEST echo and malfunction conference >> Extended Description: Use the TEST echo to post TEST ECHOMAIL! Useful for checking your tosser/scanner/FTS mail software configurations. **ALSO: discuss/query about broken links, dupe loops, and other problems within Fidonet and the North American Backbone on all net/region/zone levels here. All users and sysops welcome. >> Moderator: Ronnie Grant, 1:2612/114, 1:102/836, 1:3618/555, ronnie.grant@global.nws.net, ronnie.grant@bbsnets.com, rg@dhp.com, ronnie@eqcity.ktb.net >> Rules: 1. No off-topic posts. 2. No profanity. 3. No "flooding" or other abuse of the echo. 4. No illegal activities or posts. ----------------------------------------------------------------- FIDONEWS 14-27 Page 38 7 Jul 1997 Remember: only YOU can make sure your REC knows your position on the backboning of FIDOTEST. Netmail him today, because without your help, tomorrow's Fidonet may never arrive. Ronnie L. Grant Moderator, Fidonet FIDOTEST echo ----------------------------------------------------------------- FIDONEWS 14-27 Page 39 7 Jul 1997 ================================================================= NOTICES ================================================================= Future History 9 Jul 1997 Independence Day, Argentina. 1 Aug 1997 International FidoNet PENPAL [Echo] meeting in Dijon, France 13 Oct 1997 Thanksgiving Day, Canada. 1 Dec 1997 World AIDS Day. 10 Dec 1997 Nobel Day, Sweden. 12 Jan 1998 HAL 9000 is one year old today. 30 Apr 1998 Queens Day, Holland. 22 May 1998 Expo '98 World Exposition in Lisbon (Portugal) opens. 1 Dec 1998 Fifteenth Anniversary of release of Fido version 1 by Tom Jennings. 31 Dec 1999 Hogmanay, Scotland. The New Year that can't be missed. 1 Jan 2000 The 20th Century, C.E., is still taking place thru 31 Dec. 15 Sep 2000 Sydney (Australia) Summer Olympiad opens. 1 Jan 2001 This is the actual start of the new millennium, C.E. -- If YOU have something which you would like to see in this Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Wed Jul 02 22:58:14 1997 From: C. Ingersoll @ 1:2623/71 FIDONEWS 14-27 Page 40 7 Jul 1997 To: Editor @ 1:1/23 Date: 01 Jul 97 02:14:46 Subj: Fidonet via Internet Hubs Fidonet Via Internet Hubs Speed| Node# | Operator | Facilities | Basic Rate -----+-----------+-------------------+-------------------+----------- T1 | 1:270/101 | George Peace | FTP | $30mo. T1 | 1:396/1 | John Souvestre | FTP | $25mo. T1 | 1:12/12 | Ken Wilson | FTP | $24mo. T1 | 1:140/12 | Bob Seaborn | FTP, TransX | $5/$20 T1 | 1:346/250 | Aran Spence | FTP, TransX | $10mo. 64k | 1:124/7008| Ben Hamilton | FTP, VMoT, TransX | $20mo. 56k | 1:13/25 | Jim Balcom | FTP | $20mo. 33.6 | 1:2604/104| Jim Mclaughlin | FTP, VMoT, UUEMAIL| $1mo. 33.6 | 1:2624/306| D. Calafrancesco | VFOS | $15yr. 33.6 | 1:281/169 | Brian Greenstreet | FTP | $2mo. 28.8 | 1:330/204 | Patrick Rosenheim | Transx | $25yr. -- * VMoT = Virtual Mailer over Telnet compiled by Cindy Ingersoll, 1:2623/71, (609)814-1978, fbn@cyberEnet.net Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews. --- * Origin: * Fly By Night * (609)814-1978 *(1:2623/71) ----------------------------------------------------------------- FIDONEWS 14-27 Page 41 7 Jul 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 Whew. Been a big month for me, but a relatively slow one for the list. -=- Snip -=- Submission form for the Latest Greatest Software Versions column OS Platform : Software package name : Version : Function(s) - BBS, Mailer, Tosser, etc. : Freeware / Shareware / Commercial? : Author / Support staff contact name : Author / Support staff contact node : Magic name (at the above-listed node) : Please include a sentence describing what the package does. Please send updates and suggestions to: Peter Popovich, 1:363/264 -=- Snip -=- MS-DOS: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX Announcer 1.11 O S Peter Karlsson 2:206/221 ANNOUNCE BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR CheckPnt 1.0a O G Michiel vd Vlist 2:500/9 CHECKPNT FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16 FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLSTD FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES FrontDoor 2.12 M S JoHo 2:201/330 FD FrontDoor 2.20c M C JoHo 2:201/330 FDINFO GEcho 1.00 T S Bob Seaborn 1:140/12 GECHO GEcho/Plus 1.11 T C Bob Seaborn 1:140/12 GECHO GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GED GoldED/386 2.50 O S Len Morgan 1:203/730 GEX GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM GoldNODE 2.50 O S Len Morgan 1:203/730 GEN Imail 1.75 T S Michael McCabe 1:1/121 IMAIL FIDONEWS 14-27 Page 42 7 Jul 1997 ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT InfoMail/86 1.21 O F Damian Walker 2:2502/666 INFOMAIL InfoMail/386 1.21 O F Damian Walker 2:2502/666 INFO386 InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB IPNet 1.11 O S Michele Stewart 1:369/21 IPNET JD's CBV 1.4 O S John Dailey 1:363/277 CBV Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386 JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G MakePl 1.9 N G Michiel vd Vlist 2:500/9 MAKEPL Marena 1.1 beta O G Michiel vd Vlist 2:500/9 MARENA Maximus 3.01 B P Tech 1:249/106 MAX Max User Ed. 0.18 O F Larry Cooke 1:300/53 MUE McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP Msged 4.10 O G Andrew Clarke 3:635/728 MSGED41D.ZIP Msged/386 4.10 O G Andrew Clarke 3:635/728 MSGED41X.ZIP NEF 2.38 O S Alberto Pasquale 2:332/504 NEFD Opus CBCS 1.79 B P Christopher Baker 1:374/14 OPUS O/T-Track 2.66 O S Peter Hampf 2:241/1090 OT PcMerge 2.8 N G Michiel vd Vlist 2:500/9 PCMERGE PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS RAR 2.01 C S Ron Dwight 2:220/22 RAR RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA Silver Xpress Door 5.4 O S Gary Petersen 1:290/111 FILES Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE Squish 1.11 T P Tech 1:249/106 SQUISH StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL T-Mail 2.600 M S Ron Dwight 2:220/22 TMAIL Telegard 3.02 B F Tim Strike 1:259/423 TELEGARD Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TosScan 1.01 T C JoHo 2:201/330 TSINFO TransNet 1.00 G S Marc S. Ressl 4:904/72 TN100ALL.ZIP TriBBS 11.0 B S Gary Price 1:3607/26 TRIBBS TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG TriToss 11.0 T S Gary Price 1:3607/26 TRITOSS WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE WWIV 4.24a B S Craig Dooley 1:376/126 WWIV WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL XRobot 3.01 O S JoHo 2:201/330 XRDOS OS/2: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2 BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP FIDONEWS 14-27 Page 43 7 Jul 1997 BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2 CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2 FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLST FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GEO GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM GoldNODE 2.50 O S Len Morgan 1:203/730 GEN ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT Maximus 3.01 B P Tech 1:249/106 MAXP Max User Ed. 0.18 O F Larry Cooke 1:300/53 MUEP Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP NEF 2.38 O S Alberto Pasquale 2:332/504 NEF PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE RAR 2.01 C S Ron Dwight 2:220/22 RAR2 Squish 1.11 T P Tech 1:249/106 SQUISHP T-Mail 2.600 M S Ron Dwight 2:220/22 TMAIL2 Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK XRobot 3.01 O S JoHo 2:201/330 XROS2 Windows (16-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL FrontDoor APX 1.12 P S Mats Wallin 2:201/329 FDAPXW Windows (32-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- Argus 95 2.62 M S Max Masyutin 2:469/77 ARGUS95 Argus NT 2.62 M S Max Masyutin 2:469/77 ARGUSNT Argus NT/IP 2.62 M S Max Masyutin 2:469/77 ARGUSIP BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLSTW GoldED 2.50 O S Len Morgan 1:203/730 GEO GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM Maximus 3.01 B P Tech 1:249/106 MAXN Msged/NT 4.10 O G Andrew Clarke 3:635/728 MSGED41W.ZIP NEF 2.38 O S Alberto Pasquale 2:332/504 NEFW PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO T-Mail 2.600 M S Ron Dwight 2:220/22 TMAILNT WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP Unix: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ifmail 2.10 M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX ifmail-tx.rpm ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM FIDONEWS 14-27 Page 44 7 Jul 1997 Msged 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK Amiga: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS Msged 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TrapDoor 1.86.b2 M S Maximilian Hantsch 2:310/6 TRAPDOOR TrapDoor 1.86.b2 M S Maximilian Hantsch 2:310/6 TRAPBETA TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS Atari: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ApplyList 1.00 N F Daniel Roesen 2:2432/1101 APLST100.LZH BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY BTNC 2.00 N G Daniel Roesen 2:2432/1101 BTNC JetMail 0.99beta T S Joerg Spilker 2:2432/1101 JETMAIL Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser, C-Compression, F-Fossil, O-Other. Note: Multifunction will be listed by the first match. Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial, X-Crippleware, D-Demoware, G-Free w/ Source Please send updates and suggestions to: Peter Popovich, 1:363/264 ----------------------------------------------------------------- FIDONEWS 14-27 Page 45 7 Jul 1997 ================================================================= FIDONEWS PUBLIC-KEY ================================================================= [this must be copied out to a file starting at column 1 or it won't process under PGP as a valid public-key] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 Comment: Clear-signing is Electronic Digital Authenticity! mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs 1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23 O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+ UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3 8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6 3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2 raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9 Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5 toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1 v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg +Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/ Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg== =61OQ -----END PGP PUBLIC KEY BLOCK----- File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone 1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on the FidoNews homepage listed in the Masthead information. ----------------------------------------------------------------- FIDONEWS 14-27 Page 46 7 Jul 1997 ================================================================= FIDONET BY INTERNET ================================================================= This is a list of all FidoNet-related sites reported to the Editor as of this appearance. ============ FidoNet: Homepage http://www.fidonet.org FidoNews http://ddi.digital.net/~cbaker84/fidonews.html HTML FNews http://www.geocities.com/Athens/6894/ WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html FTSC page http://www2.blaze.net.au/ftsc.html Echomail http://www.portal.ca/~awalker/index.html WebRing http://ddi.digital.net/~cbaker84/fnetring.html ============ Zone 1: http://www.z1.fidonet.org Region 10: http://www.psnw.com/~net205/region10.html Region 11: http://oeonline.com/~garyg/region11/ Region 13: http://www.smalltalkband.com/st01000.htm Region 14: http://www.netins.net/showcase/fidonet/ Region 15: [disappeared?] Region 16: http://www.tiac.net/users/satins/region16.htm Region 17: http://www.portal.ca/~awalker/region17.htm REC17: http://www.westsound.com/ptmudge/ Region 18: http://www.citicom.com/fido.html Region 19: http://www.compconn.net ============ Zone 2: http://www.z2.fidonet.org ZEC2: http://www.proteus.demon.co.uk/zec.htm Zone 2 Elist: http://www.fbone.ch/z2_elist/ Region 20: http://www.fidonet.pp.se (in Swedish) Region 24: http://www.swb.de/personal/flop/gatebau.html (in German) Region 25: http://members.aol.com/Net254/ FIDONEWS 14-27 Page 47 7 Jul 1997 Region 27: http://telematique.org/ft/r27.htm Region 29: http://www.rtfm.be/fidonet/ (in French) Region 30: http://www.fidonet.ch (in Swiss) Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish) REC34: http://pobox.com/~chr Region 36: http://www.geocities.com/SiliconValley/7207/ Region 41: http://www.fidonet.gr (in Greek and English) Region 48: http://www.fidonet.org.pl ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: (not yet listed) Region 90: Net 904: http://members.tripod.com/~net904 (in Spanish) ============ Zone 5: (not yet listed) ============ Zone 6: http://www.z6.fidonet.org ============ ----------------------------------------------------------------- FIDONEWS 14-27 Page 48 7 Jul 1997 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Christopher Baker Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees "FidoNews Editor" FidoNet 1:1/23 BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds) more addresses: Christopher Baker -- 1:18/14, cbaker84@digital.net cbaker84@aol.com cbaker84@msn.com (Postal Service mailing address) FidoNews Editor P.O. Box 471 Edgewater, FL 32132-0471 U.S.A. voice: 1-904-409-3040 [1400-2100 ET only, please] [1800-0100 UTC/GMT] ------------------------------------------------------ FidoNews is published weekly by and for the members of the FIDONET INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. OPINIONS EXPRESSED in these articles ARE THOSE OF THE AUTHORS and not necessarily those of FidoNews. Authors retain copyright on individual works; otherwise FidoNews is Copyright 1997 Christopher Baker. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or the Editor. =*=*=*=*=*=*=*=*= OBTAINING COPIES: The most recent issue of FidoNews in electronic form may be obtained from the FidoNews Editor via manual download or file-request, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained by sending SASE to the above postal address. File-request FIDONEWS for the current Issue. File-request FNEWS for the current month in one archive. Or file-request specific back Issue filenames in distribution format [FNEWSEnn.ZIP] for a FIDONEWS 14-27 Page 49 7 Jul 1997 particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97. Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in size from 48K to 1.4M. INTERNET USERS: FidoNews is available via: http://www.fidonet.org/fidonews.htm ftp://ftp.fidonet.org/pub/fidonet/fidonews/ ftp://ftp.aminet.org/pub/aminet/comm/fido/ *=*=* You may obtain an email subscription to FidoNews by sending email to: jbarchuk@worldnet.att.net with a Subject line of: subscribe fnews-edist and no message in the message body. To remove your name from the email distribution use a Subject line of: unsubscribe fnews-edist with no message to the same address above. *=*=* You can read the current FidoNews Issue in HTML format at: http://www.geocities.com/Athens/6894/ STAR SOURCE for ALL Past Issues via FTP and file-request - Available for FReq from 1:396/1 or by anonymous FTP from: ftp://ftp.sstar.com/fidonet/fnews/ Each yearly archive also contains a listing of the Table-of-Contents for that year's issues. The total set is currently about 11 Megs. =*=*=*= The current week's FidoNews and the FidoNews public-key are now also available almost immediately after publication on the Editor's new homepage on the World Wide Web at: http://ddi.digital.net/~cbaker84/fidonews.html There are also links there to jim barchuk's HTML FidoNews source and to John Souvestre's FTP site for the archives. There is also an email link for sending in an article as message text. Drop on over. =*=*=*=*=*=*=*=*= A PGP generated public-key is available for the FidoNews Editor from FIDONEWS 14-27 Page 50 7 Jul 1997 1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It is also posted twice a month into the PKEY_DROP Echo available on the Zone 1 Echomail Backbone. *=*=*=*=* SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators also have copies of ARTSPEC.DOC. Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141, and are used with permission. "Disagreement is actually necessary, or we'd all have to get in fights or something to amuse ourselves and create the requisite chaos." -Tom Jennings -30- -----------------------------------------------------------------