F I D O N E W S -- | Vol. 10 No. 9 (1 March 1993) A newsletter of the | FidoNet BBS community | Published by: _ | / \ | "FidoNews" BBS /|oo \ | +1-415-863-2739 (_| /_) | NEW!--> 1:1/23@FidoNet _`@/_ \ _ | editor@fidonews.fidonet.org | | \ \\ | | (*) | \ )) | Editors: |__U__| / \// | Tom Jennings _//|| _\ / | Tim Pozar (_/(_|(____/ | (jm) | Newspapers should have no friends. | -- JOSEPH PULITZER ----------------------------+--------------------------------------- /********************************************************************* * IMPORTANT NOTE: The FidoNet address for FidoNews has been changed. * * The new address is: * * * * FidoNews = 1:1/23 * * * * Starting January 1993 email sent to the old address will not be * * forwarded! You were warned! * *********************************************************************/ For information, copyrights, article submissions, obtaining copies and other boring but important details, please refer to the end of this file. Table of Contents 1. EDITORIAL ..................................................... 1 Editorial: Bye bye! (boo hoo!) ................................ 1 2. ARTICLES ...................................................... 3 Steve Jackson Games case -- recent news ....................... 11 Caller ID ..................................................... 15 The Youth of FidoNet, Part II ................................. 17 I get the point! .............................................. 18 H-Net (Handle-Net) Opening March 6,1993! ...................... 19 Head-to-Head Air Combat Simulators Echo ....................... 21 This New Echo, KLINGON - What Is It? .......................... 22 TWO NEW BLINDNESS-RELATED ECHOS NOW AVAILABLE ................. 23 3. FIDONEWS INFORMATION .......................................... 25 FidoNews 10-09 Page 1 1 Mar 1993 ====================================================================== EDITORIAL ====================================================================== Editorial: Bye bye!! (boo hoo!) Well this is it, my final editorial. Next week's will be edited by Silvia Maxwell and Don Tees. Say hi to them. (Hi!) Today is a momentous day for me. I'm moving into a new apartment this very day, tomorrow my phone lines get swapped over. As soon as I finish this, I have to pack more boxes aand drag 'em over. We're moving from out in the boonies to the heart of the Mission; 16th St between Mission and Valencia. The three little holes in my windows turned out to be bullet holes! (22 or 25 cal.) The glass is double-paned, and I was able to locate the trajectory. Later, I pull down the shade, and there's matching holes! Yipes! Oh well, instead of a 45 minute walk to the cafe, it's about 120 seconds, a vast improvement. No more do I have to pay $1 for a bus, down on the corner I can buy a "late nite" (daily bus transfer) for 25 cents! ("I love, livin' in the city!" -- FEAR) I digress. Oh, probably there'll be small mistakes made, but be helpful and nice. Our new editors have to decipher my 4DOS batch files, and generate a newsletter that's at least recognizable and somehow get it to 1:13/13. In a week. I look forward to seeing what changes they make. I failed to keep one promise, that of revamping the newsletter format from "line printer" format to online readable. I really blew the "Ask EFF!" project, though Shari Steele is hanging in there raring to go. Think back on all the little wars we've had... Zone 2 hassles... Z1C "process" or lack of... POLICYx... encryption... I'm begging off just in time to miss the "Caller ID" wars -- YAY!!! (You know it's time to leave when...) It's been fun, really!! Even the hard parts I learned a lot, about taking my lumps when necessary, and staying the hell out of local squabbles. So ta-ta, I'll see you out in the cloud... FidoNews 10-09 Page 2 1 Mar 1993 My BBS is going to go offline for a while, probably a month or two, starting this week. I will have an email address however, but it's on the Internet. It's tomj@fido.wps.com My old DOS machine is now running 386BSD and directly connected to the internet. In itself an interesting story, and one you'll probably see in these pages and BOARDWATCH magazine. Anyways -- you can email me from FidoNet, via certain FidoNet nodes flagged "GUUCP". Those are UFGATE sites, that have one foot each in FidoNet and Internet. There's a bunch of then. The way it works is you send a message to one of those FidoNet addresses, with certain magicwords placed within the message itself, that the UFGATE software detects. These are: the "to:" field being the single word UUCP. The VERY FIRST line of the message formatted exactly as: to: tomj@fido.wps.com With at least one completely blank line following it. After that, put your real message. Make sure ytou have the address (ie. the to: line embedded in the message body) correct, otherwise your message won't make it. ---------------------------------------------------------------------- FidoNews 10-09 Page 3 1 Mar 1993 ====================================================================== ARTICLES ====================================================================== *A FidoNet (FTN) Domain Name Service (I'm submitting this to FidoNews to generate thought and discussion about alternatives to the present nodelist. This proposal was inspired by the recent nodelist problems (extrainious control characters, CRC errors, etc.). The present nodelist is getting too big to be perfectly managed - the recent nodelist problems will happen again sooner or later. Sooner or later MakeNL will break (probably sooner) and other nodelist processing software will start to have problems as the nodelist continues to grow. RPH) Document: FSC-0000 Version: 001 Date: 14-Nov-1992 A Proposal for A FidoNet (FTN) Domain Name Service Robert Heller 1:321/153 Locks Hill BBS Information: The purpose of this FSC is to describe my ideas for migrating FidoNet(r) networks from a "static" nodelist to a domain based nameserver type of address resolution scheme. This document does not propose a definitive scheme, only one posible scheme. Other schemes are posible - this document just presents one as a starting point for discussion. Distribution of this document is unlimited. 1. Introduction --------------- In this document I plan to present a simple domain nameserver scheme for FidoNet(r) networks. This scheme could be implemented easily, since no new connection protocols would be needed and in fact little new software would be needed. Nameserver queries would be implemented as File Requests for magic filenames. The files would contain the information needed to perform the desired address resolution. These files would be built by the nameserver in advance by an off-line process. That is, they would be pre-computed - the querying node would not be left hanging on the line while the nameserver went off and did a database lookup. FidoNews 10-09 Page 4 1 Mar 1993 2. Addresses ------------ A domain nameserver based FidoNet would use three levels of addressing: virtual (most abstract), logical, and physical (least abstract). 2.1 Virtual Addresses A node has 1 or more virtual addresses, one of which is it primary address and the others are aliases. A virtual address is a totally symbolic address and is formatted just like an InterNet address: node.domain where node is the node's name and domain is a domain specification and can have any number of [sub-]* domains. For example, my system could have a virtual address of: LocksHill.DeepWoods.com.fidonet.org The node and domain segment strings consist of letters (upper and lower case are equivelant), digits, dash (-), underscore (_), and dollar sign ($) characters and must begin with a letter. Virtual addresses generally convey no geographical or routing information. They are intended purely for human convience purposes - they are really little more and a node name, with some added information. 2.2 Logical Addresses A node can 1 or more logical addresses, although having only 1 is preferable. A logical address is exactly an existing 3-4D FidoNet(r) address: Zone:Net_or_Region/Node or Zone:Net_or_Region/Node.Point A logical address is used by mail packers and mail routers. It is the addresses exchanged in YooHoo/2U2 packets and live in the Type-2 packet headers. 2.3 Physical Addresses A node has exactly one physical address. In FidoNet(r), this is typically the telephone number assigned by the telephone company. (It is posible that some nodes have something else as a "physical" address, for example a point which is connected to its bossnode via a LAN connection or a hardwired COM port.) A multi-line BBS typically has one line for FidoNet(r) connections FidoNews 10-09 Page 5 1 Mar 1993 or multiple logical and virtual address, at least one per line. The physical address is used by the mailer program to actually make a connection. 3. The Domain Database ---------------------- The domain database would consist of four ASCII text files, probably compressed: 1) The domain table. This text file maps between virtual addresses and logical addresses. It also defines aliases as well and lists nameservers. 2) The mail-exchanger table. This text file describes the prefered netmail routing. For each domain tail, it lists one or more node names that handle incoming mail for those domain tails. This file only uses virtual addresses. Its data is consulted by high-level mail routers, that take out-bound mail messages and combines them into bundles that are later packed into mail packets (which are routed to logical address fetched from the domain table). 3) The capability file. This file describes any extra services or capabilities a node might provide. This includes (but is certainly not limited to): gateway services (to other FTN or to non-FTN networks), alternitive low-level connection protocols (i.e. UUCP, SLIP, etc.), and file echos (SDS, SDN, etc.). This file is meant as a catch-all for misc. optional information that might be usefull. 4) The nodelist segment file. This file contains the mapping from logical address to physical address, and is in fact, a presnt-day NodeList file, except it is a "sparce" nodelist. That is, it only describes the nodes at the immediate level of the nameserver and nodes at the level above and below the nameserver. 3.1 Format of the domain table file. ------------------------------------ The domain table file contains 1 or more lines of text. Lines starting with a semi-colon (;) are comments and are ignored when this file is processd. Each non-comment line contains two or more fields separated by commas: field1,field2,...,fieldN The first field is a field type keyword. The field types defined are (case is not important): FidoNews 10-09 Page 6 1 Mar 1993 DEFAULT,domaintail Defines the default domain tail to append to domain names in the rest of the file. Domain tail must begin with a dot (.). Any subsequent domain names that do end in a dot will get the specified domaintail appended before further processing. NAMESERVER,domaintail,domain,preference Defines a domain server for domaintail. Domain is the virtual address of the server node and preference is a preference value, a number giving a relative value when looking for a server to contact. A higher number means this is a better node to try and a lower number means this is a backup server. The preference gives a ranking for multiple servers for a given domain tail. ALIAS,domain1,domain2 Defines that domain1 is an alias for domain2. ZONE,zone-number REGION,region-number NET,net-number Defines default values to use in subsequent ADDRESS lines. Region and net lines are effectivly interchangable and are used for documentary reasons. ADDRESS,domain,logical-address Defines the logical address for domain. The logical-address can be missing fields. Missing fields are supplied from prior ZONE, REGION, and NET lines. Node and point numbers cannot be defaulted. 3.1.1 Sample domain table. ;; Domain table for Network 999 (N_Luna) of zone 444 (the Moon) ;; (c) Copyright 2001 Network 999 ;; ;; Our default domain Default,.N_Luna.moon.fidonet.org ;; Our zone Zone,444 ;; Our Net Net,999 ;; Our NC, Jim Alias,N_Luna_Net,Jims_SpaceSuits ;; Our NEC, Sally Alias,N_Luna_NEC,Sallys_Lunies ;; Our namesevers ;; Note empty domaintail - the default is used NameServer,,N_Luna_Net,100 NameServer,,N_Luna_NEC,50 ;; Out of net nameservers ;; Our Zone nameserver FidoNews 10-09 Page 7 1 Mar 1993 NameServer,.moon.fidonet.org.,Moon_NS.fidonet.org.,100 ;; Our IC nameserver NameServer,.fidonet.org.,FidoNet_NS.fidonet.org.,100 ;; Use the IC nameserver for non-fidonet addresses NameServer,.,FidoNet_NS.fidonet.org.,100 ;; ;; ;; Nodes ;; Address,Jims_SpaceSuits,100 Address,Sallys_Lunies,110 Address,Moon_Rock_BBS,120 Address,Monolith_HQ,200 Address,Space1999,210 Address,LostOnTheMoon,240 Address,NorthLunaics,300 ;; ;; Out of net addresses ;; Address,Moon_NS.fidonet.org.,999/100 Address,FidoNet_NS.fidonet.org.,1:1/0 Address,naEarth_gate.moon.fidonet.org.,999/1 Address,eurEarth_gate.moon.fidonet.org.,999/2 Address,ozEarth_gate.moon.fidonet.org.,999/3 Address,saEarth_gate.moon.fidonet.org.,999/4 Address,AfricaEarth_gate.moon.fidonet.org.,999/5 Some notes about the above - the underscores (_) are part of the names and do not indicate spaces. The case mixing is stylistic and is an aid to readablity. The above is a net level domain table. It also includes nameserver definations for higher levels, so nodes in N_Luna net can perform address resolutions to out of net addresses. 3.2 Format of the mail exchanger table file. -------------------------------------------- The mail exchanger table file contains 1 or more lines of text. Like the domain table lines starting with a semi-colon (;) are comments and each non-comment line contains a list of three comma-separated values: domaintail,domain,preference Where domaintail is a domain suffix of a posible mail address, domain is the virtual-address of a node that handles the domain suffix's mail, and preference is a preference value (higher number is more prefered than a lower number). FidoNews 10-09 Page 8 1 Mar 1993 3.2.1 Sample mail exchanger table file ;; Mail exchanger table for Network 999 (N_Luna) ;; of zone 444 (the Moon) ;; (c) Copyright 2001 Network 999 ;; ;; Local mail can go via either the NC or NEC, with the NC ;; getting a higher preference .N_Luna.moon.fidonet.org,N_Luna_Net.moon.fidonet.org,100 .N_Luna.moon.fidonet.org,N_Luna_NEC.moon.fidonet.org,90 ;; Out of zone mail goes through the zone gates .naEarth.fidonet.org,naEarth_gate.moon.fidonet.org,50 .eurEarth.fidonet.org,eurEarth_gate.moon.fidonet.org,50 .ozEarth.fidonet.org,ozEarth_gate.moon.fidonet.org,50 .saEarth.fidonet.org,saEarth_gate.moon.fidonet.org,50 .AfricaEarth.fidonet.org,AfricaEarth_gate.moon.fidonet.org,50 .JupiterNet.org,Monolith_HQ.N_Luna.moon.fidonet.org,50 Some notes about the above - undefined domain tails don't have a defined mail exchanger - this will cause a node trying to send such mail to do a nameserver call to get mail exchanger and any other info needed. ( The above is probably unrealistic - a more realistic mail exchanger table might have a default mail gateway. And/or a zone-local inter-network nameserver.) 3.3 Capability file. -------------------- The capability file lists virtual-address and any extra services it might provide. Semi-colon (;) in column one means a comment. The non-comment lines are of the format: virtual-address,keyword:value,keyword:value,... Where virtual-address is a node's virtual address. There can be any number of lines with the same virtual-address. The keyword:value pairs accumulate (as if there was only one very long line for that virtual-address). 3.3.1 Sample capability file. ;; Capability file for Network 999 (N_Luna) ;; of zone 444 (the Moon) ;; (c) Copyright 2001 Network 999 ;; Jims_SpaceSuits.N_Luna.moon.fidonet.org,Protcol:UUCP-Z Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:SDSURISC Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:PDNVIRTWIND Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:PDNVIRTREAL Monolith_HQ.N_Luna.moon.fidonet.org,Protocol:X2500 Monolith_HQ.N_Luna.moon.fidonet.org,Gateway:JupiterNet.org Space1999.N_Luna.moon.fidonet.org,File:PDNNUKEWASTE FidoNews 10-09 Page 9 1 Mar 1993 3.4 The NodeList Segment File. ------------------------------ The nodelist segment file is just a FTS-0005 nodelist file, except it is "sparce", that is, it only contains just enough info to translate the logical addresses in the corresponding domain table file. 4.0 Nameserver Implementation. ------------------------------ Nameservers would be implemented by using the existing file-request methods presently in existance. Five magic filenames would be setup: DNSDTABL - Domain table file DNSMXTBL - Mail Exchanger table file DNSCAPAF - Capability file DNSNODEL - NodeList segment file DNSALL - An archive file containing all four of the files. All a nameserver would need to do would be to provide these five files, probably in some sort of commonly acceptable archive format. The real filenames should have some sort of predictable, but unique name probably based on the level of the nameserver and the number of the zone, region, or network the nameserver serves. 4.1 Nameserver Levels. ---------------------- Nameservers would exist at various levels: 1) At the zone level. The zone level nameserver(s) would supply information for the current zone level nodes, regional level nameservers, and would also have information about the zone level nameservers in all other zones. 2) At the regional level. The regional level nameservers would supply information for the current region level nodes (indpendent nodes), the current zone nameserver(s) (up level), and network level nameservers. In some smaller zones, the region level *might* be skipped. The RC also makes the regional level domain info available to each of the region's independent nodes. 3) At the network level. The network level nameservers would supply information about the current network level nodes (regular nodes), and the current regional nameserver(s). Also, the NC delivers or makes available the network level domain info to each of the nodes in the FidoNews 10-09 Page 10 1 Mar 1993 local network. (If the regional level is skipped, the network nameservers would contain entries for zone level nameservers and zone level nameserver(s) would contain network nameserver info instead of regional nameserver info.) 5.0 Database Updates and Management. ------------------------------------ Each node gets the network (region for independents) level info. These updates are handled much the way nodediffs get handled at present. The existing nodediff structure is really a generic text file difference editor and should work for any sort of text file. If the node needs additional info for regular connections, it is up to the node's sysop to schedule regular file requests to the nameservers that supply the additional info needed. (This might require a cascade of requests, depending on nameserver dependencies - posibily a "make" like utility could be used to generate the requests.) A compiled database would be a merge of the data files a node gets from its NC (or RC for independents) and any additional info the node fetches. Because the information supplied at each level only relates to that level and the levels just above and below, updates are mostly local in nature. There is no need to pass detailed network level info to the RC. All that is needed is for the NC to pass the local info, merged with the regional nameserver info to the network's nameservers and pass the network's nameserver info to the RC. Likewise the RC only needs to merge the regions indepent node info with the network nameserver info (passed up from the NCs) and zone level nameserver info (passed down from the ZC) and pass this to the regional nameservers and to pass info on the region's nameserver(s) to the NCs. Things are much the same at the zone level, except the ZCs pass their own zone level nameserver info to each other. Nothing like the full nodelist ever gets passed around. 6.0 Final Thoughts. ------------------- This document is by no means complete. It is intended as "food for thought". I hope that the members of the FTSC and others will read this and think about these ideas and maybe even setup experimental nameservers and see how it goes. I expect lots of feedback. Robert Heller 1:321/153 FidoNews 10-09 Page 11 1 Mar 1993 ---------------------------------------------------------------------- Published with permission from: EFFector Online Volume 5 No. 2 2/19/1993 editors@eff.org A Publication of the Electronic Frontier Foundation ISSN 1062-9424 Happy Anniversary ;-) Steve Jackson Games Case!! March 1st marks the three-year anniversary of the Secret Service raid on Steve Jackson Games. As we await Judge Sam Sparks's decision in this precedent-setting case, EFF would like to remind everyone of what has happened so far. In May of 1991, EFF reported about the case in issue #1.04 of EFFector Online: On March 1, 1990, the United States Secret Service nearly destroyed Steve Jackson Games (SJG), an award-winning publishing business in Austin, Texas. In an early morning raid with an unlawful and unconstitutional warrant, agents of the Secret Service conducted a search of the SJG office. When they left they took a manuscript being prepared for publication, private electronic mail, and several computers, including the hardware and software of the SJG Computer Bulletin Board System. Yet Jackson and his business were not only innocent of any crime, but never suspects in the first place. The raid had been staged on the unfounded suspicion that somewhere in Jackson's office there "might be" a document compromising the security of the 911 telephone system. In the months that followed, Jackson saw the business he had built up over many years dragged to the edge of bankruptcy. SJG was a successful and prestigious publisher of books and other materials used in adventure role-playing games. Jackson also operated a computer bulletin board system (BBS) to communicate with his customers and writers and obtain feedback and suggestions on new gaming ideas. The bulletin board was also the repository of private electronic mail belonging to several of its users. This private mail was seized in the raid. Despite repeated requests for the return of his manuscripts and equipment, the Secret Service has refused to comply fully. Today, more than a year after that raid, The Electronic Frontier Foundation, acting with SJG owner Steve Jackson, has filed a precedent setting civil suit against the United States Secret Service, Secret Service Agents Timothy Foley and Barbara Golden, Assistant United States Attorney William Cook, and Henry FidoNews 10-09 Page 12 1 Mar 1993 Kluepfel. "This is the most important case brought to date," said EFF general counsel Mike Godwin, "to vindicate the Constitutional rights of the users of computer-based communications technology. It will establish the Constitutional dimension of electronic expression. It also will be one of the first cases that invokes the Electronic Communications and Privacy Act as a shield and not as a sword -- an act that guarantees users of this digital medium the same privacy protections enjoyed by those who use the telephone and the U.S. Mail." As the case proceeded, the attorneys from George, Donaldson and Ford, who represented Steve Jackson, Steve Jackson Games, and Illuminati BBS users Elizabeth McCoy, Steffan O'Sullivan and Walter Milliken, decided to drop charges against all defendants except the United States Secret Service. (This was a strategic decision made to ensure that the trial would proceed in a timely manner.) The case went to trial in the United States District Court in Austin, Texas, from January 26 - 28, 1993. The plaintiffs presented their case first with testimony from all of the plaintiffs themselves, Secret Service Special Agents Timothy Foley and Barbara Golden, former U.S. District Attorney William J. Cook, Bellcore security expert Henry Kluepfel, University of Texas security guard Larry Coutorie, WWIV BBS software creator Wayne Bell and a financial expert who testified to the amount of damages. By the end of the second day, the plaintiffs rested their case. On Thursday morning, the defense put Special Agent Timothy Foley back on the witness stand. After he testified that he did not know that Steve Jackson Games was a publisher, that the seized computer equipment (3 computers, 5 hard disks, and more than 300 floppies) had not been accessed by Secret Service investigators after March 27, 1990, but was not returned to Steve Jackson until late June, and that no copy of the information contained on the seized disks (including a manuscript for an upcoming publication and the company's business records) was ever provided to Steve Jackson, Agent Foley sat through a solid 15-minute reprimand from the judge on the unacceptability of the government's behavior. The defense attorneys were so shaken by the judge's admonishments that they decided not to call any other witnesses. While Judge Sparks made it clear that he found the Secret Service's behavior to be reprehensible, it is not clear how he will rule in this case. The case was based on two rarely-construed federal statutes -- the Electronic Communications Privacy Act (ECPA) and the Privacy Protection Act (PPA). ECPA says that government officials may not read private electronic mail unless they have a warrant specific to that mail. No search warrant specified that Elizabeth McCoy, Steffan O'Sullivan or Walter Milliken had done any wrong, yet it appears that their mail -- in fact, ALL of the electronic mail contained on the system that ran the Illuminati BBS -- had been read and deleted by agents conducting the search at Secret Service headquarters in Chicago. PPA requires that law enforcement officers follow special procedures when the entity to be searched is a publisher, in order to FidoNews 10-09 Page 13 1 Mar 1993 protect the First Amendment freedom of the press. No special procedures were followed in this case. So even if the judge finds that Secret Service behavior was inappropriate, it is not so clear that he will find that the behavior was actually in violation of these statutes. We expect Judge Sparks will hand down his decision any time now. When it is issued, we will be sure to print the written opinion in an upcoming issue of EFFector Online. ============================================================= EFFector Online is published by The Electronic Frontier Foundation 666 Pennsylvania Ave., Washington, DC 20003 Phone: +1 202 544-9237 FAX: +1 202 547 5481 Internet Address: eff@eff.org MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION In order to continue the work already begun and to expand our efforts and activities into other realms of the electronic frontier, we need the financial support of individuals and organizations. If you support our goals and our work, you can show that support by becoming a member now. Members receive our bi-weekly electronic newsletter, EFFector Online (if you have an electronic address that can be reached through the Net), and special releases and other notices on our activities. But because we believe that support should be freely given, you can receive these things even if you do not elect to become a member. Your membership/donation is fully tax deductible. Our memberships are $20.00 per year for students, $40.00 per year for regular members, and $100.00 per year for organizations. You may, of course, donate more if you wish. Our privacy policy: The Electronic Frontier Foundation will never, under any circumstances, sell any part of its membership list. We will, from time to time, share this list with other non-profit organizations whose work we determine to be in line with our goals. But with us, member privacy is the default. This means that you must actively grant us permission to share your name with other groups. If you do not grant explicit permission, we assume that you do not wish your membership disclosed to any group for any reason. FidoNews 10-09 Page 14 1 Mar 1993 ============================================================= Mail to: The Electronic Frontier Foundation, Inc. 238 Main St. Cambridge, MA 02142 I wish to become a member of the EFF. I enclose: $_______ $20.00 (student or low income membership) $40.00 (regular membership) $100.00 (Corporate or organizational membership. This allows any organization to become a member of EFF. It allows such an organization, if it wishes to designate up to five individuals within the organization as members.) [ ] I enclose an additional donation of $_______ Name: Organization: Address: City or Town: State: Zip: Phone: ( ) (optional) FAX: ( ) (optional) Email address: I enclose a check [ ]. Please charge my membership in the amount of $ to my Mastercard [ ] Visa [ ] American Express [ ] Number: Expiration date: Signature: ________________________________________________ Date: I hereby grant permission to the EFF to share my name with other non-profit groups from time to time as it deems appropriate [ ]. Initials:___________________________ ---------------------------------------------------------------------- FidoNews 10-09 Page 15 1 Mar 1993 From: Doug Mclean@1:255/9 Having read the article about caller ID by Chris Farrar in Vol. 10 No. 8 of FidoNews, I thought some views from a sysop who has already implemented caller ID security on a BBS might be helpful. I have had caller ID security in place here for several months. Since my modem directly supports caller ID, and since I am a programmer, the cost of me setting this up was next to nil. The only cost at all was a slight increase in my monthly phone bill to pay for the caller ID feature. The software that I wrote runs on the Amiga computer (sorry MS-Dos users!) and is freely available to anyone who wishes to file request it (MSCID.LHA at 1:255/9). It requires TrapDoor 1.83, and DLG Pro BBS/OS, although it could probably be adapted to run with other software. The effort it took to program a caller ID system and the higher phone bill are small prices to pay when one considers the benifits that caller ID security offers to both me as a sysop *AND* to my users. Before I implemented caller ID security, my BBS occasionally got calls from fake users whose only reason for calling the BBS was to leave nasty messages to the sysop composed mostly of four letter words. While this was not a frequent event, it was still annoying. Most likely, the callers were irresponsible kids with nothing better to do with their evenings (I am *NOT* saying that all younger callers are irresponsible or cause problems, many of my users are young, very well behaved, and a pleasure to have as regular callers). With caller ID in place, all I have to do is look for the annoying call in my log, and instruct the BBS to hang up when it detects a call from that phone number (I also get a message from the software stating that a user was booted off because they called from a dis-allowed phone number). In my particular implementation, several other options are available besides simply hanging up. Another potential annoyance is the user who calls late at night, enters a fake phone number, and then proceeds to use a callback verifier. Although I don't run a callback verifier, I can see how it could easily be used to annoy innocent people in the middle of the night. I'm sure I wouldn't appreciate a call from a BBS at 3 in the morning generated by a fake number entered into someone callback software! Caller ID software can eliminate this potential problem. Imagine the supprise on the face of a bogus caller (who had planned to do nothing more than annoy the sysop) when they were told that the phone number that gave in their application is not the number that they are calling from, and that the sysop will be informed of their real number! I haven't had ANY bogus users since putting caller ID in place. Once this type of person knows that you know who they are, they are unwilling to risk entering a lot of messages to the sysop that contain little more than four letter words. This is especially true of younger callers (again, I am not trying to lump all younger callers into one group) who fear that a quick phone call to their parents could revoke their computer access, or worse. FidoNews 10-09 Page 16 1 Mar 1993 Caller ID security offers advantages to the user as well. How many times has a user called your BBS but is unable to remember his password? Have you ever gotten a message from one user asking for someone elses password because the other person has forgotten it? With caller ID, this can be a thing of the past. My users have the option of having the caller ID software log them into the BBS automatically, they do not have to remember their password or (even their name) as long as they call from their registered phone number. Obviously, households that have more than one computer user will not want to use this feature, but most of my users find it a great convenience! But before rushing ahead with caller ID security a sysop must consider several potential problems. Not all phone lines will send caller ID information. This is especially true in areas that are still in the process of implenting caller ID. These numbers will show up as either blocked or private numbers. The user has no control over this, and until the phone company upgrades their exchange there is nothing that they can do. Some people have unlisted phone numbers for perfectly valid reasons. These people usually have no objection to a sysop knowing who they are and what their phone number is, but they do not want their number listed in the phone book. Such a phone line will not send valid caller ID information, so these users must be validated by some other means. Finally, long distance calls may not send caller ID info. The caller ID systems are different in Canada than they are in the US, so calls to Canada from the US may show up as blocked, private, or long distance, depending on your phone system and theirs. Long distance calls within the same country can send a valid caller ID string, but the exchanges on both ends must support it. As more phone companies upgrade their systems more phone numbers will send the required information, but for now caller ID is rather rare on long distance calls. One more dis-advantage of caller ID security is that the information is sent between the first and second rings. Calling long distance takes longer than calling locally (depending on how that call is routed and where you are calling, I have seen it take up to a minute to connect on a long distance call). Some people have their modem or software set to time out too quickly. Since my BBS now must answer on the second ring, occasionally when it answers there is nothing but a dial tone because the modem on the other end didn't wait long enough. As more and more sysops are implementing caller ID security, people will have to allow their modems to wait a little longer for a connect, especially on long distance calls. Caller ID is a fairly new technology that people will have to get used to. If every complaint about a new technology resulted in the supression of that technology, we would all still be living in caves eating raw food because someone would have banned fire. Caller ID can offer benefits not only to the sysop, but the user as well. In my experience, the only people who complain about it are the few people that complain about everything anyway. Most of my users like the faster and more convenient automatic login capability, and I like the increased security. Caller ID is a good thing, and it is here to stay. FidoNews 10-09 Page 17 1 Mar 1993 Doug McLean 1:255/9 ---------------------------------------------------------------------- The Youth of FidoNet, Part II by Ryan Park (1:232/19) I read Isaac Salpeter's article in last week's FidoNews ("The Youth of FidoNet") with interest. I believed everything he said, as I have had first- hand experience. I am 13 and also run a BBS, the QCC-NET BBS. My board is not a "hacker board" and in no way reflects my age. When people read my bulletin about the SysOp, they don't believe I'm 13! I started my bulletin board as "Da Board!" in September. Since December, I get 10-20 calls each day on my 17-hour BBS; many more than other full-time BBS's in our area. And just like Isaac, I have had a lot of experience with computers. I got my first computer, a Texas Instruments 99/4A when I was four and learned to read by reading the programming manuals. I learned BASIC and by the time I was six, I was writing simple programs. When we went on vacation and stopped at a computer store, the owner figured I was just playing with the keyboard. But he saw me type RUN and saw a wonderful program with sound, colours, and more appear! Since then, I have written some freeware and am writing my first "professional" program now. I applied for a FidoNet node in November to the hub at 1:232/400. He turned down my request because he thought Lee Busby, net 282's NC, would turn me down because of my age. Obviously, I was very upset with this. I reviewed POLICY4 and left messages on other FidoNet systems to the SysOps explaining this, who had no idea why I was turned down. Instead, I started my own network in January and have added both FidoNet nodes as well as QWK nodes. While it is small, it carries echos all over our area and accomplishes what I wanted to do in FidoNet --- start a local echo. After mentioning this in a number of international conferences such as OTHERNET, I decided to reapply to net 232 in January. Lee Busby was very helpful and agreed to my request. He said that the power of the hub "got to his head" and didn't think it would happen again as the person moved away from the area. But I've seen this type of behaviour once too many in FidoNet: people losing access, node numbers, or being denied node numbers altogether because of their age. A 14-year-old SysOp in my area applied in net 283 for a node number. While the NC was quite helpful, other people failed to reply for inquiries about a front door for the Amiga. While it was just because they didn't know of any, or they were "prejudice" against him because of his age, no one knows. FidoNews 10-09 Page 18 1 Mar 1993 I'm not doing this to flame anyone, certainly not Lee Busby. Instead, I think (as well as many other people) that it's time for a major policy revision. POLICY4 was written years ago, and POLICY5 is needed badly for this and many other issues (namely the elections, as Zone 1 has had a major problem democratically electing a ZC.) There have been so many teenagers writing Fido-News in the past requesting fair treatment that I feel this issue should be addressed soon. What _are_ the rights of minorities (including age, race, and sexual preference) in FidoNet? Is FidoNet going to become "adults only" like the others are? I hope this isn't the case. Unless the international policies include a non-discrimination clause in them with references to young adults also, FidoNet will be "going to the dogs". ---------------------------------------------------------------------- Steve Mulligan 1:163/307.30 Well, I get the point people. Points are just glorified users. Sure. I'll let you have that. As long as you realize that Private Nodes are just glorified points. And nodes are just glorified Private Nodes. I'm still not happy with the points-are-JUST-users image but I can't do much about it. What I have done is tried to start a point-nodelist. The point-nodelist is a list of all the points and their private net numbers. I know there will probably be conflicting private net numbers but that is something that we can work around. The point- nodelist is in no way a replacement nodelist. It is just something to be added when you compile your full nodelist. I use XLAXNODE and it has a MYLIST command which works quite nicely to do this. eg: MYLIST PRIVLIST.### To be placed in the point-nodelist, all you points have to do is send me your bosses Private Net number, your bosses address (who must be in the nodelist), your point number, the name of your point system, the city the point system is located in and your name as you want it to appear in the point-nodelist. (Send to : Steve Mulligan 1:163/307.30) I will use MAKENL (wow, and you though you had to be a ZC to use MAKENL) every two weeks to generate an updated point-nodelist. If there are a lot of submissions I will increase the rate to one week. You can then FREQ the file from 1:163/307 with the magic filename of PRIVLIST every Friday that it is released. If you have to take your point system down for a long period of time, it is recommended that you NetMail me saying you want your node taken out. FidoNews 10-09 Page 19 1 Mar 1993 I also need some help. I would like to have this distributed the same way the FidoNews and other nodelists are distributed but I don't know how. I also only support points from zone 1. I'm not an advanced MAKENL user (I'd have to be a ZC before I could call myself that!). So, all you points, send me all the information and you can finally be in a nodelist! Steve Mulligan 1:163/307.30 ---------------------------------------------------------------------- By Jason Garneau 1:325/304 H-Net (Handle-Net) Opening March 6,1993! / / /\ -------------------- / / / \ / / / /----/ ---- / \ / /----- / / / / \ / / / / / / \/ ---------- / -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- H-Net started out as a local message base on Online World BBS. The purpose was to allow users on my BBS to talk with other users on my BBS with handles instead of their legal name. This has worked out really well on my board, but running out of a small village in Northern Vermont, there are very few local users. Users started to tell me that I should make H-NeT a national echo so they could talk with other people from around the U.S. I decided about three or four months ago that I would give it a try. I started advertizing H-Net in the Vermont SysOp echo, and New England SysOp echo. Some SysOps in Vermont seemed interested, but many didn't like the idea of their users using handles to talk with other users, and yet others thought it would end up being a flop, and no one would use it (99.9% of all VT echos are "dead"). I decided not to give up. I have successfully gotten H-Net onto three other Fidonet BBS systems, and will soon be on a Non-Fido BBS. For the past 3 months, H-Net has successfully worked using Fidonet Addresses. I have had two Non-Fido BBS Sysops asking to join, but did not want to join Fidonet due to the large and costly echos. I could not give them H-Net access because they would first need a Fidonet address. This is where H-Net broke away from Fidonet Addresses. H-Net will be operating on Zone 11 by March 6th, 1993. H-Net is complete with it's own H-Net Policy 1.01, HNETECHO.xxx, HNETFILE.xxx, and the HNETLIST.xxx. These files are hatched via Tick to all nodes once a week on Fridays. This way, you can compile it at the same time as your Fidonet Nodelist. H-Net also has it's own H-Netmail similair to Fidonet's NETMAIL. FidoNews 10-09 Page 20 1 Mar 1993 H-Net's policy is totally Democratic. As we have been hearing, Fidonet's South American Region has been taken over almost like a dictator. With H-Net Policy 1.01, Elections to all positions are required every two years or less. If someone has become a dictator, the individual nodes below him/her can appeal to the H-Net Court which is ran by all of the RC's with the exception of the involved region(s). If found guilty of breaking a policy rule, they will lose their position, and possibly their node number (depending on how serious the violation). This system is designed to help keep H-Net a 100% democratic network. Policy 1.01 is in effect for all Regions and continents so all regions are equal. H-Net is still one of the smallest networks around. We listen to users' opinions and are willing to please the public. We are dedicated to making the people happy. Although this is Handle-Net, sysops with BBS programs not supporting handles can apply, and are allowed to use real names. And, for you power-hungry sysops out there: Since H-Net is just starting out, we have hundereds of positions such as RC, REC, NC, and NEC's to fill. So, if you are interested in becoming one of these positions, they are on a First-come, First-serve basis. Just to show what we have available for positions: Regional and Network Positions: Virginia, West Virginia, Kentucky, Tennessee, North Carolina South Carolina, Georgia, Alabama, Florida, Mississippi, Louisianna Arkansas, Missouri, Illinois, Indiana, Ohio, Wisconsin, Minnesota, Iowa, Oklahoma, Texas, Kansas, Nebraska, North Dakota, South Dakota, Montana, Wyoming, Idaho, Washington, Oregon, California, Nevada, Alaska, Hawaii,Delaware, D.C., Maryland and all other countries than USA. Network Positions: Maine, New Hampshire, Massachusetts, Rhode Island, Connecticut, New York Pennsylvania, New Jersey, Utah, Arizona, and New Mexico. Well, that just about concludes this article. If you are interested, Send the below application form crash Netmail to Jason Garneau at 1:325/304. Call back after 48 hours, and you will receive the latest HNETMEMB.ZIP which will always inclose the latest HNETLIST.xxx, HNETECHO.xxx, HNETFILE.xxx, and HNETPOL.101. -------------------------------------------------- | H-Net - Handle-Net Application Form Version | | 1.00 | | Taken From Fidonews Elecronic Newsletter | |------------------------------------------------| | Name - First _________________________ | | Name - Last _________________________ | | BBS Name ________________________________ | | Fidonet Node Number (if one) __:____/____ | | Flags (CM,XA,V32BIS,etc)___________________ | | ____________________________ | | Applying for (check all that apply) | | ( ) NC ( ) NEC ( ) RC ( ) REC | | ( ) Node ( ) Point ( ) ZC ( ) ZC | | ( ) Other _____________________________ | | Mother's Maiden Name (for Security reasons) | | _____________________________ | | BBS Telephone Number (___) ___-____ | | European - FidoNews 10-09 Page 21 1 Mar 1993 ___________________ | | Voice/Telephone Number (___) ___-____ | | European - ___________________ | | City, State (Province), Country: | | __________________________________ | | Baud Rate (Check all that apply) | | ( ) 300 ( ) 1200 ( ) 2400 ( ) 4800 | | ( ) 7200 ( ) 9600 ( ) 14400 ( ) 19200 | | ( ) 38000 ( ) Other _________ | | | -------------------------------------------------- If your system does not use Fidonet Netmail, Log on my BBS at (802) 873-9443, and upload this message by entering an ASCII upload in the full-screen message editor. Hope to see you online soon! - Jason Garneau (ZC-11 - H-Net) Jonathan Comtois (NC-100 - H-Net) ---------------------------------------------------------------------- By Kevin Higgins, 1:128/74 H2H_ACS : The new Head-To-Head Air Combat Simulations Echo I recently purchased a game which is literally THE most realistic com- bat flight simulator for WWI/WWII/Korean War aircraft (actually, it's not a full-fledged "game," but a Front End (FE) for a multi-player game called Air Warrior, which is available on GEnie Information Services. In the past I've flown most of the successive generations of F-15/F-16 flight simulators in between eras of dabbling in WWI and WWII simulations. Obviously, I've long been an afficianado of combat flight simulations, and probably like most of you who share a similar interest, have found that sooner or later (usually sooner) the computer drones against which you're supposed to fly prove to be very limited opponents indeed--either that, or you find out that they don't have to fly using the same laws of physics or aircraft performance that you do (a discovery that usually results in my tossing the game onto the "yeah-it's-an-okay-game-but-I-don't-play-it-anymore" shelf. The fact that I can't realistically expect a simple program to compete in the fluid arena of ACM (Air Combat Maneuvers) against a human opponent never seems to dampen my disappointment. But there's another facet of many combat flight simulations that often gets overlooked, and that's head-to-head combat--flying against your friends (or enemies) via modem! Often, the reason this facet of the games gets overlooked is that many of our friends, quite unreasonably, don't share our addiction to cutting through the air in maniacal maneuvers, getting onto another human's six (tail, for you non-fighter pilot types) and blazing away until he and his plane are shot to doll rags! FidoNews 10-09 Page 22 1 Mar 1993 Well, I say enough of this lack of fodder--er, competition! The H2H_ACS (Head-to-Head Air Combat Simulations) Echo is a meeting ground for us chairborne aces where we can discuss ACM tactics and strategy with other predatory types; where we can tell completely true stories of our exploits in the virtual atmospheres created for us my MicroProse, LucasFilm Games, Electronic Arts, Konami and others; and where we can coordinate to fly against other people foolish enough and audacious enough believe they could last for five minutes in the air with us before finding they were trying to pilot a smoking sieve which suddenly has all the flight possibilities of a brick! We will also use this echo to advertise and announce the availability of missions (for File Request or download) we've created using those games that include mission-building utiltities, and perhaps hold con- tests to see who can fly some of these custom scenarios with the most success. The possibilities are endless and we hope to explore as many of them as possible. Netmail or areafix Kevin Higgins, at 1:128/74, if you're interested in joining the H2H_ACS echo. Until we can get this baby on the backbone, I would prefer systems to poll at least twice a week. ---------------------------------------------------------------------- A New Star Trek Echo - KLINGON By Ray Brown, Vice-Moderator SysOp, SpacePort Miami, 1:135/70 "Tlhlngan Hol Dajatlh'a'?" ("Do you speak Klingon?") Greetings and salutations, fellow Trekkers/Trekkies! I'd like to announce a new echo, called KLINGON. This echo is for discussion of any aspect of "Klingons", the alien race, as seen in many of the various Star Trek episodes and Movies. The topic of discussion will be _ALL_ things that relate to Klingons, period. This will include, but not limited to, any activities of the various Klingon fan organizations, such as the Klingon Assault Group and Klingon Legion of Assault Warriors, (KAG and KLAW), or trying to write and talk in Klingon (as in the above example), or just to learn more about the Klingon "way of life" (grin). Rembember, bashing or flaming the United Federation of Planets, or members of "Federation" Star Trek fan orgainzations, is really frowned on. (Remember, we'll be ALLIES with the Federation in the 24th Century.) FidoNews 10-09 Page 23 1 Mar 1993 This new echo is currently seen on over 12 BBS's that are members of TrekNet (Z87). However, this echo is available to any and all that are interested in the Klingon way of thinking. For linking information, please contact me via NetMail, and I'll see if there's a BBS near you that's carrying KLINGON. Or, you may wish to have mail on HOLD here at 1:135/70 for you to pick up. If the number of BBS's and activity picks up, we will strongly consider requesting that KLINGON be placed on the FidoNet BackBone. Qapla!! (Success!!) Scott Kuhr Ray Brown Moderator Vice-Moderator 1:363/91 1:135/70 ---------------------------------------------------------------------- TWO NEW BLINDNESS-RELATED ECHOS NOW AVAILABLE by David Andrews, Fidonet 1:261/1125 Two new blindness-related Echos are now available via the Fidonet Zone 1 backbone. Both of these Echos, NFB Talk and Blind Talk, have been started by the National Federation of the Blind (NFB). The NFB is the oldest and largest organization of the blind in this country with over 50,000 members. There are state affiliates and local chapters in all 50 states, Puerto Rico, and the District of Columbia. Founded in 1940, the NFB is dedicated to the complete integration of the blind into the economic, political, and social community. NFB Talk is for the dissemination of news and information about the NFB and its activities. It is also intended for the discussion of NFB's philosophy of blindness and topics of specific interest to members of the National Federation of the Blind and our friends as they relate to the NFB, our policies, activities, and philosophy. Blind Talk is for the discussion of general topics of interest to blind and visually impaired persons, our friends and relatives, and anyone else who is interested. Possible topics include, but are not limited to, computers and adaptive access technology, Braille and Braille literacy, cane travel, guide dogs, alternative techniques of blindness, etc. This Echo is intended to promote the positive philosophy of blindness developed and promoted by the National Federation of the Blind. Blind Talk also provides access to the resources and information provided by the International Braille and Technology Center for the Blind, the world's largest demonstration and evaluation center for computer technology used by blind persons. FidoNews 10-09 Page 24 1 Mar 1993 NFB Talk and Blind Talk originate at 1:261/1125, NFB NET, the bulletin board sponsored by the National Federation of the Blind. NFB NET, which can be reached at (410) 752-5011, contains a variety of files of interest to blind computer users. There are also a variety of materials concerning the Americans with Disabilities Act (ADA). NFB NET is also the home of the Braille Monitor, the monthly publication of the National Federation of the Blind, Future Reflections, for parents of blind children, and the newsletter of the NFB in Computer Science. All of these publications are available in electronic form and can be file requested from 1:261/1125 using the magic file names MONITOR, KIDS and COMPUTERS respectively. You can request NFB Talk and Blind Talk from your regular Echo source. The Echo Tags are NFB-TALK and BLINDTLK. If you have questions, please contact the Moderator, David Andrews, at Fidonet 1:261/1125. ---------------------------------------------------------------------- FidoNews 10-09 Page 25 1 Mar 1993 ====================================================================== FIDONEWS INFORMATION ====================================================================== ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ---------------- Editors: Tom Jennings, Tim Pozar Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been changed!!! Please make a note of this. "FidoNews" BBS FidoNet 1:1/23 <---- NEW ADDRESS!!!! Internet fidonews@fidosw.fidonet.org BBS +1-415-863-2739, 300/1200/2400/16800/V.32bis/Zyxel (Postal Service mailing address) (have extreme patience) FidoNews c/o World Power Systems <---- don't forget this Box 77731 San Francisco CA 94107 USA 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 1992 Tom Jennings. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or FidoNews (we're easy). OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic form may be obtained from the FidoNews BBS via manual download or Wazoo FileRequest, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained from Fido Software for $10.00US each PostPaid First Class within North America, or $13.00US elsewhere, mailed Air Mail. (US funds drawn upon a US bank only.) BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21, 1:125/1212, (and probably others), via filerequest or download (consult a recent nodelist for phone numbers). A very nice index to the Tables of Contents to all FidoNews volumes can be filerequested from 1:396/1 or 1:216/21. The name(s) to request are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985... through 8=1991. FidoNews 10-09 Page 26 1 Mar 1993 INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in directory ~ftp/pub/fidonet/fidonews. If you have questions regarding FidoNet, please direct them to deitch@gisatl.fidonet.org, not the FidoNews BBS. (Be kind and patient; David Deitch is generously volunteering to handle FidoNet/Internet questions.) 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 BBS, or Wazoo filerequestable from 1:1/23 as file "ARTSPEC.DOC". Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and are used with permission. Asked what he thought of Western civilization, M.K. Gandhi said, "I think it would be an excellent idea". -- END ----------------------------------------------------------------------