informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido0941.nws

962 lines
42 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
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
----------------------------------------------------------------------
Reference in New Issue Copy Permalink