Volume 7, Number 5 29 January 1990 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Dale Lovell Thom Henderson Chief Procrastinator Emeritus: Tom Jennings FidoNews is published weekly by the System Operators of the FidoNet (r) International BBS Network as its official newsletter. Its contents represent a compendium of articles freely submitted and openly published by members of the FidoNet (r) community. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Copyright 1990, Fido Software. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact Fido Software at (415)764-1688. This is a compilation of individual articles contributed by their authors or authorized agents of the authors. Contribution of these articles to this compilation does not diminish the rights of the authors. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley St., San Francisco, CA 94107 and are used with permission. We don't necessarily agree with the contents of every article published here. Most of these materials are unsolicited. No article submitted by a FidoNet SysOp will be rejected if it is properly attributed and legally acceptable. We will publish every responsible submission received. Table of Contents 1. EDITORIAL ................................................ 1 And Now -- FidoNet after IFNA ............................ 1 2. ARTICLES ................................................. 2 Come to FidoCon '90! ..................................... 2 Internetwork Gateway Policy - Another Perspective ........ 5 And more! FidoNews 7-05 Page 1 29 Jan 1990 ================================================================= EDITORIAL ================================================================= I have heard that this past weekend's IFNA meeting came to an end with IFNA remaining alive. As I hear it, the reason has to do with corporate laws which make it necessary for the paid-up members of IFNA to vote in favor of dissolution before the board can act. This of course doesn't necessarily have any bearing on the operations of the net. IFNA has been a largely irrelevant presence for the past two years or so, and the fact that today it continues to exist changes nothing. In fact, if you carefully read this week's nodelist, or for that matter the first page of FidoNews, you will see that life is indeed going on without IFNA. Since IFNA continues to exist, and since its bylaws require that it regard FidoNews as its official publication, there will no doubt be many articles here, probably until some time after the formal ending of the Association. Most, I suspect, will relate to official business that simply must be transacted. Be patient with them. And please don't get the idea that I consider it appropriate to start dancing on IFNA's grave. IFNA was a damned fine idea which died of a particularly toxic mixture of cynicism and apathy. When the time finally comes, I'll mourn the passing of this idea, if you don't mind. Please just allow me my moment of silence. Thank you. ----------------------------------------------------------------- FidoNews 7-05 Page 2 29 Jan 1990 ================================================================= ARTICLES ================================================================= Come to FidoCon '90! by Bill VanGlahn, 1/90, FidoCon Committee Chairman As you may or may not know, this year's FidoCon is being hosted August 1-5 at the Conclave '90 sysops convention by the Secret Sysop Society in Net 107 in New Jersey. As you can probably guess by the name, we're out to have some fun! Well, now that we've gotten our act together, here's some of the details, but remember, don't tell anyone! It's a SECRET! ;-) We wanted this year's FidoCon to be more than just a convention. Past FidoCon's have been lots of fun for the sysops, but probably pretty boring for the rest of the family, so we've gone out of our way to make sure that this year you can plan on spending a real vacation here in the New York/New Jersey metropolitan area. Additionally, we've also simplified the registration procedures with our all-inclusive "chinese menu" registration form (to be published next week or the following). No longer will you have to worry about what meals you're going to attend, make your own room reservations, etc. Just pick the plan you want to have, and we'll take care of the rest! Well, on with the show: Plans A & B include the hotel room, all meals (including Friday's banquet), and the conference fee, all in one cost. Please note the discounts for early registration: Before 6/1/90: Before 4/1/90: -------------- -------------- A. Single Occupancy.......$595.00 $545.00 $495.00 B. Double Occupancy.......$450.00 $400.00 $350.00 C. Conference w/ meals....$300.00 $250.00 $200.00 D. Conference w/ Banquet..$205.00 $155.00 $105.00 E. Conference only........$175.00 $125.00 $75.00 F. Banquet only...........$130.00 $80.00 $30.00 (Those registering before 4/1/90 get a $100.00 discount, those registering before 6/1/90 get a $50.00 discount on all plans.) The conference opens with a pool-side welcoming cocktail party, at which beer & wine will be covered by your meal ticket. Friday night will be the sysop's banquet, which is also included in plans A-D (and F, of course), and there'll be a special barbecue lunch on saturday afternoon. FidoNews 7-05 Page 3 29 Jan 1990 Seminars will be held from 10am till noon, and from 1PM until 4, to give all participants plenty of time to recover from those all-night 'bull sessions' where the REAL activity takes place! We promised you outdoor activies, too, so here they are: (Since we're dealing with sysops, we've formatted the 'external events' into an event table) Start End Thu 08:30 16:30 ;Day trip to the Beach $24.50 Thu 14:30 22:30 ;Bus trip to Atlantic City $22.00 Thu 17:30 23:00 ;Twilight Manhattan Tour $37.50 Thu 18:30 23:00 ;A Night On Broadway $71.00 Fri 07:30 17:30 ;Daytime Shopping Tour: NYC $36.50 Fri 08:30 16:30 ;Day trip to the Beach $24.50 Fri 14:30 22:30 ;Bus trip to Atlantic City $22.00 Fri 17:30 23:30 ;Twilight Manhattan Tour $37.50 Sat 17:00 23:00 ;Twilight Manhattan Tour $37.50 Sat 19:30 22:00 ;Grand Costume Ball $50.00* * Costume mandatory, and included in entrance fee The TWILIGHT TOUR of New York includes a ride through Times Square (you know, that place you see every New Year's Eve), the marquees of Broadway, a trip to Macy's, the world's largest department store, a walking tour through Greenwich Village, then a ride through Soho and Little Italy and then to Chinatown for dinner. The tour then continues on to the financial district of Wall Street, and Battery Park, where you'll board a ferry that will take you across New York harbor to Ellis Island and a breath-taking view of the Manhattan skyline. The tour then finishes off with a trip past the United Nations building, Rockefeller Center, the Channell Gardens, and terminates at the Empire State building. All in all, the tour takes about 5 hours and is well worth the fee of $37.50. The Grand Costume Ball will be held at Medieval Times, a new type of dinner theater, where the times of King Arthur are brought to life again. The theater is an actual medieval area, where feats of heroics, jousting tournaments, and demonstrations of Renaissance life are recreated, all while you enjoy a true Medieval feast! Costumes are mandatory, and included in the $50.00 fee. The day trips to the beach are held at the famous New Jersey Shore, at beautiful SEAside Park. Lay on the beach all day, or enjoy the amusement park on the boardwalk! Anyone for miniature golf? $24.50 includes bus fare. FidoNews 7-05 Page 4 29 Jan 1990 Trips to Atlantic City include bus fare to the famous casinos on the board walk, as well as casino 'comps' (coupons, rebates, free tickets, etc.). The activities on the beach and boardwalk are also available for those not into the fast action and bright lights of the casinos. $22.00 For those so inclined, registration also includes use of the on premises Meadowlands Health Club and all equipment, and free admission to Cricket's nightclub and disco. For further information, please contact me at 1:1/90. Of course, we'll have the usual airline discounts (details soon), so we hope to see you all there! ----------------------------------------------------------------- FidoNews 7-05 Page 5 29 Jan 1990 Internetwork Gateway Policy ------------ ------- ------ Tim Pearson 1:286/703 I submitted this article not in an attempt to elicit additional caustic reactions to the "Gateway Document" but rather in an attempt to clarify and correct a few misconceptions and to publicly answer some questions I've been asked frequently since the document was published. I'd like to begin with some answers to some commonly asked questions: - "Is the Gateway Document in effect now? The article said it would go into effect in 30 days." No, the document is not in effect. No, that is not what the article said would happen. The article said the document would be submitted to the International Coordinator for approval in thirty days. Everyone will be given ample notice before the document goes into effect. Stay tuned to FidoNews. - "I'm the IC of XYZ-Net. Am I going to loose my echomail feeds when the document is implemented?" No evil FidoNet axe will fall upon your echomail feed at midnight on the day the document goes into effect. The Internetwork Coordinator will help you find the software necessary to comply with the requirements. No reasonable request for assistance or additional time has or will be refused. Please contact the Internetwork Coordinator for further information on the registration and certification process. Over a half dozen networks have already registered. None of them were turned down. - "If my nodes have FidoNet addresses then I can't get a gateway, right? The document says that if you have a FidoNet address you must get your echomail directly from FidoNet." Wrong. The document says that this is the expected method. It assumes that most folks with other than a purely political motivation would prefer to take the shortest distance between two points. The overriding consideration is that non-FidoNet addresses not appear in FidoNet echomail while said echomail is inside FidoNet and that all echomail gateways also be bidirectional netmail gateways. If you have a case to make with respect to this issue, please make it (even if it is purely political). The key issue in my mind is that you demonstrate a willingness to cooperate with FidoNet in good faith on technical and administrative issues. We certainly pledge to cooperate in good faith with you. Don't believe everything you hear. I suggest you contact the Internetwork Coordinator directly and see FidoNews 7-05 Page 6 29 Jan 1990 for yourself if all the dire predictions are true. - "Where do you get the authority to implement such a document?" I direct your attention to Section 7.1 of Policy4 as adopted by FidoNet. I was going to address some other points next. However, I think the following echomail reply to what, in my opinion, was a very sincere message from Jack Decker makes these points more concisely than any rewording I could come up with. I would like to thank Mr. Decker for his reasoned approach to this issue. Msg # 2907 From: Tim Pearson To: Jack Decker Subj: Re: gateway proposal ________________________________________________________________ > I have never conversed with you before so I hold no > preconceptions (good or bad) about you. I assume that you > felt there was some sincere need for this Gateway Document. Yes I do feel that there is a sincere need for the document. I'll try to explain why as we go along here... > I hope you saw my article in Fidonews in which I expressed > some reservations about this document. I do remember reading one you wrote, Jack. To be totally honest, as I sit here now, I can't remember what points you made versus points made by others who wrote similar articles. As you say, there have been several. I'm sorry I can't recall it more clearly. > ... if there is any consensus at > all, it is that folks don't seem to feel that there is any > need for this document, and/or that it is actually designed > to cause problems for the other networks and to build > additional barriers between the other networks and Fidonet. I'm afraid I can't subscribe to your conclusion, Jack, although from looking only at the public record I can certainly see how you arrived at it. I would think the same thing had I only had FidoNews articles to rely on. The fact is that I (and others on the GPDC) have received numerous positive comments via netmail from folks inside as well as folks outside FidoNet. We have received applications from over a half dozen "Other Networks" (none of which have been rejected, by the way) who seem willing to accept even the original draft of the document. Human nature makes things work kind of like the evening news. One usually doesn't hear loud and long public outcry from those who are FidoNews 7-05 Page 7 29 Jan 1990 satisfied with the way things are going. They have no incentive to "go public." Similarly, you don't see evening news broadcasts filled with reports on how things are going right in the world very often. To be quite honest, I feel that (as we so clearly saw in the IFNA referendum) the "I don't give a damn's" are in the majority again in this case. > > My only question would be, who asked for this document and > why do we need it? I know you guys put a lot of work into it > but if the general consensus of sysops in Fidonet was that > we don't need this, would you guys consider dropping the > whole idea? Or are there one or more people who are > determined to push this through whether anyone wants > it/feels it is needed or not? > I've already spoken to the "general consensus" issue above so I won't waste your time with a restatement of that position. I will try to address the "who asked for it?" part of your question. This was an ongoing process when I became an RC almost exactly one year ago. David Dodell was IC then as I'm sure you remember. David, Randy Bush and virtually all of the RC's at the time (and now as far as I know) seemed to feel that we had a problem that would only get worse. We couldn't possibly make these other networks go away even if we wanted to (and we didn't want to). Therefore, we felt and feel that we should try to put a set of guidelines in place to try to bring some order to the chaotic "grab a zone" practice that was ongoing at the time. David was getting netmails every week asking him as IC to "assign" so and so zone such and such. He was getting messages whose content consisted of irate complaints about network "A" having zone 123 before network "B" and how he should make network "B" use some other zone number. It was a mess. I think I do remember you saying that we are all agreed that Zonegates don't make proper network gateways. Well, then and now, many folks feel they do. I don't think it is malicious. I just think they don't know any better. I tried to bring forward another problem in the lead-in article I wrote when the draft document was published. That problem being that these illicit zone numbers were breaking FidoNet/Internet gateways. (Someone took issue with the use of the word "illicit". From FidoNet's point of view, that is what these non-FidoNet addresses are.) Someone somewhere made the suggestion that this could all be fixed if only FidoNet would compile all the FTN Other Network nodelists along with its own. We have enough trouble keeping our own nodelist current. The technical and logistic nightmare this would create should be obvious. Not to mention the "minor" problem that several FTN other nets are using the same zone number. FidoNews 7-05 Page 8 29 Jan 1990 The only workable solution we could come up with was simply to require that only FidoNet addresses appear in FidoNet mail. That means that some other networks are going to have to change the way their gateways work. We are in the process of helping several other networks to obtain and implement the software necessary to run a proper gateway right now. > I guess I just don't see the need to put up additional walls > between the networks. I think most of us are in this hobby > to communicate with each other, not to figure out ways to > make communications difficult. This document honestly seems > to be moving us in the wrong direction, unless I'm really > missing the reason it's needed... I'm not going to get into a counterproductive discussion of why these "walls" exist and who raised them. The fact is that they exist because other networks exist. These other networks have their own way of doing things, their own nodelists, their own addressing schemes, and their own reasons for existance. All of that is fine. We are attempting to cut some standardized bidirectional "doors" in these walls. We are not trying to make communication more difficult. The fact is, Jack, that communication is virtually impossible (via netmail) to many of the current other networks that are using FidoNet echos. How can we possibly enforce moderator's rules about topical limitations when the option to "take it netmail" doesn't exist in many cases? I would like to see one standard method agreed upon for internetwork routing. I don't care if it is the RBBS-Net method or the ^ADOMAIN method or something else entirely as long as it works -- both directions. One last point and then I'll let you rest your eyes. I've heard many people say how biased and unfair the document is. Consider the analogy to a trade agreement between the U.S. and, say, Japan. The folks in the U.S. think the Japanese are being unfair. The Japanese think the folks in the U.S. are being unfair. It is all a matter of perspective. Folks in FidoNet look at it from the FidoNet perspective. Others look at it differently. My job as a FidoNetter is to look out for the best interest of my network. I'm trying to do that. If I did any less, I would be derelict in my obligation to my network. Folks have every right to establish as many other networks as they like. If we're honest, Jack, we'll admit that without FidoNet echomail, most of them would wither on the vine. Is it too much to ask that they partake of their lifeblood in a manner not harmful to their host? I hope you would agree that the answer to that question is no. Take care (sorry for my verbosity), FidoNews 7-05 Page 9 29 Jan 1990 Tim ----------------------------------------------------------------- FidoNews 7-05 Page 10 29 Jan 1990 Re-formatted for FidoNews from original SYSOP echo message. Date: 23 Jan 90 10:37:37 From: Walter Tietjen (1:151/114) To: Tim Pearson Subj: Re: gateway proposal TP> Someone somewhere made the suggestion that this TP> could all be fixed if only FidoNet would compile TP> all the FTN Other Network nodelists along with TP> its own. We have enough trouble keeping our own TP> nodelist current. The technical and logistic TP> nightmare this would create should be obvious. TP> Not to mention the "minor" problem that several TP> FTN other nets are using the same zone number. _NO_NEED_ for FidoNet to compile an OtherNet's nodelist. The ZC of AnyOtherNet could compile his own nodelist using the keywords SINDEX and either FIDOTXT or FIDOPRN in his XLATLIST.CTL file (or equivalent if using a different nodelist compiler). Take the sorted index at the end of his NODELIST.TXT/NODELIST.PRN file. Example for AlterNet - Dos-command `COPY NODELIST.PRN ANETLIST.PRN'. AnyOtherNet ZC then fires up a text editor. `EDLIN ANETLIST.PRN'. Delete the tedious node-by-node list at the top, & keep the net by net sorted index. Now netmail file-attach the `sorted-index-only' to a volunteer at a `central-clearing-house' serving _ALL_ networks (FidoNet included). At the `central-clearing-house', the volunteer compares the `SINDEX-only' NODELIST.PRN from FidoNet, ANETLIST.PRN from AlterNet, NETLIST.PRN from NETWORK/FamilyNet, RBBSLIST.PRN from RBBS-Net, EGGLIST.PRN from EggNet, etc. Said volunteer looks for `net' number (of /) collisions where 2 or more political networks use the same `net' number. _IMPERATIVE_ that only one network use a `net' number within any FidoNet Geo-Zone - (Easier on mailer software if `net' numbers were only used once world-wide, but not essential.) TP> The only workable solution we could come up with TP> was simply to require that only FidoNet addresses TP> appear in FidoNet mail. See Above. Primary reason for leaving `foreign net' (ie non-FidoNet) addresses in echomail "seen-by" lines is "dupe" control. ANY `circular feed' causes dupes. If a seen-by-stripping internet-echogate is included in an accidental `circular feed', the dupes are spread much farther than a `circular feed' which does not include an echogate in the path. FidoNews 7-05 Page 11 29 Jan 1990 JD = Jack Decker JD> I guess I just don't see the need to put up additional walls JD> between the networks. I think most of us are in this hobby JD> to communicate with each other, not to figure out ways to JD> make communications difficult. This document honestly seems JD> to be moving us in the wrong direction, unless I'm really JD> missing the reason it's needed... TP> We are not trying to make communication more TP> difficult. The fact is, Jack, that communication TP> is virtually impossible (via netmail) to many of TP> the current other networks that are using FidoNet TP> echos. How can we possibly enforce moderator's TP> rules about topical limitations when the option TP> to "take it netmail" doesn't exist in many cases? A periodic (maybe monthly?) list of those FidoNet/AnyOtherNet multi-ID systems which have `AnyOtherNet' nodelists FReqable and which `AnyOtherNet' nodelists are available there. Freq. the desired nodelist from a multi-ID system, then send direct netmail to the desired AnyOtherNet single-ID system. Example: Dual-ID FidoNet 1:151/114 - AlterNet 7:48/2022 has both the AlterNet and NetWork/FamilyNet nodelists available for FReq. even though it is not in Network/FamilyNet. Extract from the list you would get if you FReq'ed `FILES' from 1:151/114 on Jan 23., 1990 : ANETDIFF.A19 2635 AlterNet nodediff - ANETDIFF ANETLIST.019 49242 AlterNet nodelist - ANETLIST FIX1990.LZH 2400 OPUS event bug fix for 1990 NETDIFF.A19 1985 The Family nodediff - FMLYDIFF NETLIST.019 41600 The Family nodelist - FMLYLIST NODEDIFF.A19 37782 FidoNet nodediff - NODEDIFF NODELIST.A19 274718 FidoNet nodelist (PKPAK squashed) - NODELIST TP> I would like to see one standard method agreed TP> upon for internetwork routing. I don't care if TP> it is the RBBS-Net method or the ^ADOMAIN method TP> or something else entirely as long as it works -- both TP> directions. See paragraphs directly above my edited FILES list. -Walter --- ConfMail V4.00 * Origin: TI-RALEIGH 919-833-3412 NCRTP 9986 (1:151/114) FidoNews 7-05 Page 12 29 Jan 1990 Adding to original SYSOP echo message: In addition to the 2-step method of first FReq'ing the desired AnyOtherNet nodelist then sending direct netmail, _REAL_ working zonegates could be set up between the various networks. Back in the days when NETWORK and RBBS-Net were formed, everyone _THOUGHT_ "Zones" _HAD_ to be single-digit numbers causing a false appearance of a shortage of usable zones. Actually only the TABBY package (versions 2.1 and earlier) has the single-digit zone problem. QuickBBS will handle zone numbers 1-255, and BinkleyTerm will handle zones 1-4095 (.001 - .FFF extensions on the separate holding-area for each zone setup). RBBS-Net could switch to a multi-digit zone number thereby eliminating the "2 zone 8s" conflict. Same basic principle applies to any/all other "shared zone" conflicts. ----------------------------------------------------------------- FidoNews 7-05 Page 13 29 Jan 1990 Jack Decker 1:154/9, 11:154/8 A MODERATED ECHOMAIL CONFERENCE PROCESSOR -or- MY TWO BITS' WORTH [continued from last week] AN OPTIONAL ADD-ON TO THE BASIC PROPOSAL Last week I presented the basic proposal for a moderated echomail conference processor. I'd also like to throw out a proposal for an option that would partially emulate one other advantage of GroupMail, namely, that every system that receives a conference gets the same message bundle. Please note that the following discussion applies to message packets that are being sent downbound from the conference moderator's system, NOT to messages that are upbound to the moderator, and that the following is really a separate proposal from the above. The following discussion will be meaningless if moderated conference mail is not implemented, but what follows should be considered an optional add-on to the basic moderated conference mail proposal described above. This add-on will greatly facilitate the handling of pass-thru conferences when implemented as part of any moderated conference mail processor. First, an explanation of the GroupMail feature we're trying to improve upon: Under GroupMail, when a system receives a message bundle for a particular conference, it does NOT unpack and re-toss the bundle before passing it along to any downlinks that receive the conference from that system. Instead, the bundle is passed along unchanged, just as received. So, if the unpacking software "grunges" a message (as often happens when a disk full or similar unexpected condition occurs), it only affects the display of the message on that particular system, and does not affect the condition of the message bundle received at any downstream system. GroupMail does this by building a separate message bundle (and, ultimately, a separate .ARC file) for each and every available conference. The advantage of doing this can be explained if you consider the case where (for example) you feed a large echo to several different systems. With echomail you have to toss the messages separately for each system. Thus, if you receive a 200K packet of FOR-SALE and feed it to five systems, you'll need one meg of free space (5 systems * 200K) just to toss those messages to the five individual systems, plus some additional room to allow the archiver to try and compress those packets. With GroupMail, you'd receive the one 200K packet (in ARCed format) and store it in a holding area, and that one packet would be sent to all five systems. FidoNews 7-05 Page 14 29 Jan 1990 The disadvantage of this scheme is that if all conferences are stored in individual archives, then a system receiving seventy different GroupMail conferences could conceivably receive seventy different archives (one for each conference) every night. As fast as most mailers are, there is still a certain amount of turnaround time required each time a different file is sent, so transmitting a number of small archives instead of one large one increases the connection time required to receive one's nightly echo feeds. Also, each conference archive must be individually named in such a manner as to prevent name collisions, while not using a filename that may have some meaning to a mailer program (e.g. a filename that might appear to be an attach file or a request file or a mail packet). There's also the question of how long to retain each individual message archive. As mentioned above, with echomail you will temporarily create one copy of the messages in any given conference for EACH system receiving the conference (so, if you are feeding an echo to five different systems, you will temporarily have five different copies of the messages in that echo on your system). BUT, as these message packets are sent to the recipient systems, they are automatically deleted from your system. With GroupMail, you only keep one copy of any given set of echo messages, but you have to keep it around until all the systems you've fed the echo to have had a chance to retrieve it from you system. Given that systems sometimes have technical problems that may keep them from connecting on a given night, and sysops sometime go away for weekends (at which point Murphy invariably takes over and crashes their systems), the normal retention time for GroupMail echoes has to be set at 3 to 5 days in order to make sure that no messages are "missed" by any downstream system. So the advantage of only having to store one copy of the messages in a given conference for all the nodes you feed it to is largely negated by the requirement to keep 3-5 days's worth of messages around in order to make sure that none of the systems you feed miss any messages. Finally, when the same message archive is sent to all systems you feed, it must be stored in an archive format that can be uncompressed at all systems being fed. Unfortunately, none of the best archivers are portable across all computing environments found in Fidonet. So the "least common denominator" approach is used (.ARC format archives in the case of GroupMail) which insures that virtually all systems receiving GroupMail packets can unARC them without difficulty, but at a cost of longer transmission times and greater disk space storage requirements than would be necessary if a newer archiver could be used. For these and other reasons, I do not feel that storing each day's worth of messages from a conference in an individual ARCHIVE file is a good idea. However, storing each conference in a separate BUNDLE (that is, a separate .PKT file) which is then packed to each recipient might be an effective way to transmit moderated conference mail. FidoNews 7-05 Page 15 29 Jan 1990 Let's consider how an advanced conference mail processor might handle moderated conferences: 1) An incoming mail ARCHIVE (a .mo?, .tu?, ... .su?) file arrives from another system. 2) The conference mail processor finds this packet, determines which archive format was used to create it (ARC, ZIP, LHARC, ZOO, etc.) and calls the proper de-archiver to decompress the file and recover the individual .PKT files. 3) The header of the .PKT files are examined and if they are a standard .PKT file (as currently used) they are processed in the normal manner (messages are tossed/scanned to/from the appropriate netmail or echomail areas). However, if the header indicates that the incoming .PKT file is a moderated echo conference, it is temporarily moved to a separate directory (actually, placing these files in a separate directory may not be necessary, but it's easier to mentally visualize the process if we separate these files). Please note that each of these new type .PKT files will contain messages from only one moderated conference per .PKT file (for example, if we received feeds of FOR-SALE, TECH, and COMM, we'd get three moderated conference style .PKT files, one for each of the three conferences). Also please note that both types of .PKT files may be intermixed in the same mail archive (this solves the problem of having to transmit multiple files). 4) As the new style .PKT files are moved to the holding area, a temporary index is constructed showing which conference area tag relates to each of the .PKT files (for example, showing that packet 12345678.PKT contains messages for the FOR-SALE echo). Each area tag in the index is then examined and the associated .PKT file may be handled in any of the following ways: If the .PKT file is NOT associated with a passthru area, then the messages in that .PKT file are tossed to the appropriate message areas on your system. If the .PKT file is associated with an area that is fed to other (downstream) systems, then the .PKT file is archived into an outgoing mail ARCHIVE (a .mo?, .tu?, ... .su?) file destined for each of those systems, WITHOUT change. The .PKT file that is received is the .PKT file that goes out. Note that in this case the PATH line in the messages cannot be changed. However, the integrity of the .PKT file is maintained (assuming that no errors were encountered in the process of unarchiving the .PKT file in the first place... obviously, such errors should be trapped). FidoNews 7-05 Page 16 29 Jan 1990 It should be noted here that if a moderated conference is converted to regular echomail, then it MUST be unpacked and a SEEN-BY line must be added to each message, and the system's net/node number must be added to the PATH line of each message. The messages in that conference may then be re-packed as echomail to the conference in question. To do otherwise would defeat the duplicate message security built into this scheme (this would in most cases make the use of the -p and -e switches together on the same AREAS.BBS line invalid, however, I suppose a truly ambitious programmer could figure out a way to adjust the PATH lines in the .PKT files of passthru conferences without first unpacking and tossing the individual messages). 5) Once the individual .PKT files have been tossed to your system and/or archived to other downstream systems that receive them from you, they are deleted immediately (generally in the same scan/toss cycle), and don't hang around taking up space on your system (some software might allow you to optionally override this if for some reason you wanted to keep the .PKT files around for a day or two). One might reasonably ask how a conference mail processor is supposed to know that a .PKT file contains a moderated echo conference, and how to determine the area tag. Please consider the header of a typical .PKT file: PktHType = Record OrigNode : integer; DestNode : integer; Year : integer; Month : integer; Day : integer; Hour : integer; Minute : integer; Second : integer; DestBaud : integer; PktVers : integer; OrigNet : integer; Destnet : integer; Product : char; filler : char; PwdKludge : Array[1..8] of char; filler : Array[1..24] of char; end; Since the baud rate of the destination system is a totally useless piece of information in an echomail header packet (and since virtually all systems get this information from someplace other than the packet header anyway), I propose that we utilize one byte of this integer as a "signature byte" which will indicate to a conference mail processor that this is a moderated echomail packet. No true modem baud rate currently in use is an odd value (I think we can safely ignore the oddities such as 1200/75 splits used by commercial videotex services in some countries), therefore, bit 0 of the least FidoNews 7-05 Page 17 29 Jan 1990 significant bit of the least significant byte will never be set if this field really contains a modem value. I therefore propose the field be redefined as follows for moderated conference mail: Instead of: DestBaud : integer; We'd use: EchoPktFlag : Char; SerialNo : Char; Where the echo packet type would be defined as follows: Bit 0 1 if moderated conference mail, 0 otherwise Bits 7-6 Reserved for future use Again, the implication is that if bit 0 is not set, the packet is a normal mail packet containing regular netmail or regular echomail (or both). If bit 1 IS set, the packet contains ONLY moderated conference mail which meets the following criteria: 1) The packet is exactly as it was when it left the moderator's system (the .PKT file is totally unmodified except for being unpacked and repacked) and, 2) The packet contains moderated echomail that is downbound from the moderator ONLY and, 3) ALL messages in the area are for the SAME conference and have the exact same AREA tag (the conference mail processor will normally only read the first AREA tag of the first message). If the moderated conference .PKT file is changed in ANY way, then the system making the change must reset bit 0 of the EchoPktFlag (in effect changing the packet to a normal echomail PACKET, although the messages contained therein would still be flagged as part of a moderated conference) AND the system must add its address to the PATH line of each message in the packet. You will note that I have suggested a redefinition of the second byte of the Destination Baud integer as a Serial Number byte. This would simply be a byte value that is incremented at the moderators' system each time a new message packet is issued (with rollover from 255 to 0). In this manner the recipient of a conference area could, if he so desired, keep track of this value and thereby be alerted to any interruptions or missing packets in the echo feed. Actually, if I could be sure that the 24 bytes of filler in the .PKT file header were not being used by anyone, I would suggest that this information could go in there, rather than usurping the DestBaud integer. Were that to happen, I'd prefer to see a two-byte value for the serial number, and also a 32-bit CRC value calculated on the portion of the .PKT file following the header (e.g., starting with the first byte of the first message header) to insure the integrity of the .PKT file. FidoNews 7-05 Page 18 29 Jan 1990 It should be obvious, as you read the above, that a new style moderated conference .PKT file would be completely compatible with virtually all currently existing mail processors. These processors would simply treat such packets as they would any other bundle of incoming echomail. In fact, the ONLY reason that such packets would need to be unpacked before sending to a system that is only capable of handling regular echomail is so that the required SEEN-BY line can be added, and the PATH line updated, in order to protect against duplicate message generation. It should be noted that when the -m switch is used in the AREAS.BBS file, a conference mail processor that supports this optional add-on to the basic moderated conference mail scheme should toss mail to the appropriate conference area as it is received, but NOT scan (export) it unless a specific switch is used on the command line when the mail processor is invoked. Normally you'd have a once-daily event that would invoke the processor with that switch, in order to scan and export messages from any areas that you moderate, followed IMMEDIATELY by a call to whatever you use to renumber and clean up that message area. It would not normally be a good idea to automatically delete messages from the conferences you moderate at any time other than immediately after the daily message export from that area (this would prevent messages arriving after the export event but before the cleanup event from being deleted before they can go out). And, of course, the moderated conference mail processor would have to build the .PKT files for each conference according to the specifications mentioned above. One potential problem exists at this point, and that is the possibility of creating duplicate .PKT file names. Consider that many conference moderators might decide to run their once-daily export events at about the same time (just after midnight, for example) and therefore a .PKT file naming scheme based solely on time just might produce packets for different conference areas with the same filenames. It would therefore seem wise to at least try and avoid the potential for duplicate filenames by using a .PKT file naming scheme that is not based solely on the time of day. The root portion of a .PKT filename may contain any valid hexadecimal character (0-9 or A-F). Therefore, one possible scheme might be to use a four character checksum of the conference name plus some time dependent information. For example, the following scheme might create adequately unique filenames: Mail packet filename format: cccctttt.PKT FidoNews 7-05 Page 19 29 Jan 1990 .....where cccc is a 32 bit checksum of the conference area tag, and tttt is the number of seconds past the start of the month (at the time the .PKT file is created) expressed in hexadecimal format. No .PKT file naming scheme can GUARANTEE unique filenames for conferences created on different systems, so it would be best if the moderated conference mail packer could check existing mail archives for duplicate filenames before adding a new .PKT file (I realize this may be difficult to do, however, given the number of different archiving programs in common use today). If such a check were made, renaming of .PKT files to avoid name collisions WOULD be permissible. Yet another possibility would be to use a base 36 character set (0-9 or A-Z), or perhaps better yet, a base 20 character set (the letters G-Z ONLY, to positively avoid conflicts with .PKT filenames created by existing mail packers) for the root part of moderated conference mail .PKT filenames, and base these on some sort of random numbering scheme. To some extent, the preferred method of avoiding .PKT file name collisions should be left to the software authors, but the (admittedly small) potential for difficulty should not be ignored. POLITICAL CONSIDERATIONS The above about covers the technical end of this proposal. Alas, there are the political considerations to contend with. I propose the following as sort of a Policy Statement in regard to moderated echomail: 1) Anyone who converts moderated echomail to regular echomail may do so without prior permission to feed leaf nodes (nodes that do not further distribute the conference further) ONLY. If a node receiving a converted echomail feed wishes to pass that feed along to other nodes, the conference moderator's permission is required. In any event, the node that converts moderated echomail to regular echomail is responsible for knowing which systems are receiving the conference via his system (either directly or indirectly) and for making sure that "dupe loops" are not created. 2) It should be considered a serious violation of policy to feed moderated echomail conferences to a node capable of processing only regular echomail without inserting the required SEEN-BY and PATH lines (put another way, within an AREAS.BBS file the -d switch must NOT be used to feed a node that is not running a "moderated conference mail aware" echomail processor. The -e switch MUST be used instead). 3) As long as moderated echomail is distributed as moderated echomail, (not converted to regular echomail), the propagation of duplicate messages is nearly impossible. Therefore, there is no reason that the distribution of moderated echomail conferences needs to be restricted by anything other than least-cost routing considerations (that is, geographic restrictions are not really appropriate for conferences in FidoNews 7-05 Page 20 29 Jan 1990 which duplicate messages cannot easily be propagated). 4) IF the new packet type as described above (with the header bit indicating that the packet is moderated echomail) is used, then it shall NOT be a requirement that the uplink and downlink paths between any particular system and the moderator's system be the same; however, if a conference is made available on a BBS, then an uplink path for replies MUST be provided. The intent of this provision is to allow specific conferences, or groups of conferences, to be distributed via one-way channels (e.g. radio or satellite feeds) to reduce the costs for those wishing to receive the conference. However, if an uplink path back to the moderator's system were not provided, users of a BBS might wrongly assume that they could leave messages that would be seen by all participants of the conference. Thus, the requirement that an uplink path for replies must be made available. The moderator of a conference may waive this requirement (although doing so is not recommended except in the case of "read-only" conferences). 5) Complaints that moderated echomail equals censorship are really not valid. Consider that Fidonet echomail is one of the few mediums in which folks seem to think they should be able to say anything they doggone well please. Most sysops would not allow users to post just anything that they might want to say in any conference they feel like saying it in, yet some of these same sysops will be the first to complain about anyone who tries to implement some effective moderation in echomail. This proposal addresses that concern by insuring that echomail processors will be able to handle BOTH types of echomail (both moderated and unmoderated) as easily as regular echomail is now run. So it would not be an either/or choice for sysops and echomail hub operators whether to run moderated or unmoderated echomail. Right now we have echomail hubs that offer only echomail conferences and GroupMail hubs that offer only GroupMail conferences, but with software designed to be compliant with this proposal, all hubs would be able to handle both types of conferences. Thus, it would be strictly up to the moderator of a conference as to whether that conference should be moderated or unmoderated. In the case of conferences that have been on the backbone for a long time, many would undoubtedly remain as regular (unmoderated) echomail conferences. But for new conferences, shouldn't it be the moderator's option as to how closely he wishes to moderate a conference? After all, no one will force anybody to join a conference that they feel is too tightly moderated. CLOSING COMMENTS I think that about covers everything. If you feel this proposal is missing something, please drop me a note at 154/8 or if that won't work for you, you can send it to 1:154/9. You can also leave comments in the NET_DEV echo but keep in mind that echomail currently isn't always as reliable as netmail, and occasionally my feed of NET_DEV does seem to be interrupted FidoNews 7-05 Page 21 29 Jan 1990 for various reasons (technical, not political!). One question that I have left open (mostly because I don't really want this proposal to get mired in political concerns) is whether some mechanism should be included for routing private netmail replies to echomail back up to the sender of the original message via the same path that the original message came down? I wouldn't mind seeing such a mechanism included, but it would require some changes to the above proposal and worse, it might make the whole proposal politically unacceptable in Fidonet (besides that, I think there are better ways to devise a netmail routing scheme for Fidonet, should we ever have the collective will to do so. See my article in Fidonews 7-01 if you'd like my thoughts on a netmail routing scheme). I will probably send this proposal up to the Fidonet Technical Standards Committee in a week or two, but I reserve the right to make revisions first, based on any comments I may receive from readers of these articles. Your constructive comments are welcome. ----------------------------------------------------------------- FidoNews 7-05 Page 22 29 Jan 1990 A Reply to Mr. Riddle Phil Root NC 285 285/0, 285/17 Having been forwarded a copy of Mr. Riddle's article on the Proposed Gateway Policy Document, I'd like to mention a short rebuttal. I feel that some of the 'facts' that he puts forth could use some clarification, and perhaps, I can point out some errors in his logic. Point 1: Mr. Riddle says that the major issue facing Fidonet is that of direction. I feel that he is wrong. He states the real issues are how the current coordinators acceded to their positions, how they remain there, the management and personal attitudes they represent.... I think that this indicates that the proposed Gateway Policy Document has absolutely nothing to do with his dissatisfaction. It wouldn't matter at all if it was an absolutely PERFECT document, (which it isn't, but that's a different matter), the point that he makes is that since it was proposed by the *c structure, and individual sysops were not "consulted", etc. that it is somehow flawed. I find this logic to be somewhat contorted. Point 2: Mr. Riddle is mistaken in his assumption that POLICY 4 mandated membership in the local net. It doesn't. It does, however, grant to the International, Zone, Regional and Network coordinators the ability to manage the nodelist for the greatest effeciency. In this case, the Regional coordinator saw that there was an existing net in the Omaha calling area. There were also 6 independent nodes in that area. Attempts to convince those nodes to come into the net voluntarily had failed, and under mandate from the Zone coordinator, the RC instructed that those members were to be included in the Network nodelist. In the same paragraph, there was another indication and reference to an internal network dispute that needs no further clarification here. Point 3: In paragrph 3 of Mr. Riddle's comments, he states that the *C's proposed internet gateway policy document was created in an atmosphere of "narrow-minded and short-sighted, arguably ego- tripping conduct". Such comments are really counterproductive. A lot of work and thought went into the creation of this document. Point 4: There as never been any real proof that the vote was flawed, and no one complained as long as the vote was going to their liking. Further, Mr. Riddle offers no proof that the vote was flawed. If the Board of Directors of a SEPARATE organization decides to put a resolution to the sysops, and a majority of them decide to ignore it, then I find nothing flawed in it, except that it did not turn out to Mr. Riddle's advantage. FidoNews 7-05 Page 23 29 Jan 1990 Point 5: I'm not going to comment on the debate excerpts the Mr. Riddle chooses to publish. I think that they show even further that his comments actually have very little to do with the viability or non-viability of the Internet Gateway Document. What we have here is another 'Fidonet sysop' complaining about the age old complaint, "that we have no say". This is hogwash. There is a complaint and appeal process clearly written into POLICY 4. If a *C at almost any level refuses to listen, there is ALWAYS the opportunity to go to the next higher level. Mr. Riddle has the opportunity of seeking membership in another network if he chooses. I should note that he is not even a full Fidonet node, but a point off of 285/666. Not that this diminishes his right to comment, and yes, I DID invite this comment. However, I must confess, I had hoped for some constructive criticism of the Gateway document, not a diatrabe on the *c structure, and its supposed evils. People were clamoring for democracy. They 'DEMANDED' that the sysops be given a choice on matter. Yet, when the sysops were given a choice, we saw the result. Most of the sysops did not even bother to cast their ballots. We've seen that democracy CAN work. However, it won't work in Fidonet without participation by the sysops, any better than it works anywhere else without the participation of the electorate. ----------------------------------------------------------------- FidoNews 7-05 Page 24 29 Jan 1990 Regional Netmail Routing -------- ------- ------- (Published For the Zone 1 Coordinator and RCs by 1:286/703.) The Zone 1 Coordinator and the Zone 1 Regional Coordinators would like to announce the creation of what we hope will be a helpful service to the sysops in FidoNet Zone 1. The service is not new to FidoNet but is new to Zone 1. In a significant number of cases, it really shouldn't matter if a netmail message is delivered in 5 minutes or 5 days. The Z1C connects with each Zone 1 RC and with the Zone 2/3/4/5 zonegate nightly. The Zone 1 RC's connect with each of their NC's at least twice each week on FidoNews and Nodediff nights. These already established connections could easily be utilized to offer routing services for low priority netmail addressed to any FidoNet destination. That is precisely what we've done. Although this is currently labeled a "pilot project", we can currently forsee no reason why it could not be implemented permanently. FidoNet sysops in Zone 1 may feel free to route any low priority netmail to any FidoNet Z1RC or to the Z1C. You should understand that "low priority" means that you don't care if it takes up to 5 or 6 days for the message to arrive at its ultimate destination. The transfer from RC to ZC to RC (or to zonegate) would take place fairly rapidly. However, the speed with which the message is delivered to the NC will vary from region to region based upon how often RC connects with the NC (i.e. Friday & Monday for Nodediff's and FidoNews or until the NC and RC connect for some other purpose). NC's are invited to participate in this plan and provide outbound low priority netmail routing (via the RC). NC's please understand we said "invite" not "insist". That decision us up to you and your network sysops. Zone 1, feel free to use or ignore this offer as you please. We hope that this plan will, as but one example, provide echomail users with an incentive to take message threads that stray off topic "to netmail". Yes, we could be deluged with so much traffic that our collective pocketbooks could not bear the strain. However, we prefer to trust the sysops of FidoNet and their users to use this service judiciously and responsibly. The regional routing plan is, to be sure, not mandated by Policy. It was simply something that seemed to make sense and has been voluntarily implemented. We hope that this proposal will be received in the spirit in which it is offered. That being a sincere effort to provide a service we feel we can afford to those we serve. If it doesn't work out we are surely no worse off than we are today. If it does, perhaps we can say we brought netmail "out of the closet" and made it widely available to the sysops and (more significantly to the) users in Zone 1. FidoNews 7-05 Page 25 29 Jan 1990 Questions and comments may be directed to the Zone 1 Coordinator or to any of the Zone 1 Regional Coordinators. ----------------------------------------------------------------- FidoNews 7-05 Page 26 29 Jan 1990 By Bill Weinel 1:151/121.0 @ FidoNet SCSI SYSTEM ONE: A SYSOP'S SCSI SYSTEM SCSI System One: The History ---------------------------- One of the most frustrating problems I have found since switching my BBS system over to a PC based computer is the PC's inherent inability to deal with large HD storage spaces. (While this problem has been remedied to some degree with the advent of DOS 4.x, the hardware problem of multiple hard drive storage on a single PC still exists.) This article is the story of some folks who decided that "enough was enough" and did something about it. About a year back, I became an SDS node and found myself facing the situation of needing more hard drive storage on my system. Not being the kind of person who could afford to go out an plunk down $6000 for a brand new super-duper-800-megabyte-12- millisecond-Super-Seeker hard drive, I decided that it was time to start looking for some other reasonable way to break the 2 hard drive barrier on the PC. I quickly found that I wasn't alone in my quest. A handful of other local sysops had been faced with this same problem too. Enter Jeff Lengel. Jeff is a local computer consultant, hardware engineer, software hacker, and long time friend. We started discussing the problem last January and decided that there was just no good system available to fill the need for multiple hard drive storage at the time. We had pretty much decided that SCSI was the route to go, but at that time commercial SCSI systems for PCs were few, and those that were affordable for sysops on our budget were basically non-existant. Jeff said that he had seen some good prices on SCSI hardware available through some mail order vendors and that it should be possible to put together a software package to make it all fly. None of us knew it at the time, but SCSI System One was born right there. Needless to say, Jeff found that writing the SCSI driver code was a bit more than a trivial task. He started out in assembler, but the code eventually out grew his ability to manage it. So he converted all utilities over to C, leaving the driver in assembler for speed. As time went by, Jeff got the basic driver code finished. This allowed him to start testing the SCSI controller hardware. By June, he had a working SCSI driver which would allow the PC to talk to the SCSI devices through a host adaptor card. Once the driver was working correctly, he started to refine it to work with various multi-tasking and BBS packages. He also added the ability to use bridge controllers to the system. This opened up the door for getting all those old retired ST506 type drives out of the closet and back online again. FidoNews 7-05 Page 27 29 Jan 1990 This is the point where my job started... Jeff needed a few beta testers (guinea pigs?) to iron out the remaining flaws in the driver. And of course there was that burning question that still needed to be answered: "Would the SCSI driver really run reliably with all that mailer/BBS software loaded on top of it?" I volunteered to test it under DOS 3.3 while Mike Stroud (1:151/102.0) volunteered to test it under DOS 4.x. Between the two of us, we managed to thrash it pretty well. This helped Jeff work out the few remaining kinks in the driver. "So where are we today?", you ask. Well, today we have five systems in net 151 now running a Scsi System One on a day-to-day basis. Jeff has continued to improve the SCSI drivers transfer rate and support for as many bridge adapters as he can possibly find. At the same time, he has managed to develop a 150 megabyte automatic streaming SCSI tape backup system. This addition to the his base system is a real sysops dream! It can be left to run unattended in the wee hours of the morning through use of an errorlevel exit and will automatically preform incremental backups of your system while you sleep. It can backup a 100 megabyte drive in file-by-file mode in about 16 minutes and can be tailored, through use of a CFG file, to backup individual files, subdirectories, or complete drives. Jeff's also working on adding disk mirroring and a LAN link package for a future release. It's really hard to believe that just about a year ago this was all a pipe dream floating around in the heads of a few local folks. Today, thanks to a little hard work and extremely patient wives, it's a reality. That just goes to show that a little collaboration between sysops can go a long way! SCSI System One: The Specs -------------------------- -Meets ANSI X3T9.2 specifications -Asynchronous interface up to 1.5 megabytes per second -Supports full parity generation and checking -Supports full SCSI arbitration and checking options -Supports linked commands -Supports bridge controllers -Supports logical units -Direct SCSI bus drivers -Host interface: PC, XT, AT, 80386, true compatible (*) . SCSI address 330h-337h . DMA channel 3 -Supports DMA or PIO transfer -Supports up to 7 physical drives (14 on bridge controllers) -Supports up to 24 logical drives (total) -Supports up to 536 megabytes per logical drive 3n3 FidoNews 7-05 Page 28 29 Jan 1990 -Supports complete compatibility between XT and AT bus types -Compatible with Norton Advanced utilities Ver. 4.5 and Fasttrax disk optimizer (*) max bus speed 8 Mhz. The system consists of one host adaptor card (half sized card), partitioning/low-level formatting software and SCSI device driver. A three foot SCSI interface cable is included. It requires at least DOS 3.2 or higher. Jeff has agreed that in an effort to aid the growth of the 'BBS Network' he will offer the SCSI System One host adapted system to net sysops at a special rate. For more details on the sysop offer, contact Jeff Lengel at the address below. SCSI System One 1013 Ivy Lane Cary NC 27511 USA 919-469-9750 Full information may be file requested by requesting SCSIONE from 1:151/121.0 anytime other than ZMH. ----------------------------------------------------------------- FidoNews 7-05 Page 29 29 Jan 1990 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions MS-DOS Systems -------------- Bulletin Board Software Name Version Name Version Name Version Fido 12q+ Phoenix 1.3 TBBS 2.1 Lynx 1.30 QuickBBS 2.61* TComm/TCommNet 3.4 Kitten 2.16 RBBS 17.2B TPBoard 6.0 Opus 1.03b+ RBBSmail 17.2 Wildcat! 2.10* TAG 2.5d1* Network Node List Other Mailers Version Utilities Version Utilities Version BinkleyTerm 2.30 EditNL 4.00 ARC 6.02 D'Bridge 1.30* MakeNL 2.20 ARCA06 2.20* Dutchie 2.90C ParseList 1.30 ARCmail 2.0 FrontDoor 1.99b* Prune 1.40 ConfMail 4.00 PRENM 1.47 SysNL 3.01* EMM 2.02 SEAdog 4.51b XlatList 2.90 Gmail 2.01 XlaxDiff 2.32 GROUP 2.16 XlaxNode 2.32 GUS 1.30* LHARC 1.13 MSG 4.0 MSGED 1.99 PK[UN]ZIP 1.02* QM 1.0 QSORT 4.03 StarLink 1.01 TCOMMail 2.2 TMail 1.12 TPBNetEd 3.2 TosScan 1.00* UFGATE 1.03 XRS 3.10 ZmailQ 1.10* Macintosh --------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version FidoNews 7-05 Page 30 29 Jan 1990 Red Ryder Host v2.1b4 Tabby 2.1 MacArc 0.04 Mansion 7.15 Copernicus 1.0d* ArcMac 1.3 WWIV (Mac) 3.0 StuffIt 1.51 TImport 1.331 TExport 1.32 Timestamp 1.6 Tset 1.3 Import 2.52 Export 2.54 Sundial 2.1 UNZIP 1.01* Amiga ----- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Paragon 2.00+* BinkleyTerm 1.00 AmigArc 0.23 TrapDoor 1.11 booz 1.01 WelMat 0.35* ConfMail 1.10 ChameleonEdit 0.10 Lharc 1.00* ParseLst 1.30 PkAX 1.00 PK[UN]ZIP 1.01* RMB 1.30 UNzip 0.86 Zoo 2.00 Atari ST -------- Bulletin Board Software Network Mailer Other Utilities Name Version Name Version Name Version FIDOdoor/ST 1.5c* BinkleyTerm 1.03g3 ConfMail 1.00 Pandora BBS 2.41c The BOX 1.20 ParseList 1.30 QuickBBS/ST 0.40 ARC 6.02* GS Point 0.61 LHARC 0.51 PKUNZIP 1.10 MSGED 1.96S SRENUM 6.2 Trenum 0.10 OMMM 1.40 + Netmail capable (does not require additional mailer software) * Recently changed FidoNews 7-05 Page 31 29 Jan 1990 Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 7-05 Page 32 29 Jan 1990 ================================================================= NOTICES ================================================================= Glen Johnson, 1:269/101 Announcing the DRUM_CORPS echo ------------------------------ DRUM_CORPS is an echo for chewing the rag about competitive drum & bugle corps, marching bands, and Winter color guards. It's on the backbone via the Eastern Star and is moderated by yours truly. If you've ever played in a drum corps, college band, high school marching band, or marched in a Winter color guard, this is the place for you! I've had a great deal of experience in drum corps over the years, having taught them, played with them, run them, and been a spectator too. And we're looking for other with similar experience and interests. During the competition season, we'll have scores & schedules and general BS from other drum corps freaks around the country. So ask your NEC to pick up DRUM_CORPS and join us! Glen Johnson 1:269/101 ----------------------------------------------------------------- The Interrupt Stack 9 Feb 1990 Jack Porter's Birthday. Send greetings to him at 1:205/69. 5 Jun 1990 David Dodell's 33rd Birthday 1 Aug 1990 Start of FidoCon '90. Contact Bill Vanglahn at 1:1/90 for details. 5 Oct 1990 21st Anniversary of "Monty Python's Flying Circus" If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. -----------------------------------------------------------------