F I D O N E W S -- Volume 14, Number 6 10 February 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. | +----------------------------------------------------------------------+ WHERE WERE YOU ON THIS DAY IN HISTORY? Table of Contents 1. EDITORIAL ................................................ 1 Flacking the hack? WebRing is back! ...................... 1 2. GUEST EDITORIAL .......................................... 2 Almost a New Beginning! .................................. 2 3. ARTICLES ................................................. 6 Zone 2 nodelist flags .................................... 6 A reply to "Fidonews, The "lard ass" of newsletters" ..... 12 A simple rebuttal ........................................ 13 4. GETTING TECHNICAL ........................................ 16 FSC-0034 - Gateways to and from FidoNet .................. 16 FSC-0035 - Transparent Gateways to and from FidoNet ...... 22 FSC-0036 - Group Mail Specifications ..................... 24 5. COORDINATORS CORNER ...................................... 30 Nodelist-statistics as seen from Zone-2 for day 038 ...... 30 6. NET HUMOR ................................................ 31 Why did the chicken cross the road? ...................... 31 7. NOTICES .................................................. 35 Future History ........................................... 35 8. FIDONET SOFTWARE LISTING ................................. 37 Latest Greatest Software Versions ........................ 37 9. FIDONEWS PUBLIC-KEY ...................................... 44 FidoNews PGP public-key listing .......................... 44 10. FIDONET BY INTERNET ..................................... 45 11. FIDONEWS INFORMATION .................................... 47 FIDONEWS 14-06 Page 1 10 Feb 1997 ================================================================= EDITORIAL ================================================================= Some people believe that disagreement is personal. I've never understood that but I do acknowledge the trait exists in some folks. There isn't anything personal in my observations from FidoNews 1405 regarding the substance of Gary Gilmore's 'lard ass' article in that Issue. His opinion was aired without fail and without editing. If it were personal, here, would it have been published? His article and my response are part of the public record. If he finds that unfair, that's his problem. Isn't it? The readers can decide between the views and send in their own articles. While he was railing against the size of FidoNews, I never mentioned his own contribution to the size of the Nodelist with 5 separate entries for the same telephone number. Now, that might have been considered personal, too, but it would just have been a fact like the other points I made. [grin] Facts are not personal. FidoNews IS for communicating and he is doing it again in this Issue. More power to him! He is completely incorrect about it being personal at this end. Could he be projecting? Nah. We disagree. No big deal. No insults - thinly or thickly veiled. I do get the last word in a sense but that, too, is transitory until the next Issue comes out. Them's the breaks in the real world. I'd like to remind everyone that there is an official FidoNews Echo for discussion of FidoNews ops and articles. It is available on the Zone 1 Backbone as FIDONEWS and also gets around to other Zones last I heard. There you can get some nearly real-time responses rather than this 1-2 week lag in the published FidoNews. It has no size constraints, either. Meanwhile, the motto in the banner sez it all. [chuckle] In other news, there is a Guest Editorial in this Issue. It was received via the U.S. Mail from a former FidoNet Sysop who still follows the doings of FidoNet but has an ongoing problem with local Coordinators and does not have a Node number at present. It speaks for itself. Any responses will be received by the author when he reads the FidoNews containing them. It's a LONG one by Editorial standards. I hope that doesn't cause any apoplexy out there. We publish what we get the way we get it. The WebRing [www.webring.org] is finally back on the new server and everyone who has been sending me mail asking about not being able to get an answer may now proceed to sign up their FidoNet-related web pages again. There are currently 5 sites connected to the ring and it's ready for the rest of you. [See 1402 for details.] C.B. ----------------------------------------------------------------- FIDONEWS 14-06 Page 2 10 Feb 1997 ================================================================= GUEST EDITORIAL ================================================================= Almost A New Beginning! by: V.H.(Clay) Tannacore On June the 5th, 1989, "A New Beginning" should have begun. It didn't! Why? What went wrong? Why didn't this "New Beginning" resolve the dilemma it was designed to? Last, but not least, Why hasn't there been a New, New Beginning? Some of these answers may never be resolved. Some are discussed by members of the origination in question. Some . . . Well, no one wants to address them, leastwise not in any open forum. Especially, not where the dreaded "C-Monsters" could overhear them. What am I babbling about? Come on folks, you know! FidoNet and The Policy 4 Document. Who are the "C-Monsters?" None other then those big, bad Regional Coordinators, Network Coordinators, Zone Coordinators, and assuredly that (now missing) International Coordinator. Those who inhabit the upper echelons of FidoNet. The same "C" structure that for reasons only familiar to themselves, keep this prehistoric epitaph alive, and in force. This opprobrious document that system operators (SysOps) around the world are told to operate by. This uncomplicated/complicated instrument with its "guidance" pertaining to the operation of FidoNet, and all FidoNets subordinate followers. This same instrument which leaves relatively everything up for grabs, with one exception. The one exclusion being how the "C" structure (aka-C-Monsters) is; 1) appointed 2) elected 3) to perform their duties 4) to delegate authority 5) to (attempt) operate his/her Net, Region, Zone etc. etc. The "guidance" given in the Policy 4 document to individual Network Coordinators, Regional Coordinators, and Zone Coordinators, with very few exceptions is so utterly vague and inadequate it may as well be nonexistent. But I'm getting a little ahead of myself, here. Allow me to continue with (my opinion of) what is wrong with the present day FidoNet policies and operations. Continuing right along, and in the same otiose manner. Let us examine the duties of the Regional Coordinator as per the Policy 4 document. In Section 1.2.4 (Region and Regional Coordinators) of this superannuated document, there is a total of 102 words. The first 41 words explain *what* a Regional Coordinator is. The next 53 words (and I'm being generous here) detail (grimace) the duties of the Regional Coordinator(s). Following this VERY lengthy in depth job description are another 8 words. These words inform all that the RC is "appointed" by the Zone Coordinator. Now, according to Policy 4, Section 1.2.4, The Regional Coordinator has one (and only one) duty to perform, and that is, and I quote; "maintains the list of independent nodes in the region and accepts nodelists from the Network Coordinators in the region. These are compiled to create a regional nodelist, which is then sent to the Zone Coordinator." Unquote! WOW!! Doesn't that sound like a grueling job description to you? Of course we all know that what is described in the Policy 4 document is but a fraction of what an RC is expected to do, and on a daily basis, FIDONEWS 14-06 Page 3 10 Feb 1997 at that. Why then does not this (Policy 4) document explain just what is expected of the RC, and how this is to be accomplished? Sure, give as much leeway to the person as possible, but by all means "guide" him/her in accepted procedures so to avoid a multitude of different methods of operations from network to network. In one word "STANDARDIZE" FidoNet, so as to insure a harmonious environment. As I have pointed out above. There are *no* real formal instructions to assist anyone in comprehending just what is expected of them, except to inform them that a *nodelist* must be compiled. HELLO!! I bet you didn't know it, but by far the greatest magnitude of the SysOps within the FidoNet organization already knew that... Perhaps back in 1988 and 1989 (when this hideous document was formulated) the composers of Policy 4 felt that the education level of brother members were substandard, or something. I don't know, personally. All I can remember of that time period is the contemptible power struggle that was prevalent within FidoNet. Not to say that the *power hungry* are not still a part of this great organization (FidoNet) but to some degree have been restrained in achievement of their goals. Which I consider a *PLUS* for this confederation of ours. Now that you have endured all my maunder, and haven't as yet called for my lynching. I assume one of two things; 1) you may think I have something here, or 2) you are in the process of trying to contact "Doctor Jack" to see if he makes house calls in South Carolina. Rest easy, what Dr. Jack can't do. The Veterans Administration (VA) Medical Center (aka-Hospital) will. However, before that time arrives, or before some technical computer type figures out how to send a nuclear fission apparatus via NetMail. Let me pass on a few (of my) suggestions I have that may possibly be plausible ideas for the betterment of FidoNet, and everyone involved. First, and foremost, we (meaning you SysOps, and members of FidoNet) need desperately to assemble a team of members, who can recast (rewrite) the Policy 4 Document, in order to bring it up to present day standards, taking into consideration the technology at our disposal. Second, and almost as significant, clear cut directions and procedures *must* be established within the New Policy 4 (or whatever it is called) document. Guide lines must be set for Regional Coordinators(Network Coordinators are addressed in a forthcoming summary) in order for the orderly operation (day to day) of FidoNet in every area of the globe where FidoNet is active. Third, (and here a lot of discretion must be employed) Regional Coordinators must be made aware that the *users* (without who FidoNet is doomed) must have a way of asserting his/her opinions, as well as having a way of voicing their grievances directly to the RC, without fear of retribution from a local Network Coordinator. Fourth, (again discretion and even sophistication must be stressed) the Regional Coordinators must *oversee* (without over-overseeing)and supervise their Network Coordinators (bearing in mind the voluntary nature of the FidoNet NC) so that a well organized, and smooth flowing Net is the end result. FIDONEWS 14-06 Page 4 10 Feb 1997 Fifth suggestion (and a pet peeve of mine) is for the Regional Coordinator(s) to adopt an intelligent formatting scheme for EchoMail messages. Presently no such system is in effect, and the EchoMail message bases are in total tumult, with very few exceptions. Text lines are *quoted* by the dozens, even *quoted text* is *quoted* by the (mis)user leaving a message that started out at 2Kb of text, with the robust size of a Shareware Program (just a tiny bit of misrepresentation, here) ready for use on a PC. Even the blank lines of text are being *quoted* adding to the size of the message. Why individual SysOps haven't taken steps to stop this misuse, I'll never know. This practice does nothing but cost money, time, and space, not to mention the offensive looking messages echoed over 300 or 400 different systems throughout the FidoNet areas. Sixth (getting tired yet?) suggestion is a simple one. As every SysOp in FidoNet knows, The Internet has lured many, many users from their local bulletin boards. The Internet with all its modernistic lingo, with enticing graphics, E-Mail, and Faxing capability etc. etc. Its world wide (WEB) accessibility, its . . . Hey! . .wait on darn minute. Isn't this just what FidoNet was supposed to be? Isn't this *just* what FidoNet *is*??? Oh, maybe not all the goodies like graphics, and Faxing, etc, but still a great place to communicate, and for free(?). Seventh, and last suggestion for this conclave, okay? The *free* assertion above isn't entirely accurate, anymore. There seems to be a growing fascination with *Pay For Use* bulletin boards. I suppose this is the SysOp way of entering into competition with The Internet. But, in reality all that is being accomplished is degradation of FidoNet along with the principles and ideals it was founded on. How can anyone expect a user to understand that he/she has to *donate*, *help support*, or *become a member* of a bulletin board, in order to read/write mail or upload/download a file. Gee, isn't this just what he/she has heard about The Internet? He/She was under the impression that a local bulletin board was there as a *hobby* and was free of *service charges*. He/She thought *hobby* was "something a person likes to do in his/her spare time," just like Mr. Webster explains it in his dictionary. I know administering to a bulletin board (BBS) isn't cheap, not by a long shot, but it is a *hobby*, and should be operated that way. I started running my first BBS, on an Atari 800, in 1978, so trust me when I say *I know about operating costs* first hand. It wasn't until 1984 that I got into the IBM and FidoNet business, and even then money was considered a collectors item, to me. Granted, after your initial costs, the rest was kind of inexpensive, unless you wanted a *BIG* 40Meg Hard Drive, with a price tag of $400-500.00. But at no time did I, or anyone else in the Net (with the exception of the then NC) ever even think about charging a user a fee. No one except the *software pirates* who kept copyrighted software available for download on their system, for their *paying* members. Hmmm! Could that be the reason so many systems operate on a *Pay Per Use* basis? As promised, no more *suggestions* or *criticisms*. I'll let a sleeping (puppy) dog lie, for the time being. However, I hope what I have written will incite others to do the same. Voices *have* to be raised if anything is to be done, and rest assured, something has to be done. FidoNet is in danger of a slow death, unless suitable action FIDONEWS 14-06 Page 5 10 Feb 1997 is instituted, and extremely soon. The people who are really involved with FidoNet, and who genuinely care about its existence in the future will stand up and let their viewpoints be known. This has to be a combined effort if reconstruction is to take place. If by chance this article is published in FidoNet and you find it creditable. I implore you to let the editor (Christopher Baker 1:18/14) know. Voice your own opinions and suggestions pertaining to the inadequacies of the Policy 4 Document. If you think *making waves* is frowned upon within the FidoNet structure, you have been misinformed. On the off chance your reflection is correct, then more then ever *CHANGE* is a necessity, and PDQ. ----------------------------------------------------------------- FIDONEWS 14-06 Page 6 10 Feb 1997 ================================================================= ARTICLES ================================================================= Zone 2 nodelist flags Frank Ellermann, 2:240/5815.1 This article 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 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) FIDONEWS 14-06 Page 7 10 Feb 1997 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 predecesssor 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 only one 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. 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. 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 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 FIDONEWS 14-06 Page 8 10 Feb 1997 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: ...,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 developpers an upper limit of e.g. 255 characters for a nodelist line and 63 characters for fields 3 to 6 would be more FIDONEWS 14-06 Page 9 10 Feb 1997 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 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 FIDONEWS 14-06 Page 10 10 Feb 1997 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) -> 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: 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 FIDONEWS 14-06 Page 11 10 Feb 1997 -> V110H => ISDN -> V120L => ISDN -> V120H => ISDN -> X75 => ISDN The latter ISDN flag redundancies are a consequence of FSC-0091. Maybe one of the following implications could be added in zone 2: VFC => V32 V32B VFC => V32 V32B 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, 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) FIDONEWS 14-06 Page 12 10 Feb 1997 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) 57600 used with "X2" clients 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 57600 used with V120L or "X2" 64000 used with V120H, X75, 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, 57600, 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... ----------------------------------------------------------------- A reply to "Fidonews, The "lard ass" of newsletters" By Tony Dunlap, 1:2220/30 I was reading the paper the other day and noticed in the want ads a Maytag wringer washer for sale for $35.00. There was also an article with "Your Twelve Favorite Recipes Using Yogurt" (Not that I'd ever eat anything with a name that sounds like something that had already been eaten (then disposed of)). Then of course there were the funnies (most of which weren't), and the bridge column. I am not interested in any of these things, but I at least glance at them (mainly in hope of gaining a glimmer of understanding of the deranged minds of people who would be interested in such things ). The point I am trying to make is that Fidonews is for all members of FIDONEWS 14-06 Page 13 10 Feb 1997 Fidonet, not just the majority, and if a article is found useful by just one member, it belongs there. As for it's size, come on! All of last year's Fnews in their distrubuted format (LZH and ZIP) will fit on one high density floppy (Try to store a year's worth of newspapers in that space!) By the way, just for fun I called about the wringer washer... It's gone. --- ----------------------------------------------------------------- Ooh, ow! You wound me! by Gary Gilmore, 1:2410/400 Well, it seems that it's ok to write something -for- Fidonews, just as long as you don't -talk- about Fidonews. I thought the "editorial" about my article was a little out of line, but thought "what the hell, I'll respond". The Fidonews editor's comments are quoted... cb> He doesn't say how long he's been around but only refers to cb> the output of Tees, the previous Editor as example of FidoNews cb> size past. Gee, I didn't know that mattered. I guess it's part of a Fido "elite-ism" of "my board is older than yours, so you're not as good as me", which I've always found silly. Heck, I've seen BBS systems that have been up for a month that have floored me, and I've seen very old BBS systems that were total garbage, so what's the difference? For what it's worth, my BBS has been in constant operation since January 9th, 1988. I've been in Fidonet since 1990. (Somewhere around the summer of that year, if I recall right. My system was even a Computer Shopper Magazine "BBS Of The Month" for May of 1991.. not that it means a whole lot in the big picture. Now, does any of that make my comments more or less valid? I don't think so. We're Fidonet sysops, this is Fidonews, and that means this is the place where we can comment. ...and our comments shouldn't be cast aside with editorials trying to make them seem less valid than the next persons. cb> Since Tees didn't bother to actively edit FidoNews many times, cb> it's hardly surprising many of his Issues were miniscule or cb> Editorial only phosphor padding. Oh geez... now it's "slag the old editor" time. I find it humorous that the term "phosphor padding" is used here, when this past issue contains yet more FTSC bulletins to puff up the S'nooze. Ah well... cb> FidoNews has been all sizes the past 13 years from 5K to 157K. FIDONEWS 14-06 Page 14 10 Feb 1997 But I do think the content has varied wildly. Sometimes great stuff, sometimes nothing but dreck. I know the contributors have the burden of making Fidonews what it is, but I still don't think intentionally puffing it up makes it better. cb> Nobody has to read it; part or all of it. Very true, and perhaps the more dry it gets, the less it's read. I can't count the times I've said "Did you read
in Fidonews?" to some fellow sysops, and they almost always say "Ah, I never read that thing". Too bad. I do. All the time. cb> The History and Standards series is part of what FidoNet is and Sure is! I don't think it needs to be completely reprinted though, since it's already available elsewhere. Those that really care to read it will go get it. Those that don't are (to quote myself) "furiously hitting the page down key" to avoid it, so what's the use? Got me. cb> going to keep going this way. There are FIVE FSCs in this Issue. cb> There are only sixty or so more to go. [grin] Thanks for the warning! I guess it'll be safe to read Fidonews again sometime after the next 13 issues if one wants to avoid them. cb> The software list is also an important part of the FidoNews cb> mission and we all are indebted to Peter Popovich for the cb> Herculean labors he Umm, I do believe that I gave credit -and- thanks to Peter. What I -did- say is that Peter should be given a little break, and only have to have a listing ready monthly. That's all is really needed, since software isn't going to change that fast, and if "Brand X" drops support this week, waiting for a notice 3 weeks from now won't kill anyone. (And it'll give Peter more time to get good follow up information on these packages.) cb> the Echomail weenies flee FidoNet Echomail weenies? Hmmm.. I don't know what's wrong with echomail, but you seem to not like those that use it, judging by how many times you use this phrase in your editorial. cb> for the apparently greener pastures of Internet mailing lists, Funny this is here, since you're promoting a mailing list version of Fidonews. Imagine! Indeed, there's more -Internet- promoting of Fidonews (in the Fidonews) than there is of promoting how to get it via Fidonet. cb> Those who can't, get jobs as critics. I'm doing and teaching. Those that can't take criticism shouldn't be editors, I guess. Sorry to see you take it so personally, and feel the need to turn to thinly veiled insults in order to rebut what I've said, Chris. FIDONEWS 14-06 Page 15 10 Feb 1997 Oh well. C'est la vie. ----------------------------------------------------------------- FIDONEWS 14-06 Page 16 10 Feb 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing series of FidoNet Standards and Proposals being published as part of the FidoNet History project. The individual docs have been reformatted to 70 columns as required.] Ed. Document: FSC-0034 Version: 002 Date: 30-Aug-90 Gateways to and from FidoNet Technical, Administrative, and Policy Considerations FSC-0034 Randy Bush 30 August 1990 Status of this document: This FSC contains information of value to the general FidoNet(r) community. Distribution of this document is subject to the restrictions listed in the copyright paragraph below. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Copyright 1989-90, Randy Bush. All rights reserved. A right to distribute only without modification and only at no charge is granted. Under no circumstance is this document to be reproduced or distributed as part of or packaged with any product or other sales transaction for which any fee is charged. Any and all other reproduction or excerpting requires the explicit written consent of the author. What is a Gateway to/from FidoNet? ---- -- - ------- ------- -------- A gateway is a collection of software and procedures whereby net mail and/or echomail may be transferred between FidoNet and another computer communications network. Gateways are bi-directional, as folk always want to reply to others' mail. Gateways exist now. o There are a number of software packages for gating between uucp- based systems and FidoNet, the most well-known beingthe UFGATE shareware package. These packages gate both netmail and echomail, and are often used to provide FidoNet access to/from Internet via the uucp network. These tend to go through much effort to make FidoNet look as much like Internet as possible. As of this writing, about 25 uucp gateways are scattered around FidoNet. o Rhodes University has developed a complete system between a Cyber- based NOS network and FidoNet. This system handles both net mail FIDONEWS 14-06 Page 17 10 Feb 1997 and echomail, and is also strongly based on the Internet standards, and almost views FidoNet as a transport mechanism to get to/from Internet. It is used to gate a fairly localized cluster of mainframes to FidoNet at a single point, and has made special arrangements for further routing and forwarding of mail. o WWIVnet has developed gating software based on the ForDog package for the MS-DOS-based WWIV systems, and some other package for the Mac-based Tabby systems. The MS-DOS system uses Binkley or another FidoNet mailer handles the protocol transfers to make the WWIV system look like a FidoNet system to other FidoNet nodes. WWIVnet gates are said to be scattered around the US and Canada. o A number of FidoNet-based systems have been developed for various flavors of UN*X. These vary from encapsulated Fido-worlds within UN*X (i.e not true gates at all), to FidoNet front ends for UN*X mail systems. o RBBS-net seems to have developed gateway software for the MS-DOS- based BBS network, but I do not know enough to characterize it. All of these gateway systems can and are being run in a safe and cooperative fashion, and are providing a nice cross-cultural exchange with benefits for both sides of the gates. At this time, there are also other nets which, because they are based on technology similar to FidoNet, are dumping mail onto and taking mail off of FidoNet willy nilly, with little thought to the technical, administrative, or social consequences. Often, this is done with good intentions, not realizing they are providing a disservice to both nets. What are the Characteristics of a Good Gateway? ---- --- --- --------------- -- - ---- -------- Like good contracts, good gateways should be fair to both sides. There is the need to preserve both the technical and sociopolitical integrity of all parties to the transaction. Technically, both networks will have specifications and requirements for transfer protocols, message and echomail formats, control data files, etc. Beyond the borders of the gateway software, each universe should be completely and safely maintained. o Messages and echomail should completely conform in format and content to the technical specifications of each side of the gateway. o Addressing of messages and echomail should completely conform to that of the network in or through which the messages are traveling or resident at all times. o A normal user should be able to enter new messages destined for the other side of the gate and to reply to gated mail with relative ease. FIDONEWS 14-06 Page 18 10 Feb 1997 o If FidoNet uses a network A as an intermediate to get to/from a network B, or if network C uses FidoNet to get to/from network D, then the inter-net transitions should be auditable, but local customs and technalia of the intermediate network may not need always be enforced. Socially, the customs and fashions of each network should be maintained in that network. o There must be administrative liaison and control between the two networks so agreements may be made and enforced and disputes may be adjudicated. o If the networks being gated overlap geographically, then systems should not have to pay significant costs to move mail between the two networks when it is between two nodes that are in the same general locale. o Gating is not simple, technically or administratively. Unless each net anticipates significant use of the gateways, and the anticipated gain is seen as greater than the anticipated pain, then one side or the other may reasonably decline to do the necessary work. What Technical Standards Exist? ---- --------- --------- ------ Before we develop new specifications, social protocols, and standards, we should see what exists already. o FidoNet Technical Standards exist already for the data formats and the communication protocols for net mail and echomail. All conforming gateway systems mentioned above conform to these standards. These are named FSC-nnnn, or more recently FTS-nnnn. o The SRI-NIC has published standards for message formats and communication protocols that are used between a significant number of networks that already gate to each other. These are often referred to as the Internet standards and named RFCnnnn or IDEAnnnn. o The ISO and CCITT have standards for message formats and communication protocols which are used between a significant number of systems. These are based on X.nnn specifications, eg. X.400. Other standards undoubtedly exist and should be investigated by anyone desiring to build a gateway system. The game of 'my standard is better than yours' has been played for decades with no conclusion other then demonstrating the stupidity of war. What matters is that each net's standards are maintained within that net. What Administrative Standards Exist? ---- -------------- --------- ------ Most networks have formed administrative procedures and guidelines FIDONEWS 14-06 Page 19 10 Feb 1997 which regulate if and how other networks may gate to/from them. The most notable exception is the uucp/Usenet which, having no formalized administrative rules for anything else, imposes none on gateways. Before we recoil in horror, note that uucp/Usenet is three to four times the size of FidoNet, is over twice FidoNet's age, and has a significantly better signal-to-noise ratio. The SRI-NIC provides a procedure for registering Internet domains. A domain is somewhat like what we are considering a network. This Internet registration procedure ensures that the network has o administrative responsibility and control, and o at least two registered sites which provide address mapping for the netowrk being gated. FidoNet is a registered domain of Internet. Our domain is called fidonet.org. The administrative responsibility is the FidoNet IC's. The registered 'nameservers' are at lynx.cs.orst.edu and k9.cs.orst.edu, both at Oregon State University, though this is bending the two nameserver policy a bit. DECNET, ARPANET, ... all have applicable standards, but, as they are strictly limited to formal commercial relationships, they are of little interest here. What Administrative Policies are Needed by FidoNet? ---- -------------- -------- --- ------ -- -------- What does FidoNet really need to state in terms of administrative requirements on a network wishing to gate to/from FidoNet? FidoNet needs a means of ensuring that a formal relationship exists which may be used to negotiate technical standards between the two nets, internet adjudication of disagreements both technical and social, and enforcement of decisions. Similarly, the other network will likely want such assurances as well. Therefore an agreement should be reached stating: o who is administratively responsible, o who is technically responsible, o what technical and administrative documentation exists, and o both parties will abide by eachother's rules when in the other's house, and o how grievances are to be stated and adjudicated. In addition, it will be advisable for FidoNet to place some requirements on a network wishing to form official gateways. Some of these requirements and their motivations are: o If the other network geographically overlaps a significant portion of FidoNet, then the other net should be of sufficient size that FIDONEWS 14-06 Page 20 10 Feb 1997 gateways can likely be recruited in most areas where the nets overlap. Thus, systems should not have to pay significant costs to move mail between two nets that happen to be in the same locale. o If the other network geographically overlaps a significant portion of FidoNet, then there should, at a minimum, be gateways in each FidoNet zone where they overlap. o If the other network geographically overlaps more than one zone of FidoNet, then that net should have its own gateways between the zones, and not use FidoNet to move the burden of interzone PTT costs. o If the other network geographically overlaps a significant number of the regions in a FidoNet zone, then there should, at a minimum, be gateways in each FidoNet region where they overlap. o If the other network is geographically localized, then special arrangements may be made whereby there traffic is gated to/from FidoNet at one or more places by special arrangement as if the other network were a FidoNet node or local network (in the intra- FidoNet sense) itself. o Gating of net mail, i.e. user-to-user messages, must be implemented and easily used. Gating of Echomail is optional. o Mail must be bi-directional. If someone in the other net can send mail to a node/user on FidoNet, then that FidoNet node/user must be able to reply. o If echomail is gated, then, unless special circumstances are recognized by the responsible administrators, it must be gated bi- directionally. o If a conference is moderated (in the Usenet sense, similar to Dutchie's Conference Mail's moderation or GroupMail) on one network, then it should be moderated on all other networks, or at least the gateway into the network where it is moderated should ensure that correct moderation is done by forwarding or whatever is appropriate. For inter-net gateway systems in the process of formation, it is assumed that some of the above requirements may be waived during a startup period at the discretion of the administrative bodies. Observe that if FidoNet were to try to take a shortcut which has been suggested and simply require Intetnet registration of gating networks, then, of the current networks gating to FidoNet correctly (see above), only the Rhodes system could conform technically. Eg. the uucp gating packages gate to uucp which has no administrative center and is not registered with Internet. To require Internet registration would further neither the goals of Internet, nets wishing to gate to FidoNet, nor FidoNet itself. What Technical Requirements should FidoNet Place on Gating Systems? FIDONEWS 14-06 Page 21 10 Feb 1997 ---- --------- ------------ ------ ------- ----- -- ------ -------- Each network will have its own specifications for communication protocols, data formats, message conventions, addressing, etc. Though more generally used standards are to be preferred, what really matters is that each net be self-consistent and integritous and that gateway systems maintain that integrity. From the FidoNet perspective, the following attributes of a gateway system seem to be mandatory. o Conformance to FidoNet message format as specified in current FidoNet technical standards (eg. currently FSC-0001) must be maintained while messages are within FidoNet. o Information to assist message comprehension and processing by gateway systems and/or other networks may be contained within the message body, either hidden behind ^A lines or not. If such information is needed, then conformance to current Internet standards (eg. currently RFC822) is recommended. o The FidoNet message header must contain valid FidoNet addresses at all times the message is on FidoNet. Valid FidoNet addresses are addresses of specific FidoNet nodes in the current FidoNet nodelist. o The source and/or destination address in the other net should be embedded in the text body of the FidoNet message, either hidden behind ^A lines or not. Conformance to current Internet standards is recommended where appropriate, but addressing conventions in the other net may preclude this. o A message must contain sufficient information that the originating system and user may be easily determined. o A FidoNet sysop and/or normal FidoNet BBS user should be able to enter messages destined for users in the other network and reply to gated mail using current FidoNet software. o If echomail is gated, then the echo messages should conform to all current FidoNet standards for echomail. For example, currently an echomail message should: - have a correct tear line - have an origin line of the proper format with a FidoNet origin of the gating FidoNet node - have seenbys of only FidoNet nodes - have a path line that goes back at least to the gating node o If echomail is gated, then an echomail message must contain sufficient information that the system and user of origin may be trivially determined, whatever net may have originated it. o The origin of gated echomail should be determinable in a regular way sufficient that the gating software can provide easy construction of private net mail replies to echomail messages FIDONEWS 14-06 Page 22 10 Feb 1997 which would return to the echo messages's originator through the appropriate gateway, which may or may not be different than the gateway through which the echo message came. It is acknowledged that this may require hand editing on the part of the user composing the reply. o If echomail is gated, and the other net has no equivalent, it may use net mail and/or net mail mailing lists. Messages coming into FidoNet from this type of net mail or mailing list should properly gate into the appropriate echomail conference, and replies should work correctly as well. Conclusion ---------- It is hoped that, given a philosophy and guidelines such as those outlined in this paper, FidoNet will continue to expand its links to other networks to the benefit of FidoNet and networking in general. It is hoped that this paper will be of some help to those constructing gateways to/from FidoNet, and to the administrators of FidoNet and other nets who are considering gating to/from FidoNet. This paper, the purported facts contained, and the philosophy espoused are the sole responsibility of the author, and are quite likely technically incorrect and are undoubtedly morally bankrupt. Should you have constructive correction or criticism, please contact: Randy Bush FidoNet: 1:105/6 1:105/42 Internet: randy@psg.com randy@m2xenix.uucp uucp: { uunet, qiclab, bucket }!m2xenix!randy ---------- FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe much thanks for the origin and spirit of FidoNet. DECNET is a trademark of Digital Equipment Corporation. MS-DOS is a trademark of Microsoft Corporation. -30- ----------------------------------------------------------------- FSC-0035 Transparent Gateways to and from FidoNet Technical Considerations FSC-0035 Michael Shiels 22 June 89 Copyright 1989, Michael Shiels. All rights reserved. The right to distribute for non-commercial use is granted to the FidoNet Technical Standards Committee, provided that no fee is charged. This may be posted on FidoNet electronic BBSs which charge no fee for accessing FIDONEWS 14-06 Page 23 10 Feb 1997 this document. Any and all other reproduction or excerpting requires the explicit written consent of the author. Gateways -------- Gatewaying between Fidonet and other networks seems to be the latest feature which hopefully brings more benefits to the users of each network. But there are some real problems with gatewaying and doing "transparent" replies. This proposal should allow for almost totally transparent gateways but requires the co-operation of BBS software writers to support this following protocol. Incoming Messages ----------------- When a message is entered into fidonet from another network it will be entering through one machine (say 1/2). The userid on the other network may not match very will with the 2 word 36 character userid on Fidonet. So the following is done to store away the proper userid of the sender. Two (2) lines are added to the message (usually at the top of the text portion hidden by the infamous ^A KLUDGE). ^AREPLYADDR .....\r which signifies the FULL userid of the person on the other network. The first 36 characters or the full userid if less than 36 characters long, are stored in the FROM field of the message header. When replies are done they use a second line of the following form. ^REPLYTO zone:net/node firstname lastname which is used to signify the "userid" which mail destined to this other network must be sent to and on which machine that userids resides. Replies are sent to this zone:net/node and userid with the first line of the message being changed into 'TO: ....' where .... is the FULL userid from the ^AREPLYADDR line. Should you have constructive correction or criticism, please contact: Michael Shiels FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org uucp: ?!tmsoft!masnet!michael.shiels Internet: michael.shiels@masnet.uucp ---------- FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe much thanks for the origin and spirit of FidoNet. -30- FIDONEWS 14-06 Page 24 10 Feb 1997 ----------------------------------------------------------------- FSC-0036 GROUP MAIL SPECIFICATIONS by Dale W. Lovell 7:41/34@alternet 1:157/504@fidonet Group Message Files A Group Message File is a file which contains messages for a particular group conference. The file is named as follows: .xxx Where: is the GroupMail ID name xxx is the minute of the month that the last packet was added to the file in base 36 (0..9,A..Z). The following extensions are NOT used ARC, BAT, COM, DOC, EXE, PKT, TXT. If a packet is created would normally have this name, the minute is "bumped up" one to avoid using these names. (This is also the extension used by ARCmail). Each file can contain several packets of messages. Packets should be in the Fido type 2 packet. The packets start off with a packet header. Messages follow the packet header. Each message starts off with an abbreviated packetized message header. Following the header are several variable length fields. The structures is as follows: struct pkthdrs { /* packet header structure */ int ph_onode; /* Originating node number */ int ph_dnode; /* Destination node number */ int ph_yr,ph_mo,ph_dy; /* Date packet was assembled */ int ph_hr,ph_mn,ph_sec; /* Time packet was assembled */ int ph_rate; /* packet baud rate */ int ph_ver; /* packet version */ int ph_onet; /* Originating net */ int ph_dnet; /* destination net */ int ph_rsvd[17]; /* Reserved for possible future use */ }; struct pktmsgs { /* packetized message headers */ int pm_ver; /* message version */ int pm_onode; /* Originating node */ int pm_dnode; /* Destination node */ int pm_onet; /* Originating net */ int pm_dnet; /* Destination net */ int pm_attr; /* Message attributes */ int pm_cost; /* message cost in cents */ }; The variable length data that follows is: FIDONEWS 14-06 Page 25 10 Feb 1997 Field Description Maximum length (in characters) Date 20 To whom 36 Who From 36 Subject 72 Message text 8192 The packet is finished when in place of the packetized message header there are two null characters. Message Attributes Message headers contain an integer field holding "message attributes." These are bit values that select various properties of the message. They are defined as follows: #define MSGPRIVATE 0x0001 /* Private message */ #define MSGCRASH 0x0002 /* Crash priority message */ #define MSGREAD 0x0004 /* Read by addressee */ #define MSGSENT 0x0008 /* Sent okay */ #define MSGFILE 0x0010 /* file attached */ #define MSGFWD 0x0020 /* being forwarded */ #define MSGORPHAN 0x0040 /* Unknown destination */ #define MSGKILL 0x0080 /* Kill after mailing */ #define MSGLOCAL 0x0100 /* True if message entered here */ #define MSGHOLD 0x0200 /* true if hold for pickup */ #define MSGX2 0x0400 /* reserved -- sent */ #define MSGFREQ 0x0800 /* Requesting a file */ #define MSGRREQ 0x1000 /* Return Receipt requested */ #define MSGRRCT 0x2000 /* Return Receipt */ #define MSGAREQ 0x4000 /* Request audit trail */ #define MSGUREQ 0x8000 /* Requesting a file update */ The following attribute bits are included in the packetized message header. MSGPRIVATE MSGFILE MSGCRASH MSGX2 MSGRREQ MSGRRCT MSGAREQ All other attributes are masked off and are not sent to other systems. Packet files names are as follows: ddhhmmss.PKT Where: dd is the day of the month the packet was created hh is the hour (24 hour clock) the packet was created mm is the minute the packet was created ss is the second the packet was created For example if a GroupMail file in the conference SAMPLE is created on the 22nd of a month at 08:15 the Groupmail name would be SAMPLE.NPR. 21 full days 8.25 hours FIDONEWS 14-06 Page 26 10 Feb 1997 x 1440 minutes per day x 60 minutes per hour ------- --------- 30240 minutes 495 minutes + 495 minutes in today ------- 30735 minutes into the month Convert to base 36: NPR Note that at most there are 44640 minutes in a month and this naming scheme has the capability to handle up to 46656 file names. The remaining names (2015 files or an average of 65 files per day) may be used for distributing other files in a conference (anything over YG0, hint if it starts with Z it makes it easy to identify, still leaves 1296 different files or average of 41 files per day). Disk Directories GroupMail uses two special directories for distributing it's files. The first of these directories contains what I will be calling a group date file and any unprocessed, inbound group files. The Group Date File is a zero length file in the format: .! Where: is the Group conference name When new files are update requested, the mailer should only obtain those files whose time/date stamps are later than this file's time/date stamp (or any unprocessed group files with a later time/date stamp). This directory will be referred to as the Group Inbound Directory. If a system is holding any conferences for others to update request, it will need another directory. This directory holds all processed Group Mail Files. These files can be held for up to 31 days. After a file whose conference is being held for others is processed, it should be moved to this directory. This move MUST leave the time/date stamp as it was. If a system deviates this for ANY reason WOE unto they who wrote the Group Mail processor. This directory will be referred to as the Group Holding Directory. Message files In theory (and almost always in practice) you can store the processed messages in any format you desire. New messages must be put into your network mail area as a message your mailer can handle and send properly to other Fido compatible bulletin board systems/mailers. The structure of a Fido message is as follows: struct msghdrs { /* Message header structure */ char m_from[36]; /* Who from */ char m_to[36]; /* to whom */ char m_subj[72]; /* subject of message */ char m_date[20]; /* Date of message */ int m_times; /* Number of times read */ FIDONEWS 14-06 Page 27 10 Feb 1997 int m_dnode; /* Destination node */ int m_onode; /* Originating node */ int m_cost; /* Cost of message in cents */ int m_onet; /* Originating net */ int m_dnet; /* Destination net */ int m_caca; /* extra space */ int unsigned m_rep; /* Thread to previous */ int m_attr; /* Message attributes */ int m_up; /* Thread to next */ }; The header is followed by the text of the message. This text is stored as a string of characters ending with a null. The text may or may not contain carriage returns, each of which may or may not be followed by a linefeed. Any of these carriage returns may be "soft." If the high order bit (0x80) of the carriage return is set, then it is a soft return. Line feeds and soft returns should be ignored. More on the actual messages later on. Processing inbound messages For conferences where you are NOT the top star Unprocessed Group Message Files are in the Group Inbound Directory. A processor should go through all Group Message Files which are conferences that the system actually caries (as opposed to just passing through for other systems). The file's name should be used to determine for which conference these messages are destined. While most processors have the first line of text read as ^AAREA: (no spaces), this is meant for compatibility to those systems which do not yet have GROUP capabilities. In short, YOU CAN NOT DEPEND ON IT BEING THERE, so USE THE FILENAME. The packets should be extracted from the archived message file, put into your message base. The packet files should then be deleted. Messages put into your message base from these Group Message Files should be marked in some way so that they are not processed as newly entered messages. SEA's GROUP utility uses the message sent flag for this purpose and we recommend the use of the same flag wherever possible. After all Group Message Files have been processed, the Group Date Files should have their time/date stamp changed to that of the most recent file processed. Any Group Message Files for conferences being held for other systems should be moved to the Group Holding Directory so other systems can request these files. When the Group Message File is moved, the time/date stamp on the file MUST NOT be changed. Group Message Files for conferences not being held for others should be deleted. It is also desirable at this time to delete any Group Message Files which are over one month old, or whatever period of time less than one month the system operator of that board desires. For conferences where you ARE the top star FIDONEWS 14-06 Page 28 10 Feb 1997 You should check for any new netmail messages whose ^AAREA: line is "your" conference ID. These messages should be imported into your message base with the message sent flag (or your own equivalent) turned OFF. At such a time as you "PACK" new Group Message Files you should turn the sent flag ON. Processing new outbound messages For conferences where you ARE NOT the top star Your group processor should scan through all group conferences on the system and locate any messages which have been entered. These messages should be prepared to be sent out via network mail. The first line of the network mail message should read: ^AAREA: Where: is the Group conference name There should be no spaces in this area, although your processor should be tolerant of any spaces if they are present. The message should be "from" your address and addressed to your upward link in the conference. In addition the message should be marked to be deleted/killed after being sent. You should also check to see if any messages in your netmail area from other systems are for a GroupMail conference (either one you carry, or pass on to other systems). Any of these messages should be readdressed to your upward link in the conference. Under no circumstances should you change the from fields, they should contain the address of the person who entered the message into the conference. For conferences where you ARE the top star Messages should be "copied" from your message base into a properly named Group Message File. This Group Message File must have a correct time/date stamp and be in your Group Holding Directory. Once a message has been copied into a Group Message File, it is necessary to mark it so the same message is not placed into another Group Message File. SEA's GROUP uses the message sent flag for this purpose and we recommend the use of the same flag whenever possible. I think that's it. Everything else is handled by your mailer. In order to get new Group Mail messages, you do a file update request of the GROUP conference name (.*) with the update pointing to your Group Inbound Directory. Your mailer will then get any new Group Message Files from your upward link in the conference. As new Group Message Files are processed, those who are obtaining their conferences from you will perform file update requests from your Group Holding Directory. -30- FIDONEWS 14-06 Page 29 10 Feb 1997 ----------------------------------------------------------------- FIDONEWS 14-06 Page 30 10 Feb 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 038 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-010|Nodelist-017|Nodelist-024|Nodelist-031|Nodelist-038|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 10370|10177 -193 |10063 -114 | 9877 -186 | 9729 -148 |34| | 2 | 15979|15936 -43 |15938 2 |16078 140 |16067 -11 |57| | 3 | 868| 865 -3 | 863 -2 | 863 0 | 863 0 | 3| | 4 | 554| 553 -1 | 558 5 | 550 -8 | 549 -1 | 2| | 5 | 93| 93 0 | 93 0 | 87 -6 | 87 0 | 0| | 6 | 1073| 1073 0 | 1072 -1 | 1072 0 | 1072 0 | 4| +----+------+------------+------------+------------+------------+--+ | 28937|28697 -240 |28587 -110 |28527 -60 |28367 -160 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-06 Page 31 10 Feb 1997 ================================================================= NET HUMOR ================================================================= From: "Mike Riddle" To: "Baker, Christopher" , Date: Thu, 30 Jan 97 17:10:22 -0600 Reply-To: "Mike Riddle" Subject: From another list.... Famous answers to : "Why did the chicken cross the road?" ----------------------------------------------------- Plato: For the greater good. Karl Marx: It was a historical inevitability. Thomas de Torquemada: Give me ten minutes with the chicken and I'll find out. Timothy Leary: Because that's the only kind of trip the Establishment would let it take. Douglas Adams: Forty-two. Nietzsche: Because if you gaze too long across the Road, the Road gazes also across you. Oliver North: National Security was at stake. Carl Jung: The confluence of events in the cultural gestalt necessitated that individual chickens cross roads at this historical juncture, and therefore synchronicitously brought such occurrences into being. Jean-Paul Sartre: In order to act in good faith and be true to itself, the chicken found it necessary to cross the road. Ludwig Wittgenstein: The possibility of "crossing" was encoded into the objects "chicken" and "road," and circumstances came into being which caused the actualization of this potential occurrence. Albert Einstein: Whether the chicken crossed the road or the road crossed the chicken depends upon your frame of reference. FIDONEWS 14-06 Page 32 10 Feb 1997 Aristotle: To actualize its potential. Buddha: If you ask this question, you deny your own chicken-nature. Salvador Dali: The Fish. Darwin: It was the logical next step after coming down from the trees. Emily Dickinson: Because it could not stop for death. Epicurus: For fun. Ralph Waldo Emerson: It didn't cross the road; it transcended it. Johann Friedrich von Goethe: The eternal hen-principle made it do it. Ernest Hemingway: To die. In the rain. Werner Heisenberg: We are not sure which side of the road the chicken was on, but it was moving very fast. David Hume: Out of custom and habit. Saddam Hussein: This was an unprovoked act of rebellion and we were quite justified in dropping 50 tons of nerve gas on it. Jack Nicholson: 'cause it (censored) wanted to. That's the (censored) reason. Pyrrho the Skeptic: What road? Ronald Reagan: I forget. John Sununu: The Air Force was only too happy to provide the transportation, so quite understandably the chicken availed himself of the opportunity. The Sphinx: You tell me. Sappho: FIDONEWS 14-06 Page 33 10 Feb 1997 Due to the loveliness of the hen on the other side, more fair than all of Hellas' fine armies. Henry David Thoreau: To live deliberately ... and suck all the marrow out of life. Mark Twain: The news of its crossing has been greatly exaggerated. Stephen Jay Gould: It is possible that there is a sociobiological explanation for it, but we have been deluged in recent years with sociobiological stories despite the fact that we have little direct evidence about the genetics of behavior, and we do not know how to obtain it for the specific behaviors that figure most prominently in sociobiological speculation. Joseph Stalin: I don't care. Catch it. Crack its eggs to make my omelette. Captain James T. Kirk: To boldly go where no chicken has gone before. Machiavelli: So that its subjects will view it with admiration, as a chicken which has the daring and courage to boldly cross the road, but also with fear, for whom among them has the strength to contend with such a paragon of avian virtue? In such a manner is the princely chicken's dominion maintained. Hippocrates: Because of an excess of pleghm in its pancreas. Peter Hutton: Because it was cheaper for the company on the other side of the road. Patrick Beauvillard: Sheeken? What Sheeken? Sacha Mateescu: A chicken resource of that particular skillset was needed on the other side of the road. Andersen Consultant: Deregulation of the chicken's side of the road was threatening its dominant market position. The chicken was faced with significant challenges to create and develop the competencies required for the newly competitive market. Andersen Consulting, in a partnering relationship with the client, helped the chicken by rethinking its physical distribution strategy and implementation processes. Using the Poultry Integration Model (PIM) Andersen helped the chicken use its skills, methodologies, knowledge capital and experiences to align the chicken's people, processes and technology in support of its overall strategy within a Program Management framework. FIDONEWS 14-06 Page 34 10 Feb 1997 Andersen Consulting convened a diverse cross-spectrum of road analysts and best chickens along with Andersen consultants with deep skills in the transportation industry to engage in a two-day itinerary of meetings in order to leverage their personal knowledge capital, both tacit and explicit, and to enable them to synergize with each other in order to achieve the implicit goals of delivering and successfully architecting and implementing an enterprise-wide value framework across the continuum of poultry cross-median processes. The meeting was held in a park like setting enabling and creating an impactful environment which was strategically based, industry-focused, and built upon a consistent, clear, and unified market message and aligned with the chicken's mission, vision, and core values. This was conducive towards the creation of a total business integration solution. Andersen Consulting helped the chicken change to become more successful. ----------------------------------------------------------------- FIDONEWS 14-06 Page 35 10 Feb 1997 ================================================================= NOTICES ================================================================= Future History 16 Feb 1997 Eleventh Anniversary of invention of Echomail by Jeff Rush. 29 Feb 1997 Nothing will happen on this day. 17 May 1997 Independence Day, Norway. 25 May 1997 Independence Day, Argentina. 6 Jun 1997 National Commemoration Day, Sweden. 11 Jun 1997 Independence Day, Russia. 1 Jul 1997 Canada Day - Happy Birthday Canada. 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. 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 FIDONEWS 14-06 Page 36 10 Feb 1997 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. ----------------------------------------------------------------- FIDONEWS 14-06 Page 37 10 Feb 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 Things over here have been chaotic, so I haven't been able to reply to my e-mails. I'll be catching up this coming week. Phased out this week: WildCat! 3.02 and XBBS 1.77 Phase-out highlights: This week: "Tandy Color Computer 3 (OS-9 Level II)" Section Deadline for info: 21 Feb 1997. Last week: "Xenix/Unix 386 -- Other Utilities" Section Deadline for info: 14 Feb 1997. -=- 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.1 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.0 O G Michiel van der 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 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 FIDONEWS 14-06 Page 38 10 Feb 1997 GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GED 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 ImCrypt 1.04 O G Michiel van der Vlist 2:500/9 IMCRYPT InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL InfoMail/386 1.20 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 van der Vlist 2:500/9 MAKEPL Marena 1.1 beta O G Michiel van der Vlist 2:500/9 MARENA Maximus 3.01 B P Tech 1:249/106 MAX McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP Msged 4.00 O G Paul Edwards 3:711/934 MSGED Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT PcMerge 2.7 N G Michiel van der Vlist 2:500/9 PCMERGE PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP RAR 2.00 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.599I M S Ron Dwight 2:220/22 TMAIL Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG TriToss 10.0 T S Patrick Driscoll 1:372/19 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.30 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 FIDONEWS 14-06 Page 39 10 Feb 1997 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 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 FleetStreet 1.18 O S Michael Hohner 2:2490/2520 FLEET 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 van der Vlist 2:500/9 IMCRYPT Maximus 3.01 B P Tech 1:249/106 MAXP Msged 4.00 O G Paul Edwards 3:711/934 MSGED PcMerge 2.3 N G Michiel van der Vlist 2:500/9 PCMERGE RAR 2.00 C S Ron Dwight 2:220/22 RAR2 Squish 1.11 T P Tech 1:249/106 SQUISHP T-Mail 2.599I 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.10 P S Mats Wallin 2:201/329 FDAPXW Windows (32-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- 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 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.00 O G Andrew Clarke 3:635/728 MSGNT400.ZIP PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO T-Mail 2.599I 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.8g M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx ...tx7.8 M G Pablo Saratxaga 2:293/2219 IFMAILTX 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 ---------------------------------------------------------------------- FIDONEWS 14-06 Page 40 10 Feb 1997 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 Atari: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY 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 Old info from: 01/27/92 --------------------------------------------------------------------- MS-DOS Systems Other Utilities Other Utilities -------------- Name Version Name Version -------------------- -------------------- Network Mailers 2DAPoint 1.50* Netsex 2.00b Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35 -------------------- ARCAsim 2.31 Oliver 1.0a D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02 Dreamer 1.06 Areafix 1.20 PKInsert 7.10 Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a Milqtoast 1.00 Crossnet 1.5 QM 1.00a PreNM 1.48 DOMAIN 1.42 QSort 4.04 SEAdog 4.60 DEMM 1.06 RAD Plus 2.11 SEAmail 1.01 DGMM 1.06 Raid 1.00 TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0 EEngine 0.32 ScanToss 1.28 Compression EMM 2.11* ScMail 1.00 Utilities EZPoint 2.1 ScEdit 1.12 Name Version FGroup 1.00 Sirius 1.0x -------------------- FidoPCB 1.0s@ SLMail 2.15C ARC 7.12 FNPGate 2.70 StarLink 1.01 ARJ 2.20 GateWorks 3.06e TagMail 2.41 LHA 2.13 GMail 2.05 TCOMMail 2.2 PAK 2.51 GMD 3.10 Telemail 1.5* PKPak 3.61 GMM 1.21 TGroup 1.13 PKZip 1.10 GROUP 2.23 TIRES 3.11 GUS 1.40 TMail 1.21 NodeList Utilities Harvey's Robot 4.10 TosScan 1.00 Name Version HeadEdit 1.18 UFGATE 1.03 -------------------- HLIST 1.09 VPurge 4.09e EditNL 4.00 ISIS 5.12@ WEdit 2.0@ FDND 1.10 Lola 1.01d WildMail 2.00 MakeNL 2.31 Mosaic 1.00b WMail 2.2 Parselst 1.33 MailBase 4.11a@ WNode 2.1 Prune 1.40 MSG 4.5* XRS 4.99 FIDONEWS 14-06 Page 41 10 Feb 1997 SysNL 3.14 MsgLnk 1.0c XST 2.3e XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00 XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25 MSGTOSS 1.3 ZSX 2.40 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - OS/2 Systems ------------ Other Utilities Other Utilities BBS Software Name Version Name Version Name Version -------------------- -------------------- -------------------- ARC 7.12 oMMM 1.52 Kitten 1.01 ARC2 6.01 Omail 3.1 SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33 EchoStat 6.0 PKZip 1.02 Network Mailers EZPoint 2.1 PMSnoop 1.30 Name Version FGroup 1.00 PolyXOS2 2.1a -------------------- GROUP 2.23 QSort 2.1 BinkleyTerm(S) 2.50 LH2 2.11 Raid 1.0 BinkleyTerm/2-MT MSG 4.2 Remapper 1.2 1.40.02 MsgLink 1.0c Tick 2.0 SEAmail 1.01 MsgNum 4.16d VPurge 4.09e - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Xenix/Unix 386 Other Utilities -------------- Name Version -------------------- BBS Software Network Mailers ARC 5.21 Name Version Name Version C-LHARC 1.00 -------------------- -------------------- MSGLINK 1.01 oMMM 1.42 Omail 1.00 |Contact: Willy Paine 1:343/15,| ParseLst 1.32 |or Eddy van Loo 2:285/406 | Unzip 3.10 VPurge 4.08 Zoo 2.01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BBS Software Macintosh Other Software Name Version --------- Name Version -------------------- -------------------- FBBS 0.91 Network Mailers MacArd 0.04 Hermes 1.6.1 Name Version Mantissa 3.21 Mansion 7.15 -------------------- Mehitable 2.0 Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0 Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2 Telefinder Host StuffIt Classic 1.6 2.12T10 Other Software SunDial 3.2 Name Version TExport 1.92 -------------------- TimeStamp 1.6 Point System ArcMac 1.3 TImport 1.92 Software AreaFix 1.6 Tset 1.3 Name Version Compact Pro 1.30 TSort 1.0 FIDONEWS 14-06 Page 42 10 Feb 1997 -------------------- EventMeister 1.0 UNZIP 1.02c Copernicus 1.00 Export 3.21 Zenith 1.5 CounterPoint 1.09 Import 3.2 Zip Extract 0.10 MacWoof 1.1 LHARC 0.41 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Amiga Network Mailers Other Software ----- Name Version Name Version -------------------- -------------------- BBS Software BinkleyTerm 1.00 Areafix 1.48 Name Version TrapDoor 1.80 AReceipt 1.5 -------------------- WelMat 0.44 ChameleonEdit 0.11 4D-BBS 1.65 ConfMail 1.12 Falcon CBCS 1.00 ElectricHerald 1.66 Starnet 1.0q@ Compression FFRS 1.0@ TransAmiga 1.07 Utilities FileMgr 2.08 XenoLink 1.0 Name Version Fozzle 1.0@ -------------------- Login 0.18 AmigArc 0.23 MessageFilter 1.52 NodeList Utilities booz 1.01 Message View 1.12 Name Version LHARC 1.30 oMMM 1.50 -------------------- LhA 1.10 PolyXAmy 2.02 ParseLst 1.66 LZ 1.92 RMB 1.30 Skyparse 2.30 PkAX 1.00 Roof 46.15 TrapList 1.40 UnZip 4.1 RoboWriter 1.02 Zippy (Unzip) 1.25 Rsh 4.07a Zoo 2.01 Tick 0.75 TrapToss 1.20 |Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BBS Software Atari ST/TT Name Version ----------- -------------------- FIDOdoor/ST 2.5.1 Network Mailers Other Utilities FiFo 2.1v Name Version Name Version LED ST 1.00 -------------------- -------------------- QuickBBS/ST 1.06* The Box 1.95* ApplyList 1.00@ Burep 1.1 Compression ComScan 1.04 Utilities NodeList Utilities ConfMail 4.10 Name Version Name Version Echoscan 1.10 -------------------- -------------------- FDrenum 2.5.2 ARC 6.02 ParseList 1.30 FastPack 1.20 LHARC 2.01i EchoFix 1.20 Import 1.14 PackConvert sTICK/Hatch 5.50 oMMM 1.40 STZip 1.1* Pack 1.00 UnJARST 2.00 Trenum 0.10 WhatArc 2.02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tandy Color Computer 3 (OS-9 Level II) Other Utilities -------------------------------------- Name Version FIDONEWS 14-06 Page 43 10 Feb 1997 -------------------- BBS Software Compression Utility Ascan 1.2 Name Version Name Version AutoFRL 2.0 -------------------- -------------------- Bundle 2.2 RiBBS 2.02+ Ar 1.3 CKARC 1.1 DeArc 5.12 EchoCheck 1.01 OS9Arc 1.0 FReq 2.5a UnZip 3.10 LookNode 2.00 UnLZH 3.0 ParseLST PReq 2.2 RList 1.03 RTick 2.00 UnBundle 1.4 UnSeen 1.1 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Key to old info: + - Netmail Capable (Doesn't Require Additional Mailer Software) * - Recently Updated Version @ - New Addition -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Please send updates and suggestions to: Peter Popovich, 1:363/264 ----------------------------------------------------------------- FIDONEWS 14-06 Page 44 10 Feb 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-06 Page 45 10 Feb 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 http://www.dharmanet.org/BDO/net125.html Region 15: http://www.smrtsys.com/region15/ Region 17: http://www.portal.ca/~awalker/region17.htm Region 18: http://www.citicom.com/fido.html Region 19: http://ccove.n-link.com/ ============ Zone 2: http://www.z2.fidonet.org ZEC2 http://fidoftp.paralex.co.uk/zec.htm Region 29: http://www.rtfm.be/fidonet/ (in French) Region 36: http://www.geocities.com/SiliconValley/7207/ ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: ============ FIDONEWS 14-06 Page 46 10 Feb 1997 Zone 5: ============ Zone 6: http://www.z6.fidonet.org ============ ----------------------------------------------------------------- FIDONEWS 14-06 Page 47 10 Feb 1997 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Christopher Baker Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Tom Jennings, 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 cbak.rights@opus.global.org (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 1996 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 FIDONEWS 14-06 Page 48 10 Feb 1997 FNEWS for the current month in one archive. Or file-request specific back Issue filenames in distribution format [FNEWSDnn.LZH] for a particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96. Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in size from 48K to 1.2M. 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. =*=*=*=*=*=*=*=*= FIDONEWS 14-06 Page 49 10 Feb 1997 A PGP generated public-key is available for the FidoNews Editor from 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- -----------------------------------------------------------------