F I D O N E W S -- Volume 14, Number 16 21 April 1997
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-904-409-7040 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:18/14 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: FidoNews Editor 1:1/23 |
+----------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=>
[email protected] |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
SEND ME A DOLLAR!
Table of Contents
1. EDITORIAL ................................................ 1
Same old same old ........................................ 1
2. LETTERS TO THE EDITOR .................................... 2
MS Word Macro Virus reported ............................. 2
3. ARTICLES ................................................. 3
Eating Crow .............................................. 3
FIDO Toes Up ............................................. 4
4. COLUMNS .................................................. 7
Lock and Load: Guerilla Marketing for BBSes ............. 7
5. GETTING TECHNICAL ........................................ 9
FSC-0059 - Newsgroup Interchange within FidoNet .......... 9
FSC-0060 - Calculation and Usage of CRCs ................. 19
6. COORDINATORS CORNER ...................................... 23
Nodelist-statistics as seen from Zone-2 for day 108 ...... 23
7. NET HUMOR ................................................ 24
April Fool's Pranks for Programmers ...................... 24
Changing a lightbulb the Internet way .................... 26
8. NOTICES .................................................. 28
Future History ........................................... 28
9. FIDONET SOFTWARE LISTING ................................. 30
Latest Greatest Software Versions ........................ 30
10. FIDONEWS PUBLIC-KEY ..................................... 35
FidoNews PGP public-key listing .......................... 35
11. FIDONET BY INTERNET ..................................... 36
And more!
FIDONEWS 14-16 Page 1 21 Apr 1997
=================================================================
EDITORIAL
=================================================================
Another disaffected and long-time Sysop is calling it quits in this
Issue; citing burnout. [sigh]
It's unfortunate that this hobby is taken so seriously by some that it
affects their enjoyment. There are pinheads in Echomail but then
that's what Echomail is for, isn't it? You've got to ignore them.
Taking it to heart is the road to disappointment and burnout.
On a happier note, Region 13 has elected a new Region Coordinator with
no bloodshed and no uproar. David Moufarrege has taken over the daily
Coordination ops on the eastern seaboard. He has already set up a new
webpage for Region 13 at:
http://www.smalltalkband.com/st01000.htm
and this now appears in the Zone 1 list at the end of the Issue and on
the FidoNews webpage. I was hoping to have a report of the election
from the R13 Election Coord but if it's enroute it won't make it this
week.
Still no sign of the uucpGate at 1:13/10 or its replacement. I need a
new gateway to use for outbound email here. I've tried the local one
used by my former Net but it doesn't like my uucp format for some
reason and bounces my traffic. I don't need one to be local. If I can
use your uucpGate, please let me know via Netmail or email. The
addresses are in the Masthead at the end of every Issue.
There is a new date in the Future History section this week. I hope it
doesn't last but fear it will. You figure out which one it is. [sigh]
If any of you column writers of past Issues wish to restart your
efforts or if any of you closet columnists wish make regular
contributions, check ARTSPEC.DOC and have at it! FidoNews is only what
FidoNet, at large, makes it.
C.B.
-----------------------------------------------------------------
FIDONEWS 14-16 Page 2 21 Apr 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
From: "Mike Riddle" <
[email protected]>
To: "Baker, Christopher" <
[email protected] (Christopher Baker)
Date: Fri, 18 Apr 97 13:16:48 -0600
Reply-To: "Mike Riddle" <
[email protected]>
Subject: Fwd: New MS WORD Email spread virus
==================BEGIN FORWARDED MESSAGE==================
>From: Frank Cox <
[email protected]>
>Subject: New MS WORD Email spread virus
The official MICROSOFT web page acknowledges that their wordprocessor,
WORD (all versions) and their Internet mail product, MSMAIL are
vulnerable to another macro type virus that CAN be spread by Email
described as follows:
ShareFun.A Virus Information
ShareFun.A is a new virus that utilizes MSMail and Microsoft Word to
spread itself three-fold throughout your email network. Also known as
the "ShareTheFun" virus, it is spread by using MSMail email messages
and attaching itself as an embedded document. The subject line of the
email reads "You have GOT to read this!"
ShareFun.A is a WordBasic virus, running in Word 6 and Word 95. It has
also been found in Word 97 Visual Basic for Applications (VBA), after
the infected Word 95/6.0 document has been opened in Word 97. The
virus runs and infects the Word environment whenever an infected Word
document is opened.
Details are available at:
http://www.microsoft.com/word/freestuff/mvtool/virus_fun.htm
Frank Cox
Chief Deputy Public Defender, Marin County
Hall of Justice, Rm 139
San Rafael, CA 94903
voice: 415 499 6340
fax: 415 499 6898
[email protected]
http://midas.co.marin.ca.us/mc/pd/index.html
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 14-16 Page 3 21 Apr 1997
=================================================================
ARTICLES
=================================================================
Eating Crow - A FidoNet Diet
By: Clay Tannacore 1:372/4
For the last several months I have from time to time been engaged
in writing guest editorials for FIDONEWS. You on the other hand have
been condemned to either reading them, or scooting past this section,
so that you might indulge yourself in the technical aspects of
FidoNet, one of the most celebrated portions of FIDONEWS, assuredly.
Of course, you haven't been entirely immersed in the body of knowledge
(aka technologies) of FIDONEWS, by no means. Some of you fine, fellow
SysOps have instead been preoccupied with *flaming* me via NetMail, in
various Echoes, and by even placing late night calls to my home. Why?
Well, it's simple. I have had the audacity to question FidoNet, and
POLICY 4. Apparently these subjects are taboo, if the writers opinion
varies in any way from standard operating procedures, or the status
quo. I obviously stumbled into the area of our association reserved
exclusively for *The Blessed Ones* of our brotherhood. Because of
this unholy transgression, I have been placed on a diet of *CROW*.
That's right, I am now "eating crow" as my mainstay, my only allowable
meal until I learn to communicate with the masses, and conform to the
mind set of the majority. I must undergo *reprogramming* in my mental
attitude towards FidoNet, POLICY 4, and any imbecilic procedure that
is contrived by the *Almighty* powers that be.
So, henceforth I will *not* indulge in any criticism,
animadversions, or any other commentary concerning FidoNet, nor will I
even express my opinion that POLICY 4, requires unequivocal
modifications. No longer will I be the *one* dissenting voice in this
association. Now that I find total harmony alive and well in FidoNet.
Now that I have been shown the *proper* path I must take to coexist in
this federation. Now, I resign myself to becoming assimilated into
the *true* brotherhood of Fido Net SysOps. No longer will I allow my
testosterone to rule me. I will become yet another cretin in the
fraternity of SysOps, in the land of FidoNet. . .
All the above crap aside, I *have* decided to *shut up* (loud
applause) and leave well enough alone. I have been gutted by Network
Coordinators, an RC or two, and more damn SysOps than are listed in
the NODELIST. So, with *everybody* telling me how wrong I am about
POLICY 4, and FidoNet as a hole (OOPs, I meant whole), and with only a
few (about 4 percent) SysOps in agreement with my views, I think it is
time I faded off into obscurity and allow you folks who read this
news-letter, to get a bigger dose of FTSC-0001 type literature to
digest from now on.
I do want to thank all of the guys/gals who have had to suffer
through my odious attacks on POLICY 4, and the general *C structure of
FidoNet. I never *really* expected to see any changes made in the way
this association is operated. I was, however hoping that will
FIDONEWS as my outlet, some positive dialog would evolve. Some did,
but only for a short time. Then it seemed that the voices that were
FIDONEWS 14-16 Page 4 21 Apr 1997
raised, dissolved. Either because of disappointment when noting was
seemingly getting done , or because of inter network intimidation.
Whatever the case, as expected, nothing has changed. The new motto
for FidoNet, and the old motto, is still; "STATUS QUO for FIDO", sung
to the tune of "God Bless Armenia" (and that ain't America). . .
While I'm thanking people, let me thank a guy who has (probably)
the least appreciated job, in this organization. Chris(topher) Baker,
the Editor of FIDONEWS. I know this guy has spent enough of his
personal money on phone calls alone, to place a substantial down
payment on a 98 Mercedes. A damn shame too, in my opinion. I think
each Net in *every* region should help support FIDONEWS, with a once a
year contribution of say, ten cents per node per month, or a one time
a year payment by the SysOp of one dollar ($1.00). Now, this one
should get me a group of new words to add to my vocabulary. . .[smile]
So long folks, See All of You, On The Internet. . .(BS)
-----------------------------------------------------------------
FIDO Toes Up
by Tom Johannsen, 1:104/540
Has anyone paid attention to the size of the nodelist lately? It's
shrinking. Why? The internet? Lack of interest? Politics?
Technology? None of the above?
How about all of the above. I've been in FIDO almost since it's
inception. I watched it grow until it broke the nodediff processors
and sent everyone back to the drawing board. I've watched the
in-fighting and the birth of the term Fight-o-Net. I've watched the
gradual decline of the comradeship, the friendship, that was the
purpose of FIDO to begin with. I can remember a time when you could
actually call the (now zc) on the phone and get help with anything you
needed. He actually listened, he MADE time for you. I watched FIDO
grow from a hodge-podge collection of BBS' to the formation of nets to
the ultimate - zones. Now nodes in the U.S. are declining so fast
that the growth of other zones cannot even keep up with the attrition.
Zone 1 is now outnumbered. The reason? All of the above.
FIDO is being overrun by "all of the above".
The INTERNET because of it's easy accessibility, it's timeliness of
both files and responses. You can send and receive response messages
clear around the world in less than a day. You can chat with anyone
anywhere, you can get the most recent files written. You don't need
to even keep any archives. The i-net has it all. EXCEPT for
friendliness. It's very antiseptic. You rarely ever meet the people
you come into contact with.
The LACK OF INTEREST is due primarily because of selfishness and
greed. People don't run BBS' or call BBS' for the fun factor, as they
used to. Most sysops that are just starting out in FIDO now do it for
purely selfish reasons. They already know what they are getting into
and have decided to *use* fido to get what they want, whether it is
FIDONEWS 14-16 Page 5 21 Apr 1997
files or echos or experience. A very few do it "just for the fun of
it" and they rarely last over a couple of years. They soon find out
just how bad it REALLY is. They volunteer to be a hub or become an
NEC or NC. Then reality hits. They find out just how little anyone
cares in FIDO.
The POLITICS have caused a large part of the attrition. Policy 4 was
initially written to act as a GUIDE to helping people in the net. Now
it's used more as a CLUB to pound with. It's selectively enforced and
NEVER fairly. Policy 4 is in shambles. It needs re-writing. When it
was written we foresaw growth, but not to the extent that actually
occurred, particularly in the area of echomail. However, P4 will
never be redone. Why? Laziness and Politics, along with apathy and
resistance to change. Instead of creating a document that would
promote the growth of the net, the only thing I see are inputs that
are submitted by someone "with an axe to grind". Or I see someone
with a good idea being shot down by someone without a clue as to why
FIDO exists. There is no ACTIVE participation by anyone that can get
the job done. They lurk, they read, but they don't participate. Why?
Because it might tarnish their image to align themselves with an
unpopular idea. So long as they don't have the "moxy" to stand up and
go for it, P4 will *forever* be P4.
The TECHNOLOGY of FIDO has fallen terribly short of reality. There
was a time when FIDO sysops were asked for help on many cutting edge
programs/equipment. Now???? When was the last time you saw a 300
baud modem? Statistics say that there are 2323 of them out there
somewhere. There's a whole 9 (count 'em, nine) 1200 baud modems and
so on to 9600 baud modems. Of those listed as 9600, roughly 2/3rds
are v.34 types. Why does the nodelist not reflect the true speeds?
Politics? Laziness? Or some other lame excuse. Other nets have been
using true speeds for some time now in THEIR nodelists. Why can't
FIDO? Don't ask someone. They will tell you that it's because some
software cannot handle them. Technology??? If that's the case then
why don't they update the software? However, we know that's not the
case. If it were then how is it the other nets use the same software
and get the job done.
In Summary.
FIDO is a dinosaur with it's brain in it's tail. The problem is that
the tail was cut off and the message hasn't reached the rest of it's
body yet. If it doesn't learn to adapt and improve it's technology,
it's dead (or close to it), for zone 1 at least, and just doesn't know
it.
The only thing the sysops of FIDO can agree on is to DISagree. This
DISagreement is DISagreeable and DISgraceful to those that have any
pride left. Others just don't care I guess. It's a shame. No one in
FIDO seems to care what image FIDO has.
I've become a minority. All those years of work on building and
promoting FIDO by myself and other "old-timers" has gone for naught.
Others that really CARED have already left. Even the founder is no
longer in the nodelist. Maybe Tom J. was right. I know that soon
I'll follow the rest of the "old-timers" and leave FIDO. Why? Because
it is beyond help. It has become Deaf, Dumb, and Self-Serving. Fresh
FIDONEWS 14-16 Page 6 21 Apr 1997
ideas are voiced to deaf ears. Software writers are leaving because
of the dumb antiquated technology and requirements. Improvements are
frowned on OR ignored. New concepts or new ideas are rejected out of
hand.
Am I bitter? NO! Am I "out to get someone"? NO! Am I sad? Yes.
Roll over FIDO, point your toes up, get comfortable, and play dead.
Actually, the FIDO I knew is not playing. It IS dead.
-----------------------------------------------------------------
FIDONEWS 14-16 Page 7 21 Apr 1997
=================================================================
COLUMNS
=================================================================
Lock and Load: Guerilla Marketing for BBSes
Robert Parson 1:3822/1
I hope you did your homework. In our last column I asked you to
collect up information about your local newspapers and radio and tv
stations, and advised you we would be sending them some information.
Those of you who have since also downloaded the "BBS Guide to Public
Relations" probably know what I'm going to talk about next.
That's right, we're going to talk about News Releases.
The News Media is your friend. Yes. They really can be. I know that
the image of BBSes in the media is not generally a happy one, but you
can turn that around with a grass roots effort. All it takes is your
wordprocessor and your fax modem.
Anyone who's seen a movie or tv show about journalists knows that
there are five "W's" that must be answered: Who, What, When, Where,
and Why. You don't need to write a lot to get all those in. I once
wrote a news story about a traffic fatality in two sentences. ("A 68
year old (city) man was killed in a traffic accident today. Police
say (name) slipped off a curb at (street) in (city) and was hit by a
car driven by (another name).")
The main issue, though, is that there must be something going on. You
can't just say "Joe Blow invites everyone to call his BBS." You
could, but it means nothing. What is going on at your BBS that might
entice someone to call? How about some recently added Fidonet Echos?
Now you have something. So crack open that wordprocessor and let's
crunch some words.
First, you need a headline. Something like "NEWSBOB BBS EXPANDS"
Now, the news release. (I'm making up some echos here, obviously)
"NEWSBOB Computer Bulletin Board System (BBS) has added several new
message areas that are share messages with BBSes around the world.
The new areas are 'Newsbob,' discussions about Award Winning Broadcast
Journalist Robert Parson; 'Bobmobile,' discussions about his car; and
'Bobsquad,' discussions about his wife and three children.
"The message areas are shared internationally, or 'echoed,' with
roughly 25 thousand BBSes through FIDONet, the oldest and largest
amateur message network. Fidonet carries messages with topics ranging
from abortion to zymurgy.
"NEWSBOB BBS can be reached by anyone with a computer by dialing XXX
XXX XXXX with their modem.
"For more information call Robert Parson at XXX XXX XXXX"
FIDONEWS 14-16 Page 8 21 Apr 1997
Let's break this down into its five components: Who, which in this
case is a thing: Newsbob BBS. What: New Echos. When: Recently (not
stated, but understood). Where: locally, or alternatively, in
Cyberspace (that is an actual place now, according to the latest
Associated Press style). Why: expand the offerings of the BBS. You
don't have to be a particularly brilliant writer. But if you include
all the necessary information, your News Release will, at the very
least, be readable.
There's also information about how the echos are distributed, how to
get on the BBS, and just as importantly, how to get hold of someone to
talk to in case a reporter has some questions. In most cases, if
there is now contact information, a News Release will be dumped into
the trash.
Make sure your News Release is checked for spelling. Although it
probably won't be dismissed out of hand for spelling errors, it does
look unprofessional. And professional is the image we're shooting
for, right?
Finally, try to keep your News Release to one page. Most reporters
will read the first couple paragraphs and act on it, file it, or trash
it.
Now print it out on that letterhead you ordered (or designed on your
DTP), and drop it in the mail to the media contacts you made in your
previous calls. Yes, you can send a fax if you prefer.
Do NOT expect anyone to call, and do NOT expect your News Release to
result in a story in the paper or broadcast media. You are competing
with the normal news of the day, plus possibly hundreds of faxes and
letters from others trying get space or airtime. A couple years ago,
I helped a local BBS wage a Media Campaign. It took about two months
of weekly faxed News Releases before it finally resulted in a story.
There are other things you can have in a News Release besides
additions to your BBS. You could include anticipation of the 10
thousandth caller (or 100 thousandth, or whatever), with a follow up
of who that person was. A gaming tournament. My favorite: local
angles to national stories. For instance, I contacted a local
Internet Service Provider this year to see if it was having the same
connection problems AOL was having due to the explosive growth of the
Internet (they claimed they weren't).
Be creative with your topics for News Releases. Nearly anything your
BBS is doing can become a possible news story. It's simply a matter
spinning it correctly.
Next time, we'll talk about how to handle those media scallywags.
Robert Parson
-----------------------------------------------------------------
FIDONEWS 14-16 Page 9 21 Apr 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing series of FidoNet History articles
highlighting the FidoNet Technical Standards and Proposals that
guide the programmers who make our hobby operate. They have been
reformatted to 70 columns where required and any tables may be askew
as a result. Node numbers and phone numbers may be out of date.] Ed.
Document: FSC-0059
Version: 001
Date: 08-Mar-1992
Newsgroup Interchange within FidoNet
Jack Decker
1:154/8@fidonet
A proposed standard for the interchange of USENET News messages
among FidoNet nodes.
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Introduction:
This document defines the standard format for the interchange of
USENET news messages among FidoNet nodes. It incorporates by
reference the document RFC-1036, "Standard for Interchange of USENET
Messages" by M. Horton of AT&T Bell Laboratories and R. Adams of the
Center for Seismic Studies. A copy of RFC-1036 should be included in
the distribution archive of this standard. However, RFC-1036 is NOT
applicable in its entirety to FidoNet. Therefore, unless specifically
referenced elsewhere in this document, only section 2 of RFC-1036
should be considered part of this standard. Section 3, which deals
with "control messages", may be implemented in FidoNet on an optional
basis, and if processing of control messages is included in a FidoNet
implementation, it should be done in accordance with section 3 of RFC-
1036 to the extent possible. Section 4 of RFC-1036 is *NOT*
applicable to FidoNet (except for section 4.3, which will be discussed
later) and therefore is NOT included as part of this standard.
Section 5 of RFC-1036 is a treatise on the News Propagation Algorithm
used within UseNet, and should be studied even though it is not
directly applicable to FidoNet, in particular because it contains a
discussion on the prevention of loops (what we in FidoNet commonly
refer to as "dupe loops").
Please note that FidoNet implementations do not recognize nor support
what is referred to as the "old format" or the "A format" in section 2
FIDONEWS 14-16 Page 10 21 Apr 1997
of RFC-1036.
The goal of this document is to define a standard for the interchange
of news messages between FidoNet nodes in a format that will also be
acceptable to UseNet hosts. In order to simplify the creation of
software that conforms to this standard, we do not intend to support
every news format that has ever existed in UseNet. The standard
described in RFC-1036 is used by the majority of UseNet hosts, and
therefore it is the standard that will be adopted in this document.
This standard will contain three sections: General theory of
newsgroup transmission, Format and protocols of batched newsgroups,
and the translation of newsgroup messages to and from FidoNet message
format.
1. General theory of newsgroup transmission:
Prior to the introduction of the DoveMail program, the usual method of
gating a UseNet newsgroup into FidoNet was to convert it to FidoNet
echomail, and then send it to "downstream" nodes in echomail format.
This method is still used at the majority of gateway systems at this
writing. Unfortunately, no conversion process is perfect, and some
useful control information is usually lost in the conversion. In
addition, most FidoNet echomail processors don't handle long messages
(which are fairly common in newsgroups) well at all, and many gateway
systems either try to split these messages into multiple parts (a
somewhat awkward process) or discard them entirely. Because the
duplicate message detection algorithms used in many FidoNet echomail
processors incorrectly identify some of the parts of a split message
as duplicates, parts of long messages often get "lost" when
transmitted as echomail. Also, UseNet allows a message to be posted
to multiple newsgroups, and when such messages are converted to
echomail, it may be necessary to create multiple copies of the message
(one for each echomail area that it would be placed in), thus
increasing the transmission time for such messages.
Even normal-length newsgroup messages may be falsely discarded as
duplicates by some "downstream" echomail processors. The reason this
is a particular problem in newsgroups converted to echomail is because
some echomail processors use a checksum of parts of FidoNet message
headers to determine if messages are duplicates. Since all newsgroup
messages are assumed to be addressed to "All", and since some gateway
software uses the date and time that the message was converted to
echomail rather than the original date and time from the message, it's
quite possible that the remainder of the message header contains
information that is similar enough to information in another message's
header to cause it to be discarded as a duplicate message. This
happens far more frequently with converted newsgroup messages than
with messages originally entered as echomail.
Finally, when a BBS user enters a reply to a news message that has
been converted to echomail, in many cases the information is simply
not available in the original message to generate a proper
"References:" line in the reply, as required by RFC-1036. If the
original message contained a "Followup-To:" line, which requires that
replies be posted to a different newsgroup than the one in which the
FIDONEWS 14-16 Page 11 21 Apr 1997
original message was entered, this line may not transmitted in the
message as converted to echomail. And even if this information is
available, no echomail processor currently available will modify the
reply message as required (to add the "References:" line where
necessary, or to move the message to a different area if it is a reply
to a message that contained a "Followup-To:" line).
Under this proposed standard, none of the UseNet message header
information is lost in transmission between nodes, and reply messages
can be generated that conform to UseNet specifications. If a message
is posted to multiple newsgroups, it is only transmitted once (instead
of multiple times as it might be if converted to echomail). Also,
long messages are not truncated or changed in transmission between
nodes, and finally, there is no chance that a message will be
improperly discarded as a duplicate.
The main thing to remember is that under this standard, news messages
are never converted to echomail. Echomail is an irrelevant concept in
this context, since we are not passing echomail between nodes.
Instead, newsgroups are transmitted in the native format specified by
RFC-1036, and tossed directly from batched newsgroup packets to the
FidoNet message format (e.g. the *.msg format) if necessary. Keep in
mind that most FidoNet BBS software uses the same general format not
only for echomail messages, but also for netmail and local message
areas, so it is not necessary to transmit messages between nodes in
echomail format if another format is more suitable for the type of
message being transmitted.
2. Format and protocols of batched newsgroups:
When newsgroup messages are transmitted between systems, the
individual messages must conform to the specifications of section 2 of
RFC-1036, and section 3 of this document. Where section 3 of this
document defines a more restrictive standard than RFC-1036, this
document shall take precedence.
When transmitting news messages between FidoNet nodes, they must be
sent in a batched newsgroup file (as described in section 4.3 of RFC-
1036) unless some other format is agreed upon in advance. The
transmission of unbatched news messages, or the use of any batching
method other than that described in section 4.3 of RFC-1036 shall be
considered non-standard. Please note that RFC-1036 section 4.3 refers
to this batching process as combining several messages into "one large
message", but we will refer to this "one large message" as a "batched
newsgroup file", or a "UseNet format mail packet" rather than as a
"large message", since FidoNet systems do not normally handle large
"messages".
When messages pass through a FidoNet system on their way to other
nodes, the header lines in the message may be modified to conform with
the standards given here. However, the text (body) of a message
should NEVER be altered (one exception: Carriage Returns MAY be
converted to Line Feeds in order to conform to this standard, but this
is neither required nor expected of software).
The standard format for sending a batched newsgroup file to other
FIDONEWS 14-16 Page 12 21 Apr 1997
FidoNet nodes is as follows:
First, as will be noted in section 3 of this document, individual
lines of the batched newsgroup file must be terminated with Line Feeds
only, and the file must NOT contain Carriage Return characters (ASCII
13).
Batched newsgroup files shall be transmitted between FidoNet nodes as
files named using the filename ????????.PKU, where the eight character
root name can be any of the hexadecimal digits 0 - 9 or A - F. The
.PKU extension (which stands for "PacKet - Usenet format") is the news
equivalent of the .PKT file used to transmit FidoNet format netmail
and echomail between nodes.
Batched newsgroup files with the filespec ????????.PKU may be archived
into a standard mail archive file (bearing the extension *.MO?, *.TU?,
*.WE? ... *.SU?). It is assumed that the receiver of batched
newsgroup files will take any necessary steps to make sure that both
*.PKU and *.PKT files are extracted from incoming mail archive files
before the mail archive files are deleted. In certain cases, this may
mean that an external unarchive shell may have to be used, instead of
allowing the echomail processor to call the unarchiver (typical
external unarchive shell programs at this writing are GUS, POLYXARC,
and SPAZ).
A batched newsgroup file awaiting transmission may be stored in a
FidoNet system's "outbound" area in uncompressed form, prior to being
archived for transmission or sent in uncompressed form. It is
suggested that when a system uses the .OUT extension to indicate an
uncompressed netmail or echomail packet, the .UUT extension be used to
indicate an uncompressed batched newsgroup packet. It is expected
that a .UUT file in a system's "outbound" area will be treated in much
the same way as an .OUT file, except it will be renamed to a file with
an extension of .PKU (rather than .PKT) before being archived into the
mail archive. This implies that the root name of the .UUT file will
contain the net number and node number of the destination system,
expressed as four hexadecimal digits each for net and node numbers, in
the same manner as the root name for a FidoNet .OUT file is
constructed.
The root filename of the *.PKU file should be an eight digit
hexadecimal number, with leading zeroes used if necessary, in order to
make an eight character root filename. It is suggested that this
hexadecimal number be based on time of year, with 00000000.PKU
generated at exactly midnight on January 1 and FFFFFFFF.PKU generated
at just a moment before midnight on December 31. However, it is
permissible to use the same algorithm that is used to generate the
root filename for *.PKT files.
The normal sequence for transmission of messages between FidoNet nodes
might then be described as follows:
a. Messages created on the originating system are placed into a
batched newsgroup file conforming to the specifications of RFC-1036
section 4.3. When this batched newsgroup file is destined for another
FidoNet node, it will have a filename of the format:
FIDONEWS 14-16 Page 13 21 Apr 1997
[4 hex digit net number][4 hex digit node number].UUT
This file will then be placed in the outbound mail area for packing.
b. A mail packing program will examine the outbound mail area and,
upon finding the .UUT file, will rename it to a file with an extension
of .PKU, and then shell to a compression program in order to place the
*.PKU file into a new or existing mail archive file for the
destination node. Mail archive files bear extension names consisting
of the first two letters of a day of the week (in the English
language) plus a numeric character in the range 0 - 9 (for example,
.MO5 or .TH7). The method of compression for the mail archive is as
agreed upon between the originating and destination nodes. No
"standard" method of compression for the mail archive is specified in
this document. NOTE: If the compression program fails for any reason
(such as running out of disk space), the mail packing program MUST
rename the .PKU file back to the original *.UUT filename before
exiting. Since batched newsgroup files do not contain a header that
indicates the destination node, there would be no way to determine the
proper destination node if the file were not renamed back to the
original filename.
c. The mail archive is transmitted in the usual manner by a FidoNet
compatible mailer, or such other means as may be agreed upon in
advance by the sysops of the originating and destination nodes.
d. At the destination system, the individual files are extracted from
the mail archive. *.PKT files are processed in the usual manner to
extract any netmail or echomail messages, while *.PKU files are
processed by software designed to handle batched newsgroup files. In
this context, such files could be "handled" by re-processing the
messages and batching them to be sent on to one or more additional
node(s), or by tossing the messages to the local message base, or
both.
Please note that this standard does not anticipate that batched
newsgroup files will be converted to FidoNet echomail at any point
along the way. It is realized that this may indeed happen, but such
conversions should be considered as something to be avoided if at all
possible due to the problems discussed in section 1 of this document.
3. Translation of newsgroup messages to and from FidoNet message
format:
NOTE: Where applicable, the standards defined in this section for
messages shall apply not only to locally created messages, but also to
all messages sent to "downstream" FidoNet nodes.
In this context, "FidoNet message format" means that format in which
messages commonly reside on a FidoNet BBS. At this writing, there are
three formats commonly used for message storage on FidoNet systems,
but other formats may be in use as well. The three most common
formats are the "*.msg" format as used by the original Fido program
(and a host of programs since), also commonly referred to as the
"single message per file format"; the "Hudson" format, used by
QuickBBS, Remote Access, and some other products; and the "Squish"
FIDONEWS 14-16 Page 14 21 Apr 1997
format used by the Maximus BBS and the "Squish" echomail processor.
Because there are so many message formats, some other programs have
taken the approach of trying to convert UseNet news into echomail,
creating *.PKT files which can theoretically be processed by any
FidoNet system. However, since the *.PKT files are processed by the
echomail processor, all the limitations and pitfalls associated with
converting newsgroup messages to echomail come into play.
The preferred way of handling incoming messages would be to have the
BBS (or message reader/editor) software directly read batched
newsgroup files. In this way, the files would not have to be
"processed" per se. As new batched newsgroup files arrived on a
system, they could simply be concatenated to the existing message
base, and then a utility could be run that would build an index to the
message base, in a manner somewhat similar to the way "flat file"
message bases are currently implemented on some BBS's. Of course,
you'd need to occasionally run a utility to delete old messages in
order to keep the message base from growing too large, and new
messages entered on the system would have to be exported from the
system in a separate batched newsgroup file. However, at this writing
no FidoNet-compatible BBS or message editor is capable of directly
reading a batched newsgroup file.
The second most preferable method is to convert news messages directly
to the message format used by that system. At this writing the
DoveMail software includes utilities (NewsToss and NewsScan) that can
convert batched newsgroup files to and from messages in the *.msg
(single message per file) format. It should be possible to convert
batched newsgroup files to and from other FidoNet message formats as
well.
The method in which messages are stored on a BBS, and the method in
which it is determined which new (locally-entered) messages need to be
exported from the system will necessarily be implementation-specific.
One method that can be used with *.msg type message bases is to
maintain a "high water mark" in 1.msg, similar to the "high water
mark" used for echomail messages, and additionally to mark messages
received from other nodes as "sent" when they arrive, and locally-
entered messages as "sent" when they have been exported, and to never
re-send a message marked as "sent".
When tossing incoming messages, duplicate messages can be detected by
comparing the contents of the "Message-ID:" line with those of
previously received messages. This may be slow processing
considerably, however, and would require storage of a history file of
"previously seen" messages. Another method is to look in the "Path"
line and see if we are already listed in the path; if so, the message
is a duplicate and should be deleted. This method is faster and does
not require maintenance of a history file, but will not guard against
duplicate messages arriving from one's feed that have not passed
through the system twice (for example, a message that arrived from two
different paths). Fortunately, UseNet folks seem to understand the
need for proper topology, so those types of dupes are relatively rare.
FidoNet sysops taking UseNet feeds must understand that it is
IMPERATIVE that a feed of any one newsgroup be obtained from only ONE
FIDONEWS 14-16 Page 15 21 Apr 1997
source, especially if they are then passing that newsgroup to any
"downstream" nodes. This absolutely does NOT imply that geographic
restrictions on newsgroup distribution are necessary or desirable!
Additional comments on preventing "loops" can be found in section 5 of
RFC-1036, in the discussion of the News Propagation Algorithm. Please
note that only two methods of loop prevention are included in this
standard:
1) The history mechanism. Each host keeps track of all messages it
has seen (by their Message-ID) and whenever a message comes in that it
has already seen, the incoming message is discarded immediately.
2) Not sending a message to a system listed in the "Path" line of the
header, or to the system that originated the message (which, in
practice, should be listed in the Path line).
No other methods of dupe loop prevention are acceptable. In
particular, checksums of portions of the message header or message
itself are NOT permitted to be used for loop prevention, except
perhaps as a method to quickly identify POTENTIAL duplicate messages
before doing a full string comparison with the Message-ID data in the
history file. In no case should a checksum be used as the SOLE method
of determining whether a message is a duplicate.
When newsgroup messages are created for transmission to other systems,
or when received messages are transmitted other systems, the
individual messages must conform to the specifications of section 2 of
RFC-1036. However, in order to simply programming of software
designed to handle such messages, the following modifications to the
standard are proposed for use within FidoNet. Please note that these
are slightly more restrictive than the standard permitted by RFC-1036:
a. The "old format" or "A format" described in section 2 of RFC-1036
is NOT supported in FidoNet. Only the format detailed in RFC-1036
(sometimes referred to as the "B" News format) is supported. The vast
majority of UseNet sites currently use the "B" News format.
b. The UseNet standard permits the use of "white space" to separate
certain items in the message header, with "white space" defined as
blanks or tabs. It also states that "the Internet convention of
continuation header lines (beginning with a blank or tab) is allowed."
However, it should NOT be ASSUMED that "continuation header lines"
will be used in any message. It is suggested that when creating
newsgroup messages for transmission to other systems, the use of tab
characters be avoided in header lines, and that "continuation header
lines" NOT be used, even if this means that a header line will be
considerably longer than the length of a screen line. Software that
creates FidoNet-format messages (for display to BBS callers) from
batched newsgroup files (that is, newsgroup message tossers) should
break up such extra-long header lines, using a single space character
ONLY (NOT a tab!) at the start of "continuation header lines." Since
batched newsgroup files received from a UseNet site may contain
"continuation header lines" and/or tabs as "white space" in header
lines, it is necessary to be able to decode such header lines
properly, but it is strongly suggested that FidoNet software not
FIDONEWS 14-16 Page 16 21 Apr 1997
CREATE messages with tabs or "continuation header lines" for
transmission through the network.
c. All lines in news messages, including header lines, shall be
terminated with a LINE FEED (ASCII 10 decimal) ONLY. Under NO
circumstances shall a CARRIAGE RETURN (ASCII 13 decimal) appear in
news messages transmitted through FidoNet (if a Carriage Return is
found in an in-transit message it MAY be changed to a Line Feed, this
being the sole exception to the rule about not changing the body of a
message, but the expectation is that no Carriage Returns will appear
in a news message). Also, spaces appearing at the end of lines (just
prior to the Line Feed character) are strongly discouraged since they
convey no useful information. Finally, there should be only a single
line feed at the end of each message (blank lines following the last
line of a message are not allowed, again because they convey no useful
information). Please note that the use of the Line Feed as a line
terminator is fairly standard throughout UseNet, and when a news
message is converted to a FidoNet format message it is a simple matter
to replace Line Feeds with Carriage Returns so that the message will
display properly.
d. When constructing or adding to "Path" lines, RFC-1036 (section
2.1.6) states that "The names may be separated by any punctuation
character or characters (except '.' which is considered part of the
hostname)." However, in actual practice, only the "!" (exclamation
point or "bang" character) is commonly used to separate names.
Therefore, the "!" character will be considered the "standard"
separator for system names in Path lines in messages generated in
FidoNet. Also, RFC-1036 states that "Normally, the rightmost name
will be the name of the originating system. However, it is also
permissible to include an extra entry on the right, which is the name
of the sender. This is for upward compatibility with older systems."
In actual practice, it appears that most Path lines originating in
UseNet have a user name as the rightmost entry. Therefore, when a
Path line is created for a message originating in FidoNet, it is
suggested that the following format be used (assuming a message
entered by user John Smith at node 1:123/456):
Path: f456.n123.z1.fidonet.org!john.smith
When a user name is placed in the path, all spaces in the user name
must be replaced with periods, and all uppercase characters in the
name should be converted to lowercase. It is permissible to use an
alias in place of a user's real name if the originating system runs
software that will recognize that alias in incoming netmail messages,
and remap such messages to the proper user if necessary. Also, note
the restrictions on prohibited characters in the user name as
specified in RFC-1036 section 2.1.1. Although section 2.1.1. deals
with the "From" line, common sense would indicate that these same
restrictions on prohibited characters should apply if the user name is
placed in the Path line (with the obvious exception of the use of the
period to replace spaces in the user name, which is required).
e. Header lines defined as "optional" may be more or less optional
depending on the keyword. For example, the "Reply-To" and
"Followup-To" lines should be automatically honored, if at all
FIDONEWS 14-16 Page 17 21 Apr 1997
possible, when reply messages are created, and the "References" line,
even though listed as an "optional" line, is "required for all
follow-up messages" (replies). On the other hand, lines such as
"Control" and "Distribution" may have little meaning to FidoNet nodes
(in particular, "Distribution" is meant to control distribution of a
message along hierarchial lines, but since FidoNet topology has little
relation to UseNet hierarchies, it is probably best to just ignore
"Distribution" lines on in-transit messages).
Additional specifications for messages, including required and
optional header lines, are detailed in section 2 of RFC-1036.
When a newsgroup is moderated, it is the responsibility of the sysop
of each participating BBS to prevent users from entering messages in
that area (unless the message exporting software is capable of sending
any locally-entered messages to the conference moderator via MAIL).
However, if a software newsgroup processor is written that both
imports (tosses) messages to a FidoNet-format message base, and
exports locally entered messages, and if the software does not have a
way to send replies to the moderator via mail, then some mechanism
must be provided to prevent the export of messages from a moderated
area, so that in the unlikely event that there is no easy way to
prevent users from posting messages in the moderated area, such
messages will still not be sent out. Since this standard does not
deal with the transport of UseNet MAIL within FidoNet, the method for
transmission of replies in moderated newsgroups is undefined by this
document. However, software authors are encouraged to provide some
mechanism for private mail replies to newsgroup messages, in both
moderated and unmoderated areas.
Note that if a moderated newsgroup is carried on a system, it is the
responsibility of the sysop to provide mail access to users so that
replies can be (manually) sent to the conference moderator, especially
if replies in the newsgroup area cannot be automatically routed to the
conference moderator.
One point that needs to be emphasized is there is NO message length
limit on UseNet messages. If a FidoNet node passes newsgroup messages
to, or on behalf of other FidoNet nodes, it is NOT permissible to
discard or truncate messages that exceed a preset length limit. Note
that in a batched newsgroup file, each message is preceded by a header
of the form "#! rnews <length in bytes>". Since the message text
length is never changed in processing, it is possible to determine the
length of a message after processing by reading in all the header
lines, calculating the combined length of the header lines prior to
making changes in the header (e.g. the Path line), then calculating
the combined length of the header lines after making changes. The
difference between the original and the new length of the header lines
can then be applied to the value given in the "#! rnews" line to
determine the new message length, when is then used in the "#! rnews"
header of the modified message. Also, the number of bytes given in
the "#! rnews" line, MINUS the length of the message header lines, is
the length of the body of the message. Once this length is known, the
body of the message can be copied from the input file to the output
file(s) in "chunks" small enough to fit in memory, until the end of
the message is reached.
FIDONEWS 14-16 Page 18 21 Apr 1997
The following comments are implementation suggestions applicable to
current FidoNet-compatible BBS systems, though not necessarily to
software that may be written in the future:
It should be noted that when a BBS user enters a reply message, most
FidoNet BBS software will "link" the reply message to the original by
placing the message number of the original message in the message
header (this is almost always the case if messages are stored in the
"*.msg" format, in which case the number of the message being replied
to is found at bytes 185-186 in the message header). If the
appropriate header lines have been stored in the text of the original
message, it is possible to construct a reply message that meets all
RFC-1036 specifications. For example, a "References" line can be
constructed from the "Message-ID" line (and the "References" line, if
any) of the original message. Similarly, if the original message
contains a "Followup-To:" line, the reply can be posted to the
newsgroup(s) specified in that line. This may not work as expected if
a message renumbering program or similar program messes with the
message base before reply message is exported, so it is highly
recommended that locally-entered newsgroup messages be exported as
soon as practicable after they are entered.
Since the user of a BBS may reply to a message entered by another user
of the same BBS, it is recommended that when a message is exported,
any UseNet format header lines created for the exported message also
be written back to the original message if possible. This will permit
reply linking to remain intact even if two or more users of the same
BBS participate in the same message thread.
If a message is received that specifies more than one newsgroup in the
"Newsgroups" header line, and corresponding message areas are
available on the local system, one copy of the message should be
placed in each such area. For example, if the message is posted to
four different newsgroups, and two of those groups are carried on the
local BBS, then a copy of the message should be placed in the message
base for each of those groups. If users of a BBS are allowed to post
a message to multiple newsgroups, then any message thus posted should
be copied to the message bases of any of the other areas that are also
carried on that system (and that the message was posted to) at the
time the message is exported.
Corrections and Additions to this document:
Proposed corrections and additions to this document should be
submitted to Jack Decker at 1:154/8, or
[email protected]
[Jack Decker is still around and wishes me to include his greeting to
FidoNet and give his Internet address for anyone who wishes to say
hello or discuss his FSC. He may be reached at:
[email protected] or
[email protected]
or his homepage at:
http://www.novagate.com/~jack
He also recommends
http://www.techknowtimes.com for tech types.] Ed.
FIDONEWS 14-16 Page 19 21 Apr 1997
-30-
-----------------------------------------------------------------
Document: FSC-0060
Version: 001
Date: 08-Mar-1992
Calculation and Usage of CRC's
Frank van der Loos
2:285/305.4
Status of this document:
This FSC contains information of value to the general FidoNet(r)
community. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
This document is written by :
Frank van der Loos
Torenstraat 123
3311 TR Dordrecht
The Netherlands (Europe)
FIDO mail : 2:285/305.4
Thanx to :
Willem van Pelt
FIDO mail : 2:285/305
- for giving me a mail-box :-))
- for telling me some theoretical stuff about CRC's
Richard Faasen (Yeaahh "Pfjew" he says)
FIDO mail : 2:285/311
- for giving me some CRC programs
Arie Ballegooyen
FIDO mail : 2:283/300
- for giving me all the original FTS & FSC doc's
This document is a DOC in which the CRC encoding and some usages of
this encoding are explained. Also some routines are included. In some
of the FTS & FTC doc's the encoding is very badly and sometimes wrong
explained this will take a lot of time when you are planning to
program a CRC encoding routine instead of using a routine which is
made by someone. I will also include some routines and also the scheme
to make a CRC routine so you can easily make a CRC check routine
yourself in your program.
What is a CRC :
Simply explained a CRC is a division and the remainder is the CRC
value. I think this example will help you to understand it :
FIDONEWS 14-16 Page 20 21 Apr 1997
1011 / 10011101 \
1011
----
1011
1011
----
001 (This is the CRC value)
Look familiar to division as you are used to learn at school. But
there are some differences.
When subtracting a bit the following table is used :
0 - 0 = 0
0 - 1 = 1
1 - 0 = 1
1 - 1 = 0
There is a function called XOR which will use this table. When you are
subtracting 0-1 = 1 then there is a shortage and normally you will
take a higher bit to complete to subtraction.
234
91 -
-----
143
You cut 200 to 100 because 3-9 = negative. But with the CRC you
DO NOT use this !!!
The divisor used with CRC encoding is a divisor with 1 bit more then
de actual CRC. This is explained by the remainder which is always 1
bit less then the divisor. If not then you can divide it a time again,
not?
Now you have to perform dividing on a row of char's and you can't do
that without a special trick. What you do is shifting all the bits one
by one into the CRC value and then checking if you can perform a
division. Lets have a look at this example :
1011 / 10011101 \
We are gonna use a CRC of 3 bits (the highest bit is always cut).
The first bit is the checkbit. We can divide if this bit is 1. In that
case the value is big enough to divide.
x 100 no we can not divide
perform a shift to left and shift in the next bit.
1 001 yes we can divide
divide it by 1011
0 010 the divided value (XOR'ed)
we can not divide so shift to left and shift in the next bit.
0 101 the shifted value + shifted bit.
we can not divide so shift to left and shift in the next bit.
1 011 the shifted value + shifted bit.
divide it by 1011
0 000 the divided value (XOR'ed)
FIDONEWS 14-16 Page 21 21 Apr 1997
we can not divide it so shift to left and shift in the next
bit.
0 000 the shifted value + shifted bit.
we can not divide it so shift to left and shift in the next
bit.
0 001 the shifted value + shifted bit.
we can not divide it so shift to left and shift in the next
bit. OOOppps sorry the bits are gone so this is the
remainder
001 The 3 bit remainder (is 1 less then the divisor)
0 101 no we can not divide so
no we can not divide
shift to left and take the next bit.
1 011 yes we can divide
0 000 the divided value (XOR'ed)
0 001 okay we have shifted again to left and took again the next
bit.
0 010 again
0 101 again
Compare it to the division performed at page 1 and you will see the
result is the same. But this method is more comfortable for computers.
In fact it is the same way to divide but we as humans can take more
bits and we can see direct if it is possible to divide and the
computer can not. But if we have to check every bit it will take a
lot of time to put in every time 1 bit by bit. Now luckily for you
that is not necessary. The computer and also your program can shift in
byte per byte. But then you have to try the division 8 times every
time you have putted in a byte. And the byte you have put in has to
fit in your CRC. So when you have a CRC which is 2 bits in length than
it won't fit of course. But generally a 16 bit CRC is used and even
CRC32 are now in use. When in the near future CRC64 are used I'm not
surprised. Okay now to the computer programming stuff. Here is a table
with a good method to implement a CRC16 in any language. After this a
program is stated with all the documentation in it. Remember a CRC16
has a 17bit divisor. Bit 16 (As you know we start at bit 0) is 1. When
not we have again a smaller divisor.
CRC : wordvalue
{ This routine has to be executed 8 times }
IF CRC bit 15 = 1
then
shift left 1, divide by divisor (16 bits)
else
shift left 1, {do not divide cause we can't}
{After this put in the next byte}
CRC = CRC + inputbyte
{end of this routine}
Simple isn't it. Now for the more experienced programmers a sample in
pascal at the next page.
FIDONEWS 14-16 Page 22 21 Apr 1997
inpbyte = input byte for CRC
oldCRC = old crc value
divisor = the least 16 bits of the divisor string
Function CRC16 ( inpbyte : byte, oldCRC : word, divisor : word ) :
word ;
var
tel : word;
temp : word; {A simple variable to use to store the CRC)
begin
temp := oldCRC;
for tel := 1 to 8 do
begin
If (temp and $8000)= $8000
then
begin
temp := temp shl 1;
temp := temp xor divisor;
end
else
begin
temp := temp shl 1;
end;
{ Now we have to put in the next byte }
temp := temp xor inpbyte;
CRC16 := temp;
end;
{End of routine}
This routine is easily to expand to CRC32. In that case you have to
expand your divisor and temp and CRC function to LONG value's.
Some additional information about CRC's :
CRC16 divisor = $1021 ( + bit 16 = $3021 )
The CRC16 feed value (when you first call the CRC routine) is $0000
CRC32 divisor = $77073096 ( + bit 32 = $17707306 )
The CRC32 feed value (when you first call the CRC routine) is
$FFFFFFFF
-30-
-----------------------------------------------------------------
FIDONEWS 14-16 Page 23 21 Apr 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 108
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-080|Nodelist-087|Nodelist-094|Nodelist-101|Nodelist-108|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 9088| 9088 0 | 8900 -188 | 8837 -63 | 8675 -162 |32|
| 2 | 15956|15923 -33 |15922 -1 |15902 -20 |15993 91 |59|
| 3 | 800| 800 0 | 800 0 | 800 0 | 800 0 | 3|
| 4 | 548| 548 0 | 549 1 | 548 -1 | 547 -1 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1088| 1090 2 | 1090 0 | 1083 -7 | 1083 0 | 4|
+----+------+------------+------------+------------+------------+--+
| 27567|27536 -31 |27348 -188 |27257 -91 |27185 -72 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-16 Page 24 21 Apr 1997
=================================================================
NET HUMOR
=================================================================
[postponed from April Fool's Day]
To:
[email protected]
From:
[email protected]
Subject: Top5 -4/1/97- April Fool's Day Pranks to Pull on Programmers
Errors-To:
[email protected]
Date: Mon, 31 Mar 1997 20:18:24 MST
================================================================
T H E T O P F I V E L I S T
================================================================
Sponsored by Windows Sources
Windows Sources Expert Answers for ActiveX:
Interested in websites offering free ActiveX controls?
Get the latest from expert Larry Seltzer.
http://www.winsources.com
================================================================
To forward or repost, please include the following:
[ This list copyright 1997 by Chris White and Ziff Davis, Inc. ]
[ The Top Five List
[email protected] http://www.topfive.com ]
The Top Five List for April 1, 1997
The Top 16 April Fool's Day Pranks to Pull on Programmers
16> Using their e-mail address, post a request for penpals to the
alt.prison.bodypiercing newsgroup.
15> Three words: electric mouse buzzer.
14> Assign them to the new "Heaven's Gate" project.
13> "Look, Bill Gates!! Ha! Made ya look!"
12> Put them in the same room with a member of the opposite sex.
11> "Have you got Prince Albert in a LAN?"
10> Tell them that "everyone knows Star Trek transporter technology
is bogus."
9> 10 GOTO 10
7> Swap their monitor for a large cardboard box with handpuppets.
Watch the fur fly!
FIDONEWS 14-16 Page 25 21 Apr 1997
6> Announce that annual raises will be based on a subjective test
of one's ability to "schmooze the way the butt-kissers in
Marketing do."
8> Intercept their daily Top 5 List, then remove #8 and re-insert
it between #5 and #6.
5> Pretend to "discover" a Fox TV website with a now-out-of-date
win a weekend with Gillian Anderson of X-Files contest.
4> Every hour, on the hour, forward them a warning about the
"Good Times" virus.
3> Call her up and ask if her program is running, and when she
says "yes," tell her "Well you better go catch it!"
2> Replace all the Jolt in the soda machine with Perrier and V8.
and the Number 1 April Fool's Day Prank to Pull on Programmers...
1> Special announcement: "Forget Java -- Starting immediately,
all coding will be done in COBOL."
Selected from 83 submissions from 37 contributors.
Today's Top Five List authors are:
----------------------------------------------------------------
Kermit Woodall, Richmond, VA -- 1, 5 (3rd #1)
Phil Doyle, Mercer Island, WA -- 2, 4
Jennifer Ritzinger, Seattle, WA -- 2
Craig Stacey, St. Paul, MN -- 3
Dave Wesley, Pleasant Hill, CA -- 6
Bob Mader, Knoxville TN -- 8
Lev L. Spiro, Los Angeles, CA -- 7
Tony Hill, Minneapolis, MN -- 9, 14 (Hall of Famer)
Alan Smithee, Sugar Land, TX -- 10
Michael Wolf, Brookline, MA -- 11
Marshal Perlman, Minneapolis, MN -- 12
Sue Prifogle, Rushville, IN -- 13, Topic
Alexander Clemens, San Francisco, CA -- 14
Bruce Ansley, Baltimore, MD -- 15 (Hall of Famer)
Marianne Tatom, Austin, TX -- 16
Chris White, New York, NY -- List owner/editor
----------------------------------------------------------------
Today's Runners Up list, "Millenium Falcon Bugs",
can be found at our website:
http://www.topfive.com
================================================================
T H E T O P F I V E L I S T
To subscribe: Send mail to
[email protected]
To unsubscribe: Send mail to
[email protected]
For more information: Send mail to
[email protected]
with "INFO" in the *subject* line of the message.
To report a sighting of a Top Five List in other media:
Send mail to
[email protected] with "BINGO!" in the *subject*.
FIDONEWS 14-16 Page 26 21 Apr 1997
================================================================
Ruminations & Ponderances
I just can't seem to shake the feeling that I'm
being followed, and neither can my Siamese twin.
(Thanks to Doug Rendall)
================================================================
Sponsored by Windows Sources
http://www.winsources.com
This delivery powered by Mercury Mail, Inc.
http://www.merc.com
================================================================
-----------------------------------------------------------------
Date: Thu, 17 Apr 1997 19:04:03 -0700
From: Shari <
[email protected]>
Organization: OREGON - USA
To:
[email protected]
Subject: e-mail posts
References: <
[email protected]>
Sender:
[email protected]
Reply-To:
[email protected]
Q: How many internet mail list subscribers does it take
to change a light bulb?
A: 1,331:
1 to change the light bulb and to post to the mail list that the
light bulb has been changed
14 to share similar experiences of changing light bulbs and how
the light bulb could have been changed differently.
7 to caution about the dangers of changing light bulbs.
27 to point out spelling/grammar errors in posts about changing
light bulbs.
53 to flame the spell checkers
156 to write to the list administrator complaining about the light
bulb discussion and its inappropriateness to this mail list.
41 to correct spelling in the spelling/grammar flames.
109 to post that this list is not about light bulbs and to please
take this email exchange to alt.lite.bulb
203 to demand that cross posting to alt.grammar, alt.spelling and
alt.punctuation about changing light bulbs be stopped.
111 to defend the posting to this list saying that we all use
light bulbs and therefore the posts **are** relevant to
this mail list.
306 to debate which method of changing light bulbs is superior,
where to buy the best light bulbs, what brand of light
bulbs work best for this technique, and what brands are
faulty.
27 to post URLs where one can see examples of different light bulbs
14 to post that the URLs were posted incorrectly, and to post
corrected URLs.
3 to post about links they found from the URLs that are relevant
FIDONEWS 14-16 Page 27 21 Apr 1997
to this list which makes light bulbs relevant to this list.
33 to concatenate all posts to date, then quote them including all
headers and footers, and then add "Me Too."
12 to post to the list that they are unsubscribing because they
cannot handle the light bulb controversy.
19 to quote the "Me Too's" to say, "Me Three."
4 to suggest that posters request the light bulb FAQ.
1 to propose new alt.change.lite.bulb newsgroup.
47 to say this is just what alt.physic.cold_fusion was meant for,
leave it here.
143 votes for alt.lite.bulb.
-30-
-----------------------------------------------------------------
FIDONEWS 14-16 Page 28 21 Apr 1997
=================================================================
NOTICES
=================================================================
Future History
17 May 1997
Independence Day, Norway.
3 Jun 1997
2 years since FidoNet had an International Coordinator.
6 Jun 1997
National Commemoration Day, Sweden.
12 Jun 1997
Independence Day, Russia.
1 Jul 1997
Canada Day - Happy Birthday Canada.
9 Jul 1997
Independence Day, Argentina.
13 Oct 1997
Thanksgiving Day, Canada.
1 Dec 1997
World AIDS Day.
10 Dec 1997
Nobel Day, Sweden.
12 Jan 1998
HAL 9000 is one year old today.
22 May 1998
Expo '98 World Exposition in Lisbon (Portugal) opens.
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
1 Jan 2000
The 20th Century, C.E., is still taking place thru 31 Dec.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
1 Jan 2001
This is the actual start of the new millennium, C.E.
-- If YOU have something which you would like to see in this
FIDONEWS 14-16 Page 29 21 Apr 1997
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 14-16 Page 30 21 Apr 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Good news: I've finally got the GEcho entries in the list.
Peter Karlsson, the author of Announcer, has set up a home page for
his software:
http://www.mds.mdh.se/~dat95pkn/wolves/announcer.htm
Note: At the end of April, I'll be phasing out the old Macintosh
section. As always, I'll be happy to process any information I get,
either before or after it is phased out.
Note: Mid-May, I will phase out the entire "Old Info" section.
-=- Snip -=-
Submission form for the Latest Greatest Software Versions column
OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :
Please include a sentence describing what the package does.
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.11 O S Peter Karlsson 2:206/221 ANNOUNCE
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
CheckPnt 1.0a O G Michiel vd Vlist 2:500/9 CHECKPNT
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO
FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S JoHo 2:201/330 FD
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO
GEcho 1.00 T S Bob Seaborn 1:140/12 GECHO
FIDONEWS 14-16 Page 31 21 Apr 1997
GEcho/Plus 1.11 T C Bob Seaborn 1:140/12 GECHO
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
GoldED/386 2.50 O S Len Morgan 1:203/730 GEX
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.21 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
MakePl 1.9 N G Michiel vd Vlist 2:500/9 MAKEPL
Marena 1.1 beta O G Michiel vd Vlist 2:500/9 MARENA
Maximus 3.01 B P Tech 1:249/106 MAX
McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP
Msged 4.10 O G Andrew Clarke 3:635/728 MSGED41D.ZIP
Msged/386 4.10 O G Andrew Clarke 3:635/728 MSGED41X.ZIP
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.65 O S Peter Hampf 2:241/1090 OT
PcMerge 2.8 N G Michiel vd Vlist 2:500/9 PCMERGE
PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP
QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS
RAR 2.00 C S Ron Dwight 2:220/22 RAR
RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP
Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE
Squish 1.11 T P Tech 1:249/106 SQUISH
StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK
StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Telegard 3.02 B F Tim Strike 1:259/423 TELEGARD
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TransNet 1.00 G S Marc S. Ressl 4:904/72 TN100ALL.ZIP
TriBBS 11.0 B S Gary Price 1:3607/26 TRIBBS
TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG
TriToss 11.0 T S Gary Price 1:3607/26 TRITOSS
WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
XRobot 3.01 O S JoHo 2:201/330 XRDOS
OS/2:
FIDONEWS 14-16 Page 32 21 Apr 1997
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S JoHo 2:201/330 XROS2
Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
FrontDoor APX 1.11 P S Mats Wallin 2:201/329 FDAPXW
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
Maximus 3.01 B P Tech 1:249/106 MAXN
Msged/NT 4.10 O G Andrew Clarke 3:635/728 MSGED41W.ZIP
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT
WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP
WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP
Unix:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ifmail 2.9 M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX
ifmail-tx.rpm ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
FIDONEWS 14-16 Page 33 21 Apr 1997
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPDOOR
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPBETA
TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS
Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY
Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA
Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, F-Fossil, O-Other. Note: Multifunction will
be listed by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems Other Utilities Other Utilities
-------------- Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
FIDONEWS 14-16 Page 34 21 Apr 1997
PKPak 3.61 GMM 1.21 TGroup 1.13
PKZip 1.10 GROUP 2.23 TIRES 3.11
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
SysNL 3.14 MsgLnk 1.0c XST 2.3e
XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00
XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25
MSGTOSS 1.3 ZSX 2.40
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BBS Software Macintosh Other Software
Name Version --------- Name Version
-------------------- --------------------
FBBS 0.91 Network Mailers MacArd 0.04
Hermes 1.6.1 Name Version Mantissa 3.21
Mansion 7.15 -------------------- Mehitable 2.0
Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0
Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2
Telefinder Host StuffIt Classic 1.6
2.12T10 Other Software SunDial 3.2
Name Version TExport 1.92
-------------------- TimeStamp 1.6
Point System ArcMac 1.3 TImport 1.92
Software AreaFix 1.6 Tset 1.3
Name Version Compact Pro 1.30 TSort 1.0
-------------------- EventMeister 1.0 UNZIP 1.02c
Copernicus 1.00 Export 3.21 Zenith 1.5
CounterPoint 1.09 Import 3.2 Zip Extract 0.10
MacWoof 1.1 LHARC 0.41
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 14-16 Page 35 21 Apr 1997
=================================================================
FIDONEWS PUBLIC-KEY
=================================================================
[this must be copied out to a file starting at column 1 or
it won't process under PGP as a valid public-key]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
Comment: Clear-signing is Electronic Digital Authenticity!
mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
+Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
=61OQ
-----END PGP PUBLIC KEY BLOCK-----
File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on
the FidoNews homepage listed in the Masthead information.
-----------------------------------------------------------------
FIDONEWS 14-16 Page 36 21 Apr 1997
=================================================================
FIDONET BY INTERNET
=================================================================
This is a list of all FidoNet-related sites reported to the Editor as
of this appearance.
============
FidoNet:
Homepage
http://www.fidonet.org
FidoNews
http://ddi.digital.net/~cbaker84/fidonews.html
HTML FNews
http://www.geocities.com/Athens/6894/
WWW sources
http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
FTSC page
http://www2.blaze.net.au/ftsc.html
Echomail
http://www.portal.ca/~awalker/index.html
WebRing
http://ddi.digital.net/~cbaker84/fnetring.html
============
Zone 1:
http://www.z1.fidonet.org
Region 10:
http://www.psnw.com/~net205/region10.html
Region 11:
http://oeonline.com/~garyg/region11/
Region 13:
http://www.smalltalkband.com/st01000.htm
Region 14:
http://www.netins.net/showcase/fidonet/
Region 15:
http://www.smrtsys.com/region15/ [disappeared?]
Region 16:
http://www.tiac.net/users/satins/region16.htm
Region 17:
http://www.portal.ca/~awalker/region17.htm
Region 18:
http://www.citicom.com/fido.html
Region 19:
http://home1.gte.net/bhamilt/index.htm
============
Zone 2:
http://www.z2.fidonet.org
ZEC2:
http://fidoftp.paralex.co.uk/zec.htm [shut down?]
Zone 2 Elist:
http://www.fidonet.ch/z2_elist/z2_elist.htm
Region 20:
http://www.fidonet.pp.se (in Swedish)
Region 24:
http://www.swb.de/personal/flop/gatebau.html (in German)
Region 25:
http://members.aol.com/Net254/
Region 27:
http://telematique.org/ft/r27.htm
FIDONEWS 14-16 Page 37 21 Apr 1997
Region 29:
http://www.rtfm.be/fidonet/ (in French)
Region 30:
http://www.fidonet.ch (in Swiss)
Region 34:
http://www.pobox.com/cnb/r34.htm (in Spanish)
REC34:
http://pobox.com/~chr
Region 36:
http://www.geocities.com/SiliconValley/7207/
Region 41:
http://www.fidonet.gr (in Greek and English)
Region 48:
http://www.fidonet.org.pl
============
Zone 3:
http://www.z3.fidonet.org
============
Zone 4: (not yet listed)
Region 90:
Net 904:
http://members.tripod.com/~net904 (in Spanish)
============
Zone 5: (not yet listed)
============
Zone 6:
http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-16 Page 38 21 Apr 1997
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Christopher Baker
Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar, Sylvia Maxwell,
Donald Tees
"FidoNews Editor"
FidoNet 1:1/23
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)
more addresses:
Christopher Baker -- 1:18/14,
[email protected]
[email protected]
[email protected]
(Postal Service mailing address)
FidoNews Editor
P.O. Box 471
Edgewater, FL 32132-0471
U.S.A.
voice: 1-904-409-3040 [1400-2100 ET only, please]
[1800-0100 UTC/GMT]
------------------------------------------------------
FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1997 Christopher Baker. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.
=*=*=*=*=*=*=*=*=
OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSEnn.ZIP] for a
FIDONEWS 14-16 Page 39 21 Apr 1997
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in
size from 48K to 1.4M.
INTERNET USERS: FidoNews is available via:
http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.aminet.org/pub/aminet/comm/fido/
*=*=*
You may obtain an email subscription to FidoNews by sending email to:
[email protected]
with a Subject line of: subscribe fnews-edist
and no message in the message body. To remove your name from the email
distribution use a Subject line of: unsubscribe fnews-edist with no
message to the same address above.
*=*=*
You can read the current FidoNews Issue in HTML format at:
http://www.geocities.com/Athens/6894/
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.
=*=*=*=
The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:
http://ddi.digital.net/~cbaker84/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
A PGP generated public-key is available for the FidoNews Editor from
FIDONEWS 14-16 Page 40 21 Apr 1997
1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It
is also posted twice a month into the PKEY_DROP Echo available on the
Zone 1 Echomail Backbone.
*=*=*=*=*
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators
also have copies of ARTSPEC.DOC. Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
and are used with permission.
"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings
-30-
-----------------------------------------------------------------
