F I D O N E W S -- | Vol. 9 No. 41 (12 October 1992) The newsletter of the | FidoNet BBS community | Published by: _ | / \ | "FidoNews" BBS /|oo \ | (415)-863-2739 (_| /_) | FidoNet 1:1/1 _`@/_ \ _ | Internet: | | \ \\ | fidonews@fidonews.fidonet.org | (*) | \ )) | |__U__| / \// | Editors: _//|| _\ / | Tom Jennings (_/(_|(____/ | Tim Pozar (jm) | | | Newspapers should have no friends. | -- JOSEPH PULITZER ----------------------------+--------------------------------------- Published weekly by and for the Members of the FidoNet international amateur network. Copyright 1992, Fido Software. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact FidoNews. Electronic Price: . . . . . . . . . . . . . . . . . . . . . free! Paper price: . . . . . . . . . . . . . . . . . . . . . . $10.00US For more information about FidoNews refer to the end of this file. -------------------------------------------------------------------- Table of Contents 1. EDITORIAL ..................................................... 1 Editorial: Can't tell you, it's secret ........................ 1 2. ARTICLES ...................................................... 3 A Comparison of Mail Tossers .................................. 3 Region 12 ..................................................... 7 Security and authentication using PGP in FidoNet .............. 8 Privacy and Computer Compatibility ............................ 12 CLINTON'S ECONOMIC PLAN AVAILABLE HERE ........................ 13 The Brigadoon Village Network ................................. 13 WorldPol: Your Opinion Counts ................................. 14 H-NeT soon to go national ..................................... 15 LE_CLUB: The FidoNet Veterans Club! ........................... 15 3. FIDONEWS INFORMATION .......................................... 17 FidoNews 9-41 Page 1 12 Oct 1992 ====================================================================== EDITORIAL ====================================================================== Editorial: Can't tell you, it's secret ANGRY RANT MODE ON: OK, so this rant is specific to my installation, though there's a lesson in it for everyone. I hope. I can't believe the number of sysops who must simply copy a bunch of programs in and hack at files, then walk away from their systems, assuming everything will just someow work out OK. YOU WOULD NOT BELIEVE the nonsense I get here at magic address 1:1/1. Every brain-damaged mailer in the world -- an amazing number of popular programs, which I won't list only because I don't want to put up with email from disgruntled authors and their user-defenders -- sends mail to zone 1 net 1 node 1 when they get "stuck". Anyone ever heard of "error checking"? Anyone heard of (ORPHAN) status?! (As a specific technical aside, I'm surprised at how few systems handle INTL lines, and how many don't even generate them! WARNING: do not send me ONE SINGLE MESSAGE why it's OK to not generate one, or I will ridicule you in public.) Is it not obvious that you might want to watch your system make a phone call or two before you turn it loose on the world? Look at logs occasionally, especially when lusers complain of lost mail? As of today, I'm still getting mis-routed echomail from [note1], and in it, the lusers are complaining that they're not seeing their mail! No one even checked a log file? Watched a modem dial? In techie circles, the argument pops up all the time, "Why should my program check entered messages against the nodelist, the mailer will take care of it.". People calling for a "decoupled" network, where you don't know node numbers, only net numbers, or other variations. It's called THE ERROR CASE. Fact: things frequently go wrong. Handling ERROR CASES, not FEATURES, is the mark of good software. I'm not kidding! I am seriously thinking of abandoning the "1:1/1" historic number, in favor of ANYTHING THAT WILL GET ME AWAY FROM DUD MAILERS AND BRAIN-DEAD SYSOPS!!! ANGRY RANT MODE OFF. FidoNews 9-41 Page 2 12 Oct 1992 * * * * * Last week, in writing briefly about privacy and encryption, I mistakenly gave the impression that I thought sysops should be required to accept encrypted messages on their BBSs. That was not my intent; I didn't give enough qualifying information. My apologies. What I meant was, for transient mail flowing through a system, such as a net host, where it is arguable you have carrier status, legally, anyways. Not for your BBSs message section. I am sorry if this sounded threatening to you. And to Michael Toth, who sent me an intelligent message I wrote a (hopefully equivelant) response to, but lost your email address: please send me your address, and I'll forward my reply. -------------- (note1) I had someone's node address here, but lucky for them, they fixed it before this was published. ---------------------------------------------------------------------- FidoNews 9-41 Page 3 12 Oct 1992 ====================================================================== ARTICLES ====================================================================== By Charles Buchanan 1:3812/10.6 A Comparison of Mail Tossers I guess that I better start off by telling you what is meant by a mail tosser. All of the echomail that goes throughout Fidonet is sent along in mailbags from different systems with all of the messages from all the different echomail areas bundled together. They are not separated and sent each in their own area. So when a mailbag arrives, it has one or several *.PKT files inside of it that need to be sorted and put into the correct echomail area. The mail tosser is the program that puts the messages into the correct areas as well as into the correct directories on your disk. It will also create indices or at least a supplemental utility will. This is a very basic explanation of a mail tosser and what it does. Some mail tossers have alot of different features but I don't plan to talk about that. There are 3 different types of message bases -- Fidostyle, Hudson, and Squish. Each of the three types has their own good points and bad points. So I guess that is why there are so many different mail tossers around. Here is general overview of what these 3 different types of messagebases are : Fidostyle -- Messages from each echo (or conference) are in separate files as well as separate directories. Each of the messages are in a separate file that are of the form *.MSG Hudson -- All of the messages are kept in one file and the indices, lastread pointers, and users are kept in separate files. So the actual message base has all of the messages from all echos in one file. The format of the Hudson message base is *.BBS for all of the files needed. Squish -- Squish is sort of a cross of the two types above. Squish keeps each echo separate in it's own messagebase but they can all be in the same directory. Squish also keeps separate dupes, and pointers for each messagebase. That is very basic explanation of the three types of messagebases that I'm just barely familiar with and how I understand them. I'm an expert by no means and I welcome clarification on anything that I've gotten wrong. I operate as a point and I use a mail tosser for all of the mail that comes into me. After I was struck by the infamous Feb 29 bug that made some mail tossers choke, I started looking around at what was available. I noticed that there are quite a few mail tossers. Some have more features than others. Some are very simple and others are quite complicated. FidoNews 9-41 Page 4 12 Oct 1992 One of my favorite echos that I like to participate in is POINTS. There was a discussion a few weeks ago about different tossers, speed, features, space used and other things. I was told that Squish actually uses less diskspace for the message base than Hudson. So I kept a couple of my old mailbags to try Squish for myself. Then tossed the same mailbags with a Hudson style tosser. There was indeed a difference in the speed and the space used by both. This then got me curious about other mail tossers and how they compared ? I also wondered if all Hudson style mail tossers were the same ? Well, I was surprised by what I found out !! My comparison in this article is really limited to three criteria -- speed, space used for the messagebase, and point awareness. The point awareness is by neccessity since I operate as a point and all of my old mailbags have my address in them as a true 4-D address. This means that I could not try a tosser that either -- 1) Would not support 4-D addressing or 2) Required a pointnet or a fakenet addressing scheme. I also did not want to compare all of the bells and whistles and how many of each they all had. When I looked at these tossers, I set them up as I would use them -- maybe not how other people would use them. So this means that this comparison is not real scientific nor is it the most complete comparison. But speed and diskspace usage are a common factor in all of them. Now I'll explain my setup and how I did my comparisons. I setup each of the mail tossers and made sure that they would work for me. Then I created a batch file that would try each of them out and recorded the results. Since the unarchiving of the mailbags would always be the same, I did that first and just kept the *.PKT files in my inbound directory. I also deleted the messagebase directory of all files first. I created all needed directories and files. So here is a list of how I started out before I invoked any of the mail tossers. Delete all files from inbound directory delete all files from messagebase directory Delete all log files delete all bad files and dupes move *.pkt files to inbound move empty messagebase files to messagebase directory And here is the system I'm running on : 386/20 DX DOS 5.0 640k cache with staged writes 4DOS 4.01 4 megs of ram with 1.5 ramdrive for swapping if needed 110 Meg ESDI 16ms access hard drive This is my normal setup. But for this comparison, I disabled the cache completely. The actual times are not important and should not be taken as written in stone. What is important, is the ratio in the different times. So if my setup shows something different, it will depend on your setup. Using a cache should also speed up the tossing time as well. It might be something like this : FidoNews 9-41 Page 5 12 Oct 1992 mine 486/33 XT Tosser A 20 secs 10 secs 40 secs Tosser B 15 secs 7.5 secs 30 secs As some commercials state, "Your mileage my vary". I used 31 *.PKT files from 4 different networks. They were all different sizes and contained 650 messages total. I'm not going to put the logfile results in this article because some of them are quite lengthy. It also would not serve much purpose. The times that I have were created using the 4dos Timer command. I started the timer, invoked the tosser, and then turned off the the timer. So the times shown are actually a little longer than the actual times as reported in the logfiles. I thought that if I did this for all of the tossers, it would be a bit better for comparisons. Some logfiles showed start and stop times but not how long they were active. And rather than make a mistake in my calculations, I thought that I would let 4dos do the arithmetic. I also show two results for the space usage. One is space allocated and the other is space used by files. Here is a list of the tossers that I tried and the versions : Ezpoint 2.2 (Unique, points only) Fastecho 1.20A (Hudson) Fmail 0.92 (beta) (Hudson) Freemail 1.00 (beta ?) (Hudson) Gecho (beta) (Hudson) Imail 1.21A (Hudson) Ppoint 1.35 (Unique, points only) Qecho 2.75 (Hudson Qmail 1.30 (gamma) (Fido style) Spoint 1.20 (Hudson) Squish 1.01 (Squish) Zztoss (beta) (Hudson) And here is a table of the combined results : Time Files Bytes Bytes Allocated Ezpoint 2:58.13 28 607,520 632,832 Fastecho 0:28.29 9 928,664 937,984 Fmail 0:37.63 9 931,224 940,032 Freemail 2:13.79 9 991,896 1,001,472 Gecho 1:04.59 9 839,832 847,872 Imail 5:10.11 9 839,320 847,872 Ppoint 3:18.56 53 799,028 862,208 Qecho 2:24.45 9 812,696 821,248 Qmail 4:08.10 869 1,120,556 1,802,240 Spoint 1:01.30 9 928,664 937,984 Squish 2:54.50 81 930,492 1,005,568 Zztoss 1:30.03 7 840,042 845,824 FidoNews 9-41 Page 6 12 Oct 1992 Tossers from fastest to slowest : 1 Fastecho 0:28.29 2 Fmail 0:37.63 3 Spoint 1:01.30 4 Gecho 1:04.59 5 Zztoss 1:30.03 6 Freemail 2:13.79 7 Qecho 2:24.45 8 Squish 2:54.50 9 Ezpoint 2:58.13 10 Ppoint 3:18.56 11 Qmail 4:08.10 12 Imail 5:10.11 Disk Usage (File bytes) least to most : 1 Ezpoint 607,520 2 Ppoint 799,028 3 Qecho 812,696 4 Imail 839,320 5 Gecho 839,832 6 Zztoss 840,042 7.5 Fastecho 928,664 7.5 Spoint 928,664 9 Squish 930,492 10 Fmail 931,224 11 Freemail 991,896 12 Qmail 1,120,556 Disk Usage (Allocation bytes) least to most : 1 Ezpoint 632,832 2 Qecho 821,248 3 Zztoss 845,824 4.5 Imail 847,872 4.5 Gecho 847,872 6 Ppoint 862,208 7.5 Fastecho 937,984 7.5 Spoint 937,984 9 Fmail 940,032 10 Freemail 1,001,472 11 Squish 1,005,568 12 Qmail 1,802,240 Summary : --------- FidoNews 9-41 Page 7 12 Oct 1992 This is not meant to be an endorsement of any tosser nor is it meant to put down any tosser. It is not meant to be "The Definitive Test". As I stated to begin with -- I set these tossers up according to how I would use them. Everyone has different needs. Some of these tossers will only work within their own enviornment, others may be used by lots of other programs. Some of the tossers are only for point systems. Others are Hudson style mail tossers and Squish has it's own format. Qmail is a Fido style mail tosser. It is also up to the individual person which format they prefer. Is speed is more important than space used or the other way around ? What about cost ? Do you want the messagebase in one file ? Or do you want the areas separated ? Some of these tossers are in testing stages, some are fairly new, others are well proven. And I found that some tossers are quite easy to setup while others are a bit more complicated. Some have a setup program while others require you to edit a configuration file. I thought that I share some results with you about what I found out when looking at these tossers. All of them work well and are worth taking a look at. Feel free to send comments to me : Charles Buchanan 1:3812/10.6 ---------------------------------------------------------------------- By: Mark Skaff (1:163/525) The majority's viewpoint on the Region 12 election situation In reponse to Gordon Chapman's (1:163/150) article on Region 12 last week, I wish to submit this article to show the viewpoint of not only myself, but the viewpoint of many other sysops in the region. To commence the article, I will tell you about my viewpoint on the Region 12 situation. Simply put, I voted NO in our local Network to have an election. I have several reasons for this, and one is; Policy clearly says that Regional co-ordinators are elected, not appointed, and tradition or no tradition, that should be the way our Region should be conducted, whether a small amount of sysops in Region 12 want it, or not. There is no reason why our Region should be different from others in this major aspect. The reason I say "small amount of sysops" is because the polls and petitions have not encompassed many sysops in the networks. Recently, a sysop clarified the fact that less than 20% of sysops in the region have voted in the polls issued in their nets, to be represented by their NCs for RC election (See next paragraph about polls, etc.). This sysop also stated that less than 20% of Net 163 voted. Yet, Mr. Chapman is demanding an election. It looks as if not that many sysops really want one. FidoNews 9-41 Page 8 12 Oct 1992 Some readers may not know what I am referring to when I talk about the polls, etc. Well, to sum that up, a poll of the Sysops in the nets of Region 12 was done by the NCs, and was to be reported to the RC. The poll focused on a question with this nature; "Do you wish to have an election for Regional Co-ordinator?". The outcome of this was 75% - NO (no election) and 25% - YES (supporting election). After this fatal blow to the NO side, Mr. Chapman decided to try another poll. Except, this time, he put together a _petition_, which exists as I type this. It seems that every second message in REG12 currently, is propaganda to get people to sign the petition, or a discussion about it. May I also supplement; Bryan Hochberg, who is our current Regional Co-ordinator, has done a good job on his duties as an RC. I am happy with the way he handled an appeal of a recent policy complaint. I have no complaints to the way he handles mail, and lastly, he contacted the ZC in appropriate situations, and did not let certain matters fall into his own hands. Regardless if Mr. Hochberg is a temporary RC or not, he will hopefully remain here for the time being, and as far as I'm concerned, will remain here until we willingly resigns. By Policy, Bryan should keep his position as Regional Co-ordinator, and no election should be held. ---------------------------------------------------------------------- THOUGHTS ON SECURITY AND AUTHENTICATION FOR EMAIL SYSTEMS Tom Jennings (1:125/111) Some ideas on public key security systems. To sum up ahead of time, I assert that the public broadcasting of public keys is more than enough security and authentication for casual, privacy needs in the FidoNet or other email network. All of this article assumes the use of PGP version 2.0, the RSA double-key encryption system implemented as freeware. This is all new to most of us, this security/privacy thing. Both technologically and socially. What privacy we have we take for granted without much thought; letters in envelopes, "who is it?" to knocks on the door, etc. When we try to break down these things into their underlying assumptions, well, it's hard. We shouldn't get upset with ourselves or others if "we don't get it" right away. And we'll find some obvious things aren't, and vice versa. I will assume that if you really, really need utter absolute security, you can achieve that with PGP or whatever. If it's that sensitive, sending it over an electronic medium probably isn't recommended. This article isn't about how to achieve bank-vault security. FidoNews 9-41 Page 9 12 Oct 1992 Within the FidoNet, the most common use we all seem to talk about is PRIVACY, rather than SECURITY. I can only speak for myself, but, my netmail (not echomail) traffic is probably a reasonable example. I read about 100 messages a week, and send out about 50. There's a dozen or so people I talk with regularly, and about 50 per week that I do not know. Most of it is of the "Oh yeah, so and so said this. How's your mother. Did you get that file OK...". Even if an eavesdropper read this stuff, I would barely care. There are some times though when revealed message contents could be... personally compromising. Embarrassing. A real life example: a long time ago, a sysop in a net was having trouble with their net host. Some messages critical of that net host were intercepted by the host, some passed on, and some we each got replies to! Not Good. What *I* want is a way to ensure that sometimes, only the addressee can read a given message. I am willing to pay some penalty for this, but I won't live with a system that restrains me like a stone castle and moat. My needs and risks just aren't that great. With that as a background assumption, let's look at two separate issues that look at first to be the same -- SECURITY and AUTHENTICATION. SECURITY -- given an encrypted message, how likely is it that someone can ascertain what's inside it (assuming you're not the addressor or addressee)? As an operating assumption, I will take it for granted that PGP produces files that are secure in themselves (barring bugs, etc). Like the docs say, a frontal cryptological assault is hard, and in our casual privacy case, probably not what we've got to worry about. There are other ways to figure out what's going on. Imagine you're that net host. You've had trouble with this particular sysop before. You notice he's just sent a flurry of messages to the local RC, then the ZC. Hmmm!! Do you really need to know what's in those messages?! (This is called traffic analysis. In pre-WWII Germany, the Nazis tracked down "Jew sympathizers" with traffic analysis of telephone billing information; Europeans don't get itemized phone bills any longer... like here in the US. So I was told, the information is no longer kept. (Do I really believe that...:-)) Anyways, security is more than cryptographic strength. Turns out, there's a way around this: anonymous remailers. In a private Internet mailing list Eric Hughes came up with a trick to anonymously remail messages; you send mail destined for system X to the remailer instead; it strips off the header info and mails it to system X. Anonymity isn't really needed though in the case above, simple remailing will do. Again, our *general* FidoNet needs are modest. FidoNews 9-41 Page 10 12 Oct 1992 AUTHENTICATION is the sticky one for us. Authentication is determining: is this person really the person they say they are? But I think you'll see it isn't the fatal problem it appears to be at first. Let's get the obvious case out of the way first again: if you need utter and absolute security, you better damn well know the person ahead of time, you should get a key delivered by hand, and you should think about if you really want to conduct business over an electronic link in the first place. Authentication in this case isn't -- or shouldn't be! -- a problem. For our relatively-casual privacy use, authentication is almost moot. Some people I have already exchanged keys with, *I've never met face to face in my life* and may never. In spite of this I feel I know them. I trust or assume that they are who they say they are. This is the environment we need to work in. This, plus the fact that we've got (at the moment) some 16,000 potential keys, means we simply can't do the full-blast security thing. How much "security" can I expect, or need, with someone I've never met? Consider again the utter-security case again. But the bottom line is in fact already taken care of, PGP or not -- how do you know that "the real Tom Jennings" wrote this article? Our underlying social system, so frequently overlooked, takes care of it. You can assume I, and many people who have been in the net, are verifiable. You have a number of ways to determine if I really wrote this article. Simply asking via FidoNet will uncover most fakes. Looking at old nodelists to see what info on my name has changed. Ask people who might know me. And so on. If our public keys are scattered to the wind like plants scatter pollen, it is certainly possible that I could fake "your" public key, and gain access through all the methods discussed in detail in the literature. However, assuming the real person and the fake person(s) are both generating keys (and using them to sign and send messages), the more keyrings were passed around the chances of detecting the incompatible keys becomes almost certain. At that point, even a casual effort would be able to track it down, to at least determine that there *was* a fake. Example: Mary has been using PGP for a few months, and conversing with friends and acquaintances. Her public key is filerequestable, and probably appears on a hundred keyrings. Over the next few months, other people get messages from "Mary" making increasingly odd claims, via encrypted mail. The impostors fake key, in order to be useful at all, would also have to be widely distributed. Curious, someone sends Mary a message encrypted with what appears to be her public key, and a plaintext one telling her that the cyphertext was encrypted with her public key, and that he suggests if she can't decipher it someone may have faked her key. FidoNews 9-41 Page 11 12 Oct 1992 What Mary actually does depends on many things. If she has indeed been creating the crazy messages, well, the problem's elsewhere. If she finds she can't read the message, her recourse depends on what is available to her: if there are public key repositories, she would be advised to contact them and notify them of the alleged faked key(s), and follow whatever process is setup to generate a new key. The very knowledge of key collision would be enough to flag to users that there's a potential problem. There are more practical issues that limit our need for traditional security measures on keys. Even if you stored your private key on disk, it would take physical access of your machine to get it. This is not what I'm worried about in private FidoNet mail. If a FidoNet member tries to break into my house or system to get at my key, I've got other troubles! Practically speaking, it might even be a good idea to have two keys; a small (256 bit) one for casual, email privacy, and a big one (1024 bits) that you give to people by hand on diskette. The small key will mean better performance, more important on bulk casual email, and certainly adequate against eavesdropping. For high-security needs, which most people don't have (I certainly don't), the performance penalty probably won't matter as much. The worst part of security systems is that people will *rely* on them as absolutes. This is the only thing that makes a faked, encrypted message worse than a faked, plaintext message. Again, it's important to remember the goal (as if we could ever possibly agree to a *single* goal...) -- if it's privacy, the ability to stop eavesdroppers, then a broadcast public key system is more than adequate, and public key repositories even better. If you want a maximum-security vault, you take added precautions. No one system will solve all problems. I'm a firm believer in a broadcast public key system for email. PRACTICAL SUGGESTIONS FOR PGP USE IN FIDONET PRIVACY: * Use small (256 bit) keys for routine, low-security use, such as netmail privacy with people you don't know personally (and don't get keys from physically). * Public key encryption is most useful for email, ie. FidoNet netmail, especially when it flows through multiple hosts on its way to its destination. FidoNews 9-41 Page 12 12 Oct 1992 * The current password scheme for echomail links is proven to be adequate to safeguard what is basically a public forum, anyways. Further security doesn't seem to be needed on these links. * When adding keys received via FidoNet to your public keyring, answer "do you want to certify this key yourself" with NO, unless you received the key by hand. It doesn't hurt the usefulness of the key itself; however, if someone later uses your public keyring they won't be lulled into a false security. (Certification of keys can be done at any time.) * Passing keyrings around willy-nilly, though counter to "good security practice" in traditional uses is actually a good thing for us. "Key Repositories" scattered throughout the net (each exchanging keyrings as well as posting lists of "trouble keys") is a better idea. * Reserve large (1024 bit) keys for people who you know, and can ensure security in traditional ways (some pointed out in the PGP documentation). * As seems to be developing, have your public key filerequestable as magicname "PGPKEY" (your own public key only), and your keyring as "KEYRING" (all of your public keys). These should be ASCII-armor files (PGP -kxa) ---------------------------------------------------------------------- by Andrew Gray of FidoNet 1:231/590.0 Privacy and Computer Compatibility Well, they are at it again. Privacy is a sensitive issue. But, in reference to G.K. Pace's article in FidoNews Vol. 9 No. 40, pages 9-11, he refers to a program called PGP 2.0 and says "(the rest of you may want to get PGP 2.0)". I could get it, but it wouldn't do me a lot of good. PGP 2.0 is an IBM-compatible program. I run on an Amiga. Small compatibility problem here. G.K. Pace then inserts in a message (or SOMETHING, I STILL don't know what) into FidoNews expecting everyone to read it. Welp, I guess I'm flat outta luck. Yes, I agree that privacy is a sensitive issue, but we must make sure that one of the principals of FidoNet, that every computer can use it, including Amigas, Ataris, Macintoshs, IBMs, etc. is insured. After all I could submit an article encrypted with PowerPacker and be achieving the same thing here. No other computers besides Amiga (to my knowledge) have a copy of PowerPacker, so no one else could read it. Now if you are PRIVATELY transfer stuff between two of the same computers, fine. But in a public document like FidoNews, no. (* ED NOTE: PGP comes with full "C" sources, and has been ported to Unix and other operating systems. It's work, done by volunteers. If you're a "C" programmer, or know one, well, there you go. Nothing is free. You are right, to be most useful it will require compatible software to run on at least most of the hardware out there. *) FidoNews 9-41 Page 13 12 Oct 1992 ---------------------------------------------------------------------- Al Filandro 1:141/885, 1:141/1885@Fidonet Bill Clintons Economic Plan I have found the last four years and the policies of our current "leader" in the United States pathetic to say the least. I don't want to go into a large debate about this clown's inability to lead our country; I've watched dozens of friends and family who have been employed their entire lives plunge into seemingly endless unemploy- ment. We do need change and it is "time for them to go". I sure hope some of you out there in the wonderful Fidonet community feel the same way as I do (registered Republican-voting Democrat!). To help turn some people on to the REAL ISSUES and the REAL PLAN, I have keyed, verbatim, Bill Clinton's economic plan to a readable ASCII text file which is easy to view with any editor. If any of you who filerequest this file would be so kind and post it on your systems to allow your caller's the ability to view Clinton's plan as well, it would be gratefully appreciated. To file request Bill Clintons plan, you may FileRequest the magic filename of "CLINTON" from fidonet nodes 1:141/885 OR 1:141/1885- Node1 is a USR 16.8 V32bis and Node2 is a USR 14.4k Straight HST modem (if any of you have a preference). The Filename itself is "CLINT92.ARJ" and it is approximately 17k compressed (44k uncomp- ressed). Nodelisted systems only may Freq this file (In Fidonet, Rbbsnet, Mailnet or Ournet) and my systems are located in Southington, Connecticut. I also urge each and every one of you to take the time to view the debates, the REAL issues (not mudslinging unsubstantiated claims) and take the time to vote this November. Thank you for your time. -Al Filandro ---------------------------------------------------------------------- "BBS Junkie" Be one with the keyboard Allow your fingers to glide Type in a few messages To a girl or a guy Become a BBS Junkie And never have to get high. Friends you'll meet aplenty Each with their own traits FidoNews 9-41 Page 14 12 Oct 1992 Join in the conversations Just pull up a stool Become a BBS Junkie And dive into the pool! The Psycotic Poet ---------------------------------------------------------------------- by Jerry Schwartz (1:142/928) WorldPol Depends upon You Your opinion is very valuable to the WorldPol development team, and your help is needed. When it passes, WorldPol will help shape your hobby, and it should be shaped the way YOU want it to be. Since the publication of the WorldPol draft in FidoNews, we have gotten a lot of feedback via netmail. Most of it falls into two categories: - "You left out something important." - "You made it too long." Well, it isn't easy for one or two people to figure out what to do with that. And because it was sent via netmail, only one or two people have seen it. There are two parts to the solution. I am going to crosspost all of these suggestions into the WorldPol echo; none of them seemed to be "private" stuff, so I am going to take my chances on offending anyone. That brings me to the second part: distribution of the WorldPol echo. It is already on the European backbone, I've been told, and should be on the North American backbone soon. In the meantime, it is available at 1:102/631, 1:128/77, 1:133/411, 1:142/928, 1:157/603, 1:170/400, 1:250/99, 1:367/1, 6:720/303, 2:512/1, 2:257/102 and possible elsewhere. If you want your opinions heard, could you please hook up? We want WorldPol to be what the members of FidoNet want it to be. Thanks. ---------------------------------------------------------------------- FidoNews 9-41 Page 15 12 Oct 1992 By Jason Garneau 1:325/304 H-NeT goes National / / /\ / -------- / / / \ / ____ / /----/ ---- / \ / / | / / / / \ / /_____/ / / / / \/ \_____ / -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 two to three weeks 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 got my feed (1:325/301) to start sending the echo out to 1:101/1, and 1:325/118 to help stir up activity. And now I arrive at today. H-NeT does not yet reach the requirements to be available on the backbone, so it is only available at 1:325/304, 1:325/301, 1:325/118, and 1:101/1. If you are interested in H-NeT, tell your SysOp, or if you are a SysOp, ask one of these nodes to set it up so you can belong to H-NeT. Please contact me at 1:325/304, or 1:325/301 if you have any questions about H-NeT. We hope to see you on H-NeT and happy telecommunications! ---------------------------------------------------------------------- LE_CLUB - The FidoNet Veterans Club ----------------------------------- Le_Club is a social echomail conference that aims to bring together FidoNet oldtimers. The echo is not restricted in any way, except that it is only open to FidoNet sysops, and not to BBS users. Still, it is recommended for those that have been in the network for at least two years, although the more novice sysops are welcome to come, see, and participate. Le_Club is a species of electronic FidoNet "con." It is the place to talk about how each of us got started in the network, to remember how things were back then and, why not, to talk about the future each of us envisions for our dear FidoNet. It is also the place to socialize with other "names" we have seen for long but with whom we were never in touch, and of course, to simply talk about the weather, share happy experiences as well as tales of dupe loops, bombing runs and why not, thunderstorms messing around with the phone equipment. :) FidoNews 9-41 Page 16 12 Oct 1992 There is absolutely no room in Le_Club for politics or flames. Many of us have had differences with others -ranging from small discussions to full-fledged flame wars- throughout the years, but we MUST leave them out of the echo. In addition to this, Le Club is not a technical echo, there is the conference NET_DEV that is more appropriate for technical matters. There will be no moderator in Le_Club, other than the persons in charge of periodically posting the echo's guidelines and participation statistics, also known as the hosts or "Logkeepers." By getting linked to Le_Club, you are committing yourself to being friendly towards everybody, and to refrain from starting hapless episodes. We believe it is still possible. Henk Wevers, Noel Bradford, Pablo Kleinman LOGKEEPERS ATTENTION: ---------- Many FidoNet vets have joined Le_Club already... please request it to your echo feed and join in! ---------------------------------------------------------------------- FidoNews 9-41 Page 17 12 Oct 1992 ====================================================================== FIDONEWS INFORMATION ====================================================================== ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ---------------- Editors: Tom Jennings, Tim Pozar Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello "FidoNews" BBS FidoNet 1:1/1 Internet fidonews@fidosw.fidonet.org BBS (415)-863-2739 (2400 only until further notice!) (Postal Service mailing address) (have patience) FidoNews c/o World Power Systems 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, 1:107/519.1 (and probably others), via filerequest or download (consult a recent nodelist for phone numbers). 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.) FidoNews 9-41 Page 18 12 Oct 1992 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/1 as file "ARTSPEC.DOC". "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings of Fido Software, 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 ----------------------------------------------------------------------