informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1413.nws
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

2642 lines
119 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

F I D O N E W S -- Volume 14, Number 13 31 March 1997
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-904-409-7040 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:18/14 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: FidoNews Editor 1:1/23 |
+----------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=> cbaker84@digital.net |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
THE FIDONET <> INTERNET GATING IS STILL WORKING
Table of Contents
1. EDITORIAL ................................................ 1
The uucp Gates STILL work and a NEW Section! ............. 1
2. LETTERS TO THE EDITOR .................................... 2
Letter to the Editor: Comments on Fidonews ............... 2
3. ARTICLES ................................................. 4
Where'd Guucp 1:13/10 go? ................................ 4
AOP Plans Summit '97! .................................... 9
Impressed and Encouraged! ................................ 10
More bugs in MS Internet Explorer & Netscape in Windows .. 13
4. GETTING TECHNICAL ........................................ 18
5. COORDINATORS CORNER ...................................... 34
Nodelist-statistics as seen from Zone-2 for day 087 ...... 34
6. COMIX IN ASCII ........................................... 35
Another Dumb-ASCII Pun ................................... 35
7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 36
Nanet Nodes take note .................................... 36
8. NOTICES .................................................. 37
Future History ........................................... 37
Opus marches on starting 1 May 97! ....................... 38
9. FIDONET SOFTWARE LISTING ................................. 39
Latest Greatest Software Versions ........................ 39
10. FIDONEWS PUBLIC-KEY ..................................... 44
FidoNews PGP public-key listing .......................... 44
11. FIDONET BY INTERNET ..................................... 45
And more!
FIDONEWS 14-13 Page 1 31 Mar 1997
=================================================================
EDITORIAL
=================================================================
I inadvertently stirred up some panic last week with the news that
1:13/10 was down and the FidoNet - Internet gate was closed. Cancel
that panic. [grin]
1:13/10 IS down but I have been informed of hundreds of alternates
in action as we read. Burt Juda still operates the FidoNet DNS and
although those linked to him for such transfers thru 1:13/10 are now
traffickless, those linked to one of the other Gates should still be
moving mail. I wouldn't have noticed if I hadn't been a registered
user of that particular linkage.
There is an article down the pages that applies to the 1:13/10 ops
ONLY! It has been updated since it was pre-published in several of
the major Sysop Echos. The updated version will likewise appear in
those Echos to clear up any excitement and misapprehension.
On FidoNews, there is now a Letters to the Editor Section. It is the
first Section that appears after the Editorial info areas. There you
may rant or rail or wax poetic to me, as Editor, or the rest of
FidoNet if you're not in the mood to send your stuff in as an article
[.ART].
The new extension for this area is: .LET and the first one appears in
today's Issue at the suggestion of that writer. An updated ARTSPEC has
already been hatched into the FIDONEWS and SDS SOFTDIST file echos as
well as being copied into the FIDONEWS Echo and placed on the FidoNews
webpage.
[Just happened: The addition of the .LET file extension created a
conflict for MAKENEWS so the extension for retractions has just been
changed to .RTX and the ARTSPEC doc and .ZIP rehatched.]
On another front, any news on the IC election?
C.B.
-----------------------------------------------------------------
FIDONEWS 14-13 Page 2 31 Mar 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
Letter to the Editor: Comments on Fidonews
by Dave Aronson, Sysop of Air 'n Sun, 1:109/120.0
Okay, Chris, you asked a while back for comments on the changes in
Fidonews... you got it.
Firstly, something I've always disliked about Fidonews. In fact, I
have the same bone to pick with lots of shareware authors who do this
in their .doc files. This is an electronic publication, so WHY is it
formatted for printing ON PAPER? Gimme plain ASCII text, with no
formfeeds or page numbering (tho LINE numbering could be useful!) or
other junk that's utterly useless for viewing online. Of all such
bogosities, especially, NO LEFT MARGINS!!! This thing is being
shipped and stored all over the world, plus there are a gazillion
trivial little programs out there to *add* a left margin (and even
to break into pages and number the pages), so why make us ship and
store all that useless empty space? Restricting the RIGHT margin to
column 70 is fine --that won't force fugly rewrap on most systems, and
gives those who WANT to print it out, some room for a margin. But
forcing a LEFT margin on us all??? That might even force fugly rewrap
on some BBS systems notorious for not liking text over 72 columns
wide....
Secondly, this huge conglomeration of stuff that's essentially the
same from week to week. Mostly, that's the lists, like of Fidonet
compatible software or of web pages about Fidonet. That could be far
more efficiently replaced by a list of CHANGES from last week, and
maybe a reference to where we could freq a list. (Yes, FREQ, not
ftp, or browse a @#$%^&* web page!) Then there's the boilerplate junk
at the end. Come on, do we really need all that every week? Again,
just give us the bare bones and tell us how to get the whole megillah.
To placate those whining "but freqing is sooooo expensive!", perhaps a
"docserver" could be setup, whereby someone would email a given name
at a given node, and be emailed back a copy of the document, all of
which could take place via cheap netmail routing. The latest version
of NetMgr claims to be able to do this, and at the moment, I am trying
it; send email to "docserv" (w/o quotes) at 1:109/120.0, with subject
line including the word(s) "description", "echolist", "gunflyer",
and/or "jewishflyer" (again, w/o quotes), to try it out --it should
get you one emailed document back per such message.
Thirdly, I dunno about you, but I suspect that the vast majority of
even the regular readers have been skipping past the reposted Fidonet
Technical Standards. I sure have, aside from an occasional brief
skimming of the first couple screens! Stuff like that is why so many
call it "da Snooze"! Once again, a summary, plus an announcement of
where such things could be freqed or docserved (or, <sigh>, ftped or
browsed) would be a lot more efficient. Perhaps instead if someone
who has taken the time to read and understand this stuff could post a
brief "review" of each of the standards in turn, including their
significance to Fidonet's modern operation, IMHO that could be QUITE
FIDONEWS 14-13 Page 3 31 Mar 1997
"newsworthy".
Fourthly, I suggest a new "extension", .LET, specifically for "Letters
to the Editor".
Fifthly... where's all the smart folks, er, articles at? B-) Yeah,I
know, I know... some more ASCII art is on the way!
-----------------------------------------------------------------
FIDONEWS 14-13 Page 4 31 Mar 1997
=================================================================
ARTICLES
=================================================================
[The following is the digest of a conversation between Alan Rackmill
and your Editor. He responded to my posting in FIDONEWS Echo asking
about the disappearance of 1:13/10 and the fidonet.org Internet Gate.
It is published with his permission.] Ed.
[This applies to the uucp Gate at 1:13/10 ONLY!! fidonet.org mail IS
flowing at other gates according to other sources.] Ed.
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Tue Mar 25 20:38:32 1997
From: Alan Rackmill @ 1:107/101
To: Christopher Baker @ 1:18/14
Date: 25 Mar 97 15:13:10
Subj: FidoNews 1412 is in the can!
* Forwarded (from: FIDONEWS) by Alan Rackmill using timEd/2 1.01.
* Originally from Alan Rackmill (1:107/101) to Christopher Baker.
* Original dated: Mar 25 '97, 14:57
Christopher Baker wrote in a message to All:
CB> Where DID Guucp 1:13/10 go and why?
CB>
Sorry about that.
I should have spread the word further than I did.
13/10 as known and loved in the past is dead.
During an equipment move, the equipment decided enough was enough and
refused to restart when plugged back in.
Sort of like a fatal heart attack.
At the same time, Burt's personal machine also went south and didn't
return.
The gateway machine is/was owned by Burt's employer, and the decided
to not replace the computer, so 13/10 had nothing to run on.
The good news is that we are working on a replacement for the gateway
and should have it back up in two or 3 weeks.
It will not be physically located where it was, nor will Burt be
running it, but it will be the gateway again for internet<>fidonet
Email.
He is, however, very involved in getting the gateway back in action
The usegroups may become available in the future, but that is not
certain.
I will keep everyone up to date as things develop.
FIDONEWS 14-13 Page 5 31 Mar 1997
Alan
Team OS/2,
Fidonet 1:107/101, ibmNET 40:4371/101, OS2NET 80:135/15
internet: alanrack@ix.netcom.com
___ timEd/2 1.01
- Origin: The Maven's Roost * MAX/2 * WARP * v.34 1-908-821-4533
(1:107/101)
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Tue Mar 25 20:39:04 1997
From: Christopher Baker @ 1:18/14
To: Alan Rackmill @ 1:107/101
Date: 25 Mar 97 19:59:56
Subj: Re: FidoNews 1412 is in the can!
> Sorry about that.
> I should have spread the word further than I did.
are you the Guucp guru now?
> 13/10 as known and loved in the past is dead.
what happens to fidonet.org mail in the meantime?
> During an equipment move, the equipment decided enough was enough
> and refused to restart when plugged back in.
> Sort of like a fatal heart attack.
okay. i've been able to get that much info.
> At the same time, Burt's personal machine also went south and didn't
> return.
conspiracy? [grin]
> The gateway machine is/was owned by Burt's employer, and the decided
> to not replace the computer, so 13/10 had nothing to run on.
been there.
> The good news is that we are working on a replacement for the
> gateway and should have it back up in two or 3 weeks.
and in the meantime?
> It will not be physically located where it was, nor will Burt be
> running it, but it will be the gateway again for internet<>fidonet
> Email.
> He is, however, very involved in getting the gateway back in action
who is in charge?
> The usegroups may become available in the future, but that is not
FIDONEWS 14-13 Page 6 31 Mar 1997
> certain.
the what?
> I will keep everyone up to date as things develop.
why you?
thanks. can i have this in a FidoNews article after the questions are
answered or can i publish the response?
QOFM.
Chris
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Wed Mar 26 16:21:44 1997
From: Alan Rackmill @ 1:107/101
To: Christopher Baker @ 1:18/14
Date: 25 Mar 97 23:30:21
Subj: FidoNews 1412 is in the can!
Christopher Baker wrote in a message to Alan Rackmill:
> Sorry about that.
> I should have spread the word further than I did.
CB> are you the Guucp guru now?
No, but Burt called me voice when the crash happened, and I sent out a
few messages about it.
> 13/10 as known and loved in the past is dead.
CB> what happens to fidonet.org mail in the meantime?
Unfortunately all mail that went through the gateway is being
returned.
We are trying to get everything setup so that fidonet.org remains as
an entity and get the mail flow back to normal.
> During an equipment move, the equipment decided enough was
> enough and refused to restart when plugged back in.
> Sort of like a fatal heart attack.
CB> okay. i've been able to get that much info.
> At the same time, Burt's personal machine also went south and didn't
> return.
CB> conspiracy? [grin]
Of course.
Or sympathy. ;-))
FIDONEWS 14-13 Page 7 31 Mar 1997
> The gateway machine is/was owned by Burt's employer, and the decided
> to not replace the computer, so 13/10 had nothing to run on.
CB> been there.
> The good news is that we are working on a replacement for the
> gateway and should have it back up in two or 3 weeks.
CB> and in the meantime?
In the meantime, it is like a bridge collapse: nothing gets from one
side of the river to the other until the bridge is rebuilt.
> It will not be physically located where it was, nor will Burt
> be running it, but it will be the gateway again for
> internet<>fidonet Email.
> He is, however, very involved in getting the gateway back in action
CB> who is in charge?
Steven Reinen, 107/700 has a dedicated connect to the internet and
Burt is working with him to get everything moved over to his system.
> I will keep everyone up to date as things develop.
CB> why you?
Why not?
I can get to Burt voice, and I dug up Steven as a replacement for the
gateway ** accidently, I must admit ** and I am the new NC here in net
107.
And being retired, I have the time to keep up with everything.
CB> thanks. can i have this in a FidoNews article after the
CB> questions are answered or can i publish the response?
You may publish this response, since I am not good at writing "formal"
articles.
Alan
Team OS/2,
Fidonet 1:107/101, ibmNET 40:4371/101, OS2NET 80:135/15
internet: alanrack@ix.netcom.com
--- timEd/2 1.01
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Wed Mar 26 16:22:10 1997
From: Christopher Baker @ 1:18/14
To: Alan Rackmill @ 1:107/101
Date: 26 Mar 97 16:16:01
Subj: Re: FidoNews 1412 is in the can!
FIDONEWS 14-13 Page 8 31 Mar 1997
> No, but Burt called me voice when the crash happened, and I sent out
> a few messages about it.
okay. i didn't see any. did you tell ZC1? he was unaware of it until i
asked him last week.
> Unfortunately all mail that went through the gateway is being
> returned.
that explains a failure i had last week.
> We are trying to get everything setup so that fidonet.org remains as
> an entity and get the mail flow back to normal.
will Juda maintain that?
> In the meantime, it is like a bridge collapse: nothing gets from
> one side of the river to the other until the bridge is rebuilt.
okay. at least we now know what's going on.
> CB> who is in charge?
> Steven Reinen, 107/700 has a dedicated connect to the internet and
> Burt is working with him to get everything moved over to his system.
okay.
> Why not?
just asking.
> I can get to Burt voice, and I dug up Steven as a replacement for
> the gateway ** accidently, I must admit ** and I am the new NC here
> in net 107.
okay.
> And being retired, I have the time to keep up with everything.
i can relate.
> CB> thanks. can i have this in a FidoNews article after the
> CB> questions are answered or can i publish the response?
> You may publish this response, since I am not good at writing
> "formal" articles.
thanks. a condensed version of the conversation will appear in
FidoNews 1413 next Monday. an Echomail version will appear in FIDONEWS
Echo today and will be cross-posted to several major Sysop Echos for
information to all in the meantime.
QOFM.
Chris
FIDONEWS 14-13 Page 9 31 Mar 1997
-30-
THIS INFORMATION IS CORRECT ONLY AS IT PERTAINS TO THE OPERATIONS OF
THE uucp GATE AT 1:13/10. THE EFFECT OF THE DEMISE OF 1:13/10 IS NOT
GLOBAL ON THE fidonet.org EMAIL MOVEMENT AT THE OTHER GATES.
There are hundreds of other gates linked to the FidoNet DNS that are
still functioning without ever having stalled. Burt Juda IS the DNS
guru with or without the presence of 1:13/10 at present.
My apologies for any undue panic amongst the users of the Internet
gates this discussion of 1:13/10 may have caused.
Ed.
-----------------------------------------------------------------
Submitted by Michele Stewart
1:369/21
Online Summit '97
The AOP 2nd Annual Conference
Planned for September 11-14, Online Summit '97 will be held at the
Town & Country Resort and Conference Center in San Diego, CA. Senator
Ron Wyden (D-OR), the keynote speaker for Online Summit '97 will
address Congress' role in the future of the online world and the
internet.
We are anticipating approximately 500 members to OS'97.
Cost for the event is:
AOP Members Non AOP-Member
Before August 1, 1997 $200 $350
After August 1, 1997 $300 $450
AOP Online Summit '97 Exhibition Rates:
AOP Members Non-AOP Members
10' x 10' booths only $250 $1,000
AOP Online Summit Hotel Information and Rates:
Garden Rooms $95
East Tower Rooms $105
West Tower Rooms $115
(prices are for single or double occupancy)
For room reservations call:
Town & Country Resort and Conference Center
500 Hotel Circle
San Diego, CA 92108
(800) 542-6082 (inside CA)
FIDONEWS 14-13 Page 10 31 Mar 1997
(800) 854-2608 (outside CA)
FAX: (619) 291-3584
960 rooms, in-room movies, beauty salon, barber shop, access to
Health club, complimentary newspapers 6 days, walk to Fashion Valley
shopping.
For Conference Registration or information contact:
Susan Merkel, Director Member Services
ASSOCIATION OF ONLINE PROFESSIONALS
6096 Franconia Road, Suite D
Alexandria, VA 22310
703-924-5800 (voice)
703-924-5801 (fax)
smerkel@bellatlantic.net (email)
Fidonet: 1:109/255
-----------------------------------------------------------------
Impressed and Encouraged!
By: Clay Tannacore (1:372/136)
I have just recently completed reading FIDONEWS (1412), dated 24 March
97. In a guest editorial by a FidoNet SysOp named Carl Hultay
(1:259/546) I believe I detected the traits of the old "comrade in
arms" attitude that at one time was prevalent in the FidoNet
community. It is possible that I misunderstood his rationalization,
but I don't think so. I positively think I have found someone within
the association that literally cares about the imminent problems of
FidoNet. While I can not agree with his introspection regarding the
forecast for FidoNet, I applaud his tenacity. It is heart warming to
hear (read) a fellow Fido-Nut (OOPS) SysOp, at least proclaim his
convictions as to the forthcoming future of our brotherhood.
I can relate to his predicaments concerning the "death of hardware",
and the instinctive feeling of doom, when you are faced with the loss
of a BBS. I (like many thousands before me) have had to endure
similar conditions, on a number of occasions. I sympathize with him
regarding the loss of users, especially due to financial obstacles,
and especially due to the death of a family member (the computer, and
accessories. . .[g] ) However, what disturbs me the most, is his
reference to the "loss of users." For this gentleman to believe that
he will again be able to boast of a user base near one thousand (or
maybe more) without admitting that MANY radical changes will have to
be contrived in the way FidoNet is operated, is a very discouraging
supposition. At present there are just to many opposing forces in
FidoNet, for a restoration to a position once held by this
organization. To many "I want" attitudes , as well as to many "I
gotta' have more power" points of view. Nothing will ever be the
same, not in FidoNet's present mode.
Mr. Hultay speaks of the "commercialism" associated with The Internet.
What he has apparently dismissed in his attempt to disallow the
thought of a FidoNet "doomsday", is that FidoNet is no longer an
FIDONEWS 14-13 Page 11 31 Mar 1997
association completely dominated by hobbyist, but has partially
fallen into The Internet like, "Profit For Me" temperament. Many,
many bulletin boards systems are at the present time directly
competitive with the Internet, in that they conclude that a "pay-for-
use" system is the way to go. "If the Internet can do it, then so
can I" is something that has become an everyday behavior, a behavior
which if it is not discontinued, will eventually bring down FidoNet.
Mr. Hultay goes on to explain his feelings when his computer (hard
drive) developed a *brain fart*, and pooped out. He states that it
was at that this in his life that, "I knew that I was a true SysOp. I
could not give up. I *WANTED* my BBS." Mister, if that was your
*TRUE* sentiment at the time. I SALUTE YOU! However, I believe my
old professor (psychology 101) might take exception to that. I tend
to believe he would more than likely classify you as (in direct
English) a Hilter-like-wannabe. . .[g] Of course, you have to take
into consideration that Professor Freedmen, pulled a Dr. Jack, and
blew his own brains out about 10 years ago! Another predominate trait
that FidoNet SysOps seem to have acquired over the last eight or ten
years is the *power for me* temperament. For some reason there seems
to be a growing number of SysOps that feel compelled to attain as much
power, or influence (ability to intimidate) as possible over their
users. Why? I have no idea, except to say what everyone else who has
studied this formidable swing in human nature says, that it is a "sign
of our times." Of course, this is probably of bunch of horse hockey!
Whatever the reason, it is not exclusive of SysOps alone within the
FidoNet community. We have an abundance of Network Coordinators with
the same, or like, philosophy, not to leave out a number of Regional
Coordinators who have become "Hooked On Power", and they think it
"Works For Them." Consequently we have a network that will become a
little known fleck in history, if "we" do not recognize the problems,
and do something about it.
Brothers, I beseech you to take a very close look at FidoNet as it is
today. Then try to visualize it five or ten years from now. Look
into the prospective for FidoNet, if present conditions prevail, and
try to visualize it with all these problems confronted, and corrected.
I'll tell you right now, I can see a FidoNet similar to the early
years, when Tom Jennings and a few more (caring and dedicated) people
produced a telecommunications system unequaled from its conception to
the present day. The Internet you say is bigger and has many more
features. Maybe! Just keep in mind the *GRANDFATHER* who led the
way for The Internet, and is still *BIGGER* than that inception.
FidoNet was the trailblazer for all the nets which subsequently
evolved from it, and with the dedication of those who care about it.
It will be again! We can not allow the "me first" people who care for
nothing but their own personal gratification to prevail. We can not
tolerate those who would bring nothing but hopelessness within the
net, to remain. These people *must* be identified by those who care,
and be weeded out.
By now, most of you people are sick and tired of hearing (reading) me
complain about what is faulty with FidoNet. Some would even like to
*see* me get off the pot, and make some useful suggestions for the
betterment of it. So would I! I could sit hear on my duff, day in
and day out spreading my philosophy and criticisms. Chastising the
FIDONEWS 14-13 Page 12 31 Mar 1997
*C structure, the SysOps, and most of all, that piece of garbage that
is referred to as POLICY 4. I could do all that, and never add to the
prosperousness of the Net. The trouble is, *I* could do all these
things, but nothing would be gained. NOTHING at all! Nothing that
is, without *Y*O*U* making a contribution. I (we) need input of
everyone who cares one tiny bit about the future of our association.
You (the members) SysOps out there who have been sitting on your
opinions, for all these many years, and you Regional Coordinators who
*have* opinions for your regions upward movement. The Network
Coordinators, who *know* what is wrong within their individual
regions, but are to damned worried about their positions as NC to
voice those conceptions for fear of retaliation. Those users out
there who read FIDONEWS, who would like to be a part of FidoNet, but
because of the antiquated rules, procedures and the general *cut
throat* mentality that is so obviously prevalent, have been reluctant
to join. Now is the time to voice your opinions. Join in this
endeavor with those who truly care. Let your voice be heard, by those
who must *listen* if FidoNet is to have a reincarnation. Remember,
there is safety in numbers, and more importantly, a greater pool of
intellect to draw upon. With many voices, there comes many
suggestions, and with those many suggestions comes many intelligent
and significant recommendations which leads to a aggrandized
membership, and a more equable association.
If anyone out there has any hesitancy in believing that I intend to
accelerate the demise of those who have been responsible for the
shortcomings of FidoNet, let them be assured I fully intend to raise
enough hell to either cause sufficient change in the way FidoNet
operates, or find myself without a node number, again.
If there are any inhabitants out there who consider themselves *real*
FidoNet people, and would like to join in this crusade, by all means
send me some mail (FidoNet, not Internet [gag]) with your suggestions.
I am particularly interested in those who have suggestions pertaining
to a *NEW* POLICY document. Those who have any complaints about the
monitory provisos dictated by EchoMail Coordinators. Anyone who is
infuriated with the multitude of Bulletin Boards (BBS) which indulge
in the practice of charging users for access. Anyone who has ever had
(what you consider) an unfair decision rendered by your NC, or RC, or
both, let me know. Let *us* right a wrong that has been going on much
to long. Do you have any suggestions concerning the EchoMail Policies
in the different Nets you have been associated with? How about a
*REAL* EchoMail POLICY for FidoNet, itself? Any ideas on how to
better the present procedures or policies? Do you know of any person
who is a part of the *C structure of FidoNet (also including SysOps)
who have allowed his/her personal opinion of you (or someone else) to
influence a rendering of a fair and impartial decision? Have you (or
anyone you know) ever been denied a reasonable appeal process by
anyone in the position to deny it (NC, RC, SysOp, ZC, et al). These
are all questions that must be taken under consideration when
attempting to reestablish a network such as FidoNet.
I realize with all the criticism I have expressed in this wonderful
outlet (FIDONEWS - Thanks, Chris Baker) concerning FidoNet. I have
irritated the hell out of the *good-old-boy-network* who in all
likelihood will now attempt the FidoNetSqueeze. It may even work!
FIDONEWS 14-13 Page 13 31 Mar 1997
But, who cares? I've said my piece, expressed my opinions, got others
to take a closer look at what is going on. I have actually received a
few positive responses to the articles printed in FIDONEWS, shocking
isn't it? Look folks, I'm not the only one with the desire to better
this organization, there are many out there who would like to be proud
of FidoNet, again. Perhaps some of these people are worried about
what sort of retribution would be forthcoming if they were to speak
out, or maybe they are just being a little overly circumspect than is
absolutely necessary. Or perhaps their reluctance is justified in
light of what has been a trend in FidoNet, of late. Whatever the
reason, I believe this open challenge and solicitation for help, just
may instigate these people to finally stand up and have their
convictions noted.
-----------------------------------------------------------------
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)>
Date: Tue, 25 Mar 97 08:20:52 -0600
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
Subject: Fwd: Warning: Latest Win95, Win97 & NT Browser/Networking
Security
==================BEGIN FORWARDED MESSAGE==================
Received: from austin.onu.edu (austin.onu.edu [140.228.10.1]) by
monarch.papillion.ne.us (8.7.4/8.6.9) with ESMTP id BAA13578 for
<mriddle@monarch.papillion.ne.us>; Tue, 25 Mar 1997 01:37:15 -0600
(CST) >Received: from austin.onu.edu (localhost.onu.edu [127.0.0.1])
by austin.onu.edu (8.8.5/8.8.5) with SMTP id CAA35433
for <mriddle@monarch.papillion.ne.us>; Tue, 25 Mar 1997
02:34:14 -0500
Date: Tue, 25 Mar 1997 02:34:14 -0500
Errors-To: david@drw.onu.edu
Reply-To: network2d-l@austin.onu.edu
Originator: network2d-l@austin.onu.edu
Sender: network2d-l@austin.onu.edu
From: Jeff Beard <jbeard@microlaw.com>
To: mriddle@monarch.papillion.ne.us
Subject: Warning: Latest Win95, Win97 & NT Browser/Networking Security
These security bugs are really starting to bug me -- seriously! IMHO,
this one is very disturbing, as it has the very definite potential to
compromise security for an entire network.
I do apologize in advance that this message is lengthy, because it
requires some technical explanation of what SMB is, and how it relates
to the latest (and perhaps greatest) security problem. I also
included the Wired news site article (at the bottom of this message)
that explains it in plainer language.
THE SECURITY PROBLEM: If you are running either Win95, Win97, or NT,
and use either MS IE 3.xx, Netscape 3.xx, or Netscape Communicator
4.0, there is now yet another bug (a whopping SIX security bugs for IE
this month! and I think the second one for Netscape) THAT WILL SEND
OUT YOUR WINDOWS LOGIN NAME AND PASSWORD TO A REMOTE SERVER which can
FIDONEWS 14-13 Page 14 31 Mar 1997
capture it! And for most network users, their Windows login name and
password are also their network login name and password, which of
course puts the entire network at risk for break-ins. For example, a
person's Win95 login name and password is often the same for their
Novell Netware and MS Windows NT server. Cute, huh?
First, let me explain briefly what the SMB protocol is, because it is
key to the security flaw -- then the rest of the message will make
more sense. I compiled the following information from several web
sites that did a good job of describing it:
It has to do with embedding a link (e.g., an image link) in the web
page to an SMB server rather than the normal HTTP server. SMB, which
stands for Server Message Block, is a protocol for sharing files,
printers, serial ports, and communications abstractions such as named
pipes and mail slots between computers. It is a higher level protocol
which can be transported over TCP/IP, NetBEUI and IPX/SPX. If TCP/IP
or NetBEUI is in use, then the NetBIOS API is being used. If SMB is
used over TCP/IP or NetBEUI, then NetBIOS names must be used in a
number of cases. NetBIOS names are usually the name of the computer
that is running NetBIOS. (In many instances, the computer names are
referenced by the "\\" prefix to designate a different computer on the
network -- this is an important aspect of the security flaw -- read
on.)
For more info about SMB and its security problems, you can go to:
http://samba.anu.edu.au/cifs/docs/what-is-smb.html (Describes SMB)
http://www.sur.fr.net/ftp/supports/96/netbios-3.html (re: Security
Problems)
(I'm sure there are a lot of other great SMB sites too, but these were
among the first two I found using Alta-Vista when researching this.)
Okay, enough of the SMB explanations. Now that you know what SMB is,
here's how the security flaw/bug works:
In a web page, the webmaster can insert a link reference uses a
combination of the "file://" URL command followed by the "\\"
reference that Win 95, 97, and NT use to refer to and access other
servers (as I mentioned above). Then, because your browser sees this
link (e.g., an image tag) as a reference to a different server (the
SMB server), Win95, 97 & NT automatically send your Windows login name
and password to the remote server to log in (the "\\" makes it think
that the other PC is part of its network), ALL BEHIND THE SCENES, so
the user has no idea whatsoever that this is happening!!! Basically
the guy discovered this security flaw by combining different things
that were in the previous IE bug reports this month -- very clever.
The article below tells network administrators how to block this on
their firewall setup, to block access to the SMB server. It appears
that the rest of us using Win 95, 97 and NT are just out of luck for
now.
The article posted at the end of this message is from the Wired news
site, at:
FIDONEWS 14-13 Page 15 31 Mar 1997
http://www.wired.com/news/technology/story/2702.html
The web site referred to in the article is authored by the guy who
discovered the bug, and gives a lot more info about it, as well as
demonstrating the bug in real time to you.
WARNING!!! IF YOU GO TO THE FOLLOWING WEB SITE USING WIN95, 97, OR NT,
IT *WILL* MOST LIKELY CAPTURE YOUR LOGIN NAME AND PASSWORD, AND THE
SITE POSTS A TABLE SHOWING THE LAST 10 CAPTURED LOGIN NAMES, PASSWORDS
(but only shows the beginning of the password for your protection),
HOST NAME AND IP ADDRESS, SO YOU CAN SEE IF YOU ARE VULNERABLE, AND
THEN TELLS YOU TO CHANGE YOUR LOGIN AND PASSWORD ASAP TO PROTECT
YOURSELF! I used my standalone Win 3.1 laptop with no problem (hey,
right now Win 3.1 apps are more secure on the Net, IMHO -- so don't
knock it <g>). BTW, the "bug" web site mentions that "Notice that the
most common account & password I get is 'Administrator' ". So it's
capturing administrator logins and passwords as network administrators
hear about the bug and visit his site -- full access, good grief. If
any of you would like to read the full text from the site without
going there, send me an e-mail and I will send it to you, since my Win
3.1 laptop system does not support that security flaw.
The URL for the bug site, if you are curious, is (but remember my
WARNING!):
http://www.ee.washington.edu/computing/iebug/
(The following URL is okay to go to:)
http://www.wired.com/news/technology/story/2702.html
Another Windows Networking Bug Discovered by Toxic
11:56am 21.Mar.97.PST Yet another security-related browser
bug has been uncovered, the sixth to affect Microsoft Internet
Explorer this month. This latest bug, in the file sharing protocol
of both Windows 95 and Windows NT, allows someone to set up a rogue
Web site that obtains your username and Windows network password.
Windows NT users of all versions of Microsoft Internet
Explorer and many versions of Netscape are vulnerable to this attack
- which is not addressed by Microsoft's 12 March browser fix.
As with the rash of recent Internet Explorer security bugs
and holes, Aaron Spangler, the bug's discoverer, has created a
Web page to demonstrate the vulnerability.
"My bug is twofold," said Spangler, a systems administrator
at the University of Washington. "It takes advantage of two exploits.
The elegance lies in putting the two together to come up with grabbing
people's passwords. That's a pretty scary thing," he said. Spangler
has captured more than 940 passwords, many from administrator accounts
using weak passwords such as "horse" and "dog."
Spangler said both bugs have affected IE for some time. He
first tried contacting both Microsoft and Netscape on 13 March, and
created his Web page the next day. He says he received a note from
FIDONEWS 14-13 Page 16 31 Mar 1997
Microsoft saying that they were working on the bug. "But every time I
send any more email they don't respond," he says. "They're completely
ignoring me. It's frustrating."
Netscape sent an auto-generated response to his email, but
has not contacted him since, he said.
The attack relies on the file structure of the Windows
operating system, and the behavior of a browser when it encounters a
URL that begins with the "file://" scheme. When Windows sees a file:
URL, it attempts to read the specified file from the user's local hard
disk. For example, file://C:\temp\foo.html will open C:\temp\foo.html
from your local hard drive.
However, the Windows file system is designed such that
filenames that begin with a double backslash actually reside on
another machine. If you take these two factors and combine them, you
realize that the file in the example above could also be referenced as
a URL, as in file://\\bar.wired.com\temp\foo.html.
When a user attempts to access a file through this method,
his Windows machine will connect to the specified server -
bar.wired.com in the above example. The server will then attempt to
authenticate the user by asking for a username and password. Windows
will automatically send the information entered by a user when they
logged into their own Windows network, which is what most users do
when they first boot their machine. Windows will only prompt the user
for a password if the values entered at startup are not accepted by
the remote server.
Spangler's demo page contains an "<IMG>" tag that
references an image stored on his SMB server instead of his Web
server. When you load his page, your browser will attempt to load
the image. It will connect to Spangler's Windows file server, and when
requested, automatically send your username and password. You will
receive the image, and Spangler will receive your password. Everything
appears perfectly normal to the Web surfer.
Spangler says the fix is really trivial. "All [Netscape and
Microsoft] have to do is make it so their Web browser will not accept
URLs that come from an SMB server. It's a little statement that they
can put in their code," he said.
Network administrators can protect users on their network
by blocking TCP port 139 on their outgoing firewall (port 139 is the
SMB port). An outgoing firewall configured in this manner will not
allow traffic from a protected network to reach port 139 of any
machine on an outside, untrusted network, and will thus thwart this
kind of attack.
"Microsoft is checking into all bug reports and taking them
very seriously," said a Microsoft spokesperson. "If it is something
[engineers] need to change, they will do something about it."
Netscape could not be reached for comment.
______________________________________________________________
FIDONEWS 14-13 Page 17 31 Mar 1997
Good grief!!! Now we have to stand in line to report browser/OS
security flaws!
John L., I think this is a pretty good illustration of our discussion
re: increasingly serious security flaws, don't you?
Jeff
_____________________________________________
Jeffrey J. Beard, Esq.
Legal Systems Consultant
MicroLaw, Inc., Milwaukee, WI
E-mail: jbeard@microlaw.com
Web Site: http://www.microlaw.com
_____________________________________________
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 14-13 Page 18 31 Mar 1997
=================================================================
GETTING TECHNICAL
=================================================================
FSC-0054 - The CHARSET Proposal
[This is part of a continuing series of FTSC docs republished as part
of FidoNet History. It has been reformatted to 70 columns where
required.] Ed.
Document: FSC-0054
Version: 004
Date: 27-May-1991
The CHARSET Proposal
A System-Independent Way of Transferring Special Characters,
Character Sets and Style Information in FIDO Messages.
Fourth Release
Duncan McNutt
2:243/100@fidonet
Status of this document:
This is a finished specification, it is used in several FIDO
products.
This FSC suggests a protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unrestricted.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Contents:
---------
Purpose
History
Pros & Cons
The Present System
The Proposed System
Technical Details
Examples
Summary
Implementation Sample
Purpose:
--------
This document is a proposal for a FIDO standard.
This document describes a method of allowing international and other
non-standard ASCII characters to be transferred via a network and
FIDONEWS 14-13 Page 19 31 Mar 1997
interpreted by the receiving systems. It also allows for expansion to
multiple character sets and character sets that require more than one
byte storage space per character. Further the capability to include
style and font changes are part of this proposal.
This proposal is based on the ISO standard character sets. It defines
a mechanism to switch between all of the defined ISO sets. Further it
defines switches that allow style and font changes. The FSC-0054
standard also coexists with the extensions of the ISO LATIN-1
characters set as defined in FSC-0051. FSC-0054 and FSC-0054 use the
same identifier (CHRS: LATIN-1 2) to indicate the LATIN-1 character
set. FSC-0051 (draft 3 and above) defines the codes unused in LATIN-1
for additional characters. At present these are the numeric super and
subscripts as well as Polish characters.
History
-------
All in all the author is aware of 6 initial proposals for including
additional characters in FIDO messages, most of them did not get the
critical mass to achieve widespread use. Three of them actually
managed to get FSC numbers. FSC-0054 and FSC-0051 effectively merged
as of this document. FSC-0054 is backwardly compatible to FSC-0050.
Another standard that was used in Denmark is no longer in discussion.
The initial proposal was FSC-0050. It had several drawbacks, most
notably it was too limiting and it was based around a particular
hardware platform. Because of its implementation in Opus, FSC-0054
tries to recognize the messages produced by that system. There are
several incompatible "flavors" of FSC-0050 floating around, so FSC-
0054 can not always produce perfect results when translating FSC-0050
messages. Implementations that allow for FSC-0050 can use the same
code for FSC-0054 but may need to generate different kludges and will
need to be expanded a to make full use of the extra features.
A second proposal FSC-0051 had the advantage of hardware independence
but lacked (on its own) expandability as it only allows for roman
characters (ie: western languages). Because the FSC-0051 and FSC-0054
methods both contain the LATIN-1 character set as the base set for
western countries the authors agreed on a common identifier to allow
the two systems to coexist. FSC-0051 allows you to add Polish
characters to the Latin-1 character set without necessitating
compliance to FSC-0054 Level 3. FSC-0051 is mainly used in Sweden.
The system described in this document gives the maximum in capability
without breaking the FIDO message format. It allows hardware
independence and internationalization of FIDO software.
To further enhance the capabilities of FIDO beyond what is described
here a new message document format must be defined. The author
suggests this be done in connection with a type-3 format and that the
Open Document Architecture (ODA) be included as the standard for that
format. ODA is the agreed standard for commercial mail systems and is
being implemented by X.400 messaging systems. Conformance to that
standard would allow transfer between FIDO and other nets without
translation. ODA contains formatted text as well as graphics and
FIDONEWS 14-13 Page 20 31 Mar 1997
sound.
Pros and Cons:
--------------
Any form of non standard ASCII extension to the present messages
must respect the following criteria.
It should:
o be simple
o be backwards compatible
o be expandable
o be transparent
o allow for multiple levels of support
o allow for translation to the least common denominator
Earlier proposals had several problems:
1) They inserted non ASCII characters in the PRESENT stream of
messages.
2) They did not allow for an easy to read "standard ASCII" represen-
tation on areas that do not support their special encoding
scheme.
3) They increased the size of messages by a larger amount than is
necessary.
4) They were hardware dependant.
5) The implementation sample were too slow to be effective (a minor
point).
6) They limited the possibilities.
They only allowed for a limited amount of graphic or other
special purpose characters. They did not allow for character
sets that require storage space that are larger than one byte per
character. They were not expandable.
The advantages of the system proposed here are:
It does not have any of the failings of the prior systems (points 1-
5).
1) It does not insert any non ASCII characters in the present
stream of messages.
2) It allows for an easy to read standard ASCII representation.
3) It does not increase message size. It only includes the charset
kludge in messages that use non-ascii characters (e.g.: Kanji).
4) The presented algorithm is efficient.
5) The presented algorithm is efficient.
FIDONEWS 14-13 Page 21 31 Mar 1997
6) It support ALL international characters as well as graphic and
other special characters. It allows for character sets that
require storage space that is greater than one byte per
character. It allows for future expansion.
7) It allows for a simple method of converting non-standard
characters to standard ASCII in present systems.
8) It allows for character set coherence in message areas without
double processing.
9) It allows multiple levels of compliance.
10) It concerns itself with gateway filtering of messages.
11) The implementation allows non "charset kludge" aware programs
to display and edit messages.
12) It concerns itself with network representation as well as
local storage.
The present system:
-------------------
The present system "normally" only uses standard ASCII, unless an
echomail conference moderator explicitly allows non ASCII characters.
If a user does not conform to this and writes non standard ASCII in
a message, then other users with different systems get garbage on
their screens. This can be (and in some areas is) a major problem.
At present there is no way to display non Roman characters in FIDO
messages.
The proposed system:
--------------------
The proposed system will be able to help with messages that do NOT
have the CHARSET kludge in them on an area by area basis. However
manual intervention by the user will allow it to translate the alien
codes to the local ASCII extensions. It will also allow editors to
more easily make standard ASCII representations of extended character
sets. Which hopefully will make more users conform to standard ASCII.
For messages with the charset kludge the method described below
allows using extended character sets. There are multiple levels of
support:
Level 0: STANDARD message (no charset kludge). This method adds an
option to convert non standard ASCII to ASCII. Level 0 is
straight forward: don't change anything, except remapping non
standard ASCII to ASCII.
This should be the initial default for any CHARSET message
writer.
Level 1: INTERNATIONALIZATION, accents and other language specific
FIDONEWS 14-13 Page 22 31 Mar 1997
characters are supported. This is needed for echomail areas
that go through gateways to other systems that have a limited
character set. Level 1 can be supported by ALL types of
computers! It translates the standard US ASCII codes to the
foreign ISO codes and back.
Most software only needs to READ this type of message. This
is easily done with the sample implementation that is
available via SDS. Most software should directly support
level 2.
Level 2: Support for Level 1 plus EXTENDED CHARACTERS, included are
graphic characters and special characters from other
character sets such as Greek (for mathematical discussions
for example). This is intended to allow the different
personal computer, workstation, mini and mainframe users to
converse in text mode.
The default for level 2 messages should be the LATIN-1
character set. It is still compatible with the present
stream of messages.
This is the most common level of support for most software.
It is also what the sample implementation concerns itself
with most.
Level 3: Support for MULTIPLE CHARACTER SETS. This requires a greater
effort in implementation. Level 3 is (of course) not
backwards compatible.
It is easiest to support level 3 if you use a pixel based
display, it is probably not worth implementing on a text only
display. For example: if you have an X-Windows, Microsoft
Windows, Macintosh or similar display then you should have no
trouble implementing level 3.
Level 4: Support for 16 BIT CHARACTER SETS. Software authors
that support products that are intended for use in Asia
should concern themselves with this specification.
The implementation algorithm which has been developed is a pop-in
module that allows present message editor/display programs to offer
Level 2 support for the 5 most popular systems (ASCII, IBM, APPLE, ISO
Latin-1, VT100). The Atari now uses the IBM character set, the Amiga
and the VT200 displays use the ISO Latin-1 (ISO 8859-1) character set.
This implementation is also usable as a filter for fast translation of
messages in gateway software or for a packet translator. See the
notes at the end of this document for further details.
Levels 1 & 2:
Levels 1 and 2 are based on a remapping system. The following must
be supported:
o Level 1: remapping of non standard ASCII foreign characters,
remaps characters that are less than decimal 128.
FIDONEWS 14-13 Page 23 31 Mar 1997
o Level 2: additional remapping of special characters and
graphic characters, remaps characters over decimal 127
(i.e.: characters with the most significant bit set).
o [optional] a style mechanism (bold, underline...)
o [optional] font switching (times, helvetica...)
Characters below decimal 32 are reserved for special use (e.g.: the
SOH character is used for message kludges).
Note: Basically a lot of international message areas contain a certain
amount of messages with international characters. These characters
have the same codes on all systems, they are most likely known to you
through your printer manual, VT100 foreign symbols, or as IBM
codepages. The only reason these codes are not displayed correctly
is that your message reader can not know which of these character
sets is used. Levels 1 and 2 will mark the message with an ID that
will let your message reader change the environment in such a way that
the characters are displayed correctly.
The style mechanism and the font switching are fully transparent and
backwards compatible. Style changes are easy to support, even VT100
and Hercules (on IBM-PCs) displays support underline and boldfaced
characters.
Remapping of foreign codes may take one of two forms selected by the
user:
1) remap to character set supported by this system
2) remap to ASCII
Level 1 remaps 98% on all systems, Level 2 remaps with a "best
match" algorithm. It may be that results are not perfect but they
should be recognizable. See the Technical Description below for some
examples.
Levels 3 & 4:
Levels 3 and 4 require additional support that is non trivial.
However, it is not as complicated as it might seem at first. The
following must be supported:
o a character set switching mechanism,
o multiple character sets (Roman, Greek, Cyrillic...),
o character set remapping (fairly simple),
o [optional] transliteration (not simple),
Transliteration (converting words and symbols to another representa-
tion or language) is an optional feature that is supported by some
operating systems (OS/2 and Macintosh as well as some UNIX systems).
Transliteration is not really part of this proposed standard but is
mentioned to bring the technical possibility to mind. If your
operating system supports it then transliteration is usually just a
simple function call, if it doesn't then forget it.
Levels 5 & 6:
FIDONEWS 14-13 Page 24 31 Mar 1997
Do not exist and are not (presently) proposed. I was thinking about
B&W bitmaps for level 5 and color graphics for level 6, however that
is not suitable for Fido messages until ISDN becomes the standard
medium of transport. The physical (not logical) limit of 25000 bps
on regular telephone systems is just not fast enough to allow the
cost effective transfer of such large data amounts for a privately
operating individual. Even supposing a 10 to 1 compression of
graphics, would not be nearly enough (color pictures could still
easily be larger than 2 megabytes).
Technical Description
---------------------
This description gives a complete specification of levels 0 through 4.
If you have needs that go beyond the specification of levels 3 and 4
as they are put forward here then please write the author.
As mentioned before the proposed method for levels 0 through 2 relies
on remapping. Remapping is fairly straight forward on almost all
hardware plat- forms. It is easiest on graphically oriented systems
such as the UNIX X-Windows, Apple machines, Commodore Amiga, Atari ST
and IBM Presentation Manager or Windows systems. But even on text
only displays such as IBM DOS, VT100 and Commodore 64 machines the
most used characters are fairly easily available. Helpful in this
endeavor is that the foreign characters and additional special
characters are often the same on different hardware platforms, even if
they do not have the same ordinal value. Examples are the ISO
characters such as the English pound symbol and other common symbols
such as the international quotes ("<<" and ">>") or the Yen symbol.
The proposed remapper remaps non standard ASCII characters to the
character set options of the present system. Remapping may be one
character to one character, one character to two characters or one
character to multiple characters. The latter requires extra
implementation effort.
Example:
The uppercase "A" with the accent grave "`" above it, will remap on
all systems that support at least the ISO foreign characters or
similar character sets. It will remap to the uppercase "A" in
standard ASCII. The user could be allowed the option to view an
approximation of the original by displaying the "A" followed by the
"`", but this choice is left to the implementor.
The following two kludges are proposed (<charset_kludge> and <char-
set_change>). The kludge syntax is described in BNF below, comments
are in curly brackets, terminal symbols are in double quotes.
Case is important.
<charset_kludge> ::= "^aCHARSET:" <charset_param>
| "^aCHRS:" <charset_param>
FSC-0054 only writes the CHRS kludge, but for backwards
compatibility with older methods allows CHARSET as a valid kludge.
FIDONEWS 14-13 Page 25 31 Mar 1997
Note: up to the end of the charset kludge, all characters must be
standard ASCII. Keywords are in English.
<charset_param> ::= <level_1_opt> "1" | <level_2_opt> "2" |
<level_3_opt> "3" | <level_4_opt> "4"
<level_1_opt> ::= "DUTCH" | "FINNISH" | "FRENCH"
| "CANADIAN" | "GERMAN" | "ITALIAN"
| "NORWEG" | "PORTU" | "SPANISH"
| "SWEDISH" | "SWISS" | "UK"
Note: <level_1_opt> represents the 12 different ISO international
replacement characters. An 8 character limit applies, more charac-
ters may be used by the kludge, but only the above must match.
<level_2_opt> ::= "LATIN-1"
| "ASCII" | "IBMPC" | "MAC" | "VT100"
<level_2_opt> strings may not exceed 8 characters in length.
The Amiga and the VT200, etc. use LATIN-1 extended characters. The
LATIN-1 kludge is the same as in FSC-0051. The LATIN-1 kludge is used
for the transport medium in the Network. The others are primarily for
local storage.
Note: the other level 2 options can be useful in translating incoming
messages as well. Example: an IBM system hosts Echomail areas that
concern themselves with Amiga and Macintosh computers, even though the
messages do not have a kludge the local system could translate them
using FSC-0054 to make the extended codes of these machines readable
to his local machine. VT100 is included for local translation of PC
graphics for non-PC based clients. It should not appear on the
network.
<level_3_opt> ::= "Latin-1" | "Latin-2" | "Latin-3" | "Latin-4"
| "Latin-5" | "Arabic" | "Cyrillic" | "Greek"
| "Hebrew" | "Katakana
Includes international character sets that can be displayed using not
more than 224 (=256-32) characters, this consists of about 25 language
sets. The above are the most common. If you are writing a product
that requires one of the others please contact the me.
Latin-1 is included because in level 3 you can switch character sets,
in other words you can switch languages. This is often the case in
foreign languages, especially in technical discussions. In Japanese
for instance it would not be unusual to see characters from 4
different character sets.
<level_4_opt> ::= " | "Hanzi" | "Kanji" | "Korean" | "UNICODE"
Hanzi is also known as Chinese, Kanji as Japanese. Level 4 Options
are
16 bit characters sets. This does not mean that messages are twice as
large. In Japanese for example most words are represented with
FIDONEWS 14-13 Page 26 31 Mar 1997
Katakana (8-bit) with the occasional Kanji character (16-bit) thrown
in.
For your reference, the ISO character sets are defined in the
standards document ISO 8859. Further Arabic is 8859-6, Cyrillic is
8859-5, Greek is 8859-7, Hebrew is 8859-8, Latin-5 is 8859-9, Latin-4
is 8859-4, Latin-3 is 8859-3, Latin-2 is 8859-2, Latin-1 is 8859-1,
Katakana is JISX0201.1776-0. For the level 4 options below Hanzi is
GB2312.1980-0, Kanji is JISX0208.1983-0, Korean is KSC5601.1987-0.
Unicode is not yet an international standard, it is included for
future compatibility. Your system software will support it if it
passes ISO committee boards.
When you implement foreign character sets be sure you conform to the
standards! Several vendors have taken it upon themselves to define
their own standards, partially this was done because no firm standards
had been set at that date. Most vendors are correcting their
character mappings to conform (e.g.: see Microsoft's conversion to
Latin-1 in Windows away from the IBM-PC character set). I do not have
all the documents in machine readable form, if you want to get
references I suggest you go to your local library. Don't wait until
the last minute though as it is likely that your librarian will need
to order some of the documents.
Note: <level_3_opt> and <level_4_opt> strings "imply" additional
changes. Example the Arabic and Hebrew languages are written from
right to left. Some character sets may be the same but character
ordering is different. Character widths may vary to a large extent
(including zero width characters).
<charset_change>::= "^aCHRC:" <switch>
Note: use of the charset change kludge REQUIRES the charset kludge at
the beginning of the message. Also message readers supporting this
kludge do not display a new-line if this kludge is encountered.
<switch> ::= <level_2_switch> | <level_3_switch>
<level_4_switch>
<level_2_switch>::= "D" {default, see below for explanation}
| "F " <font_change> | "S " <style_change>
The string "^aCHRC:D" is a resetting mechanism that turns on the
default settings of the message displayer/editor, whatever they may
be. This string must be recognized by software that evaluates the
style and font change switch.
The It is assumed that the user is seeing some font that has a
reasonable size suitable for his viewing needs. Most printed texts
are displayed in a serif 12 point, proportional font with no added
style. Most default settings come close to this representation. On
text only displays non-proportional fonts are the norm, however as
no rule for the ordering of the displayed characters can be made, an
assumption of a non homogeneous character display can be made. In
other words, one should not assume that characters are displayed in
a fixed way, that's why we are have the <font_descrip> below.
FIDONEWS 14-13 Page 27 31 Mar 1997
<level_3_switch>::= <level_2_switch> | "L " <level_3_opt>
| "C " <set_change>
The character set change option can't be use in level 2 because of
unsatisfactory display results on text only display hardware. If you
want to change the character set (not just font or style) then you
must support level 3.
<level_4_switch>::= <level_2_switch> | <level_3_switch>
| "L " <level_4_opt>
<font_change> ::= <font_descrip> " " <font_family>
<font_family> ::= NULL | {any number of fonts family names,
examples: Times, Bookman or Helvetica}
The font families can be just about any text string, of course if you
have an esoteric font then it is unlikely that the recipient has it as
well (especially in echomail). It is suggested that the author
recommends that the user use commonly available fonts. Even if a
particular font is not available to the reader the font descriptor
will approximate the display of the original message.
<font_descrip> ::= <font_descrip1>
| <font_descrip1> <font_descrip1>
<font_descrip1> ::= "S" {serif} | "N" {sans-serif}
| "P" {proportional} | "O" {other}
Note: font_family can be null, but font_descriptor must be there.
<style_change> ::= <style_change> <style_change>
| "b" {Bold} | "i" {Italic}
| "u" {Underline} | "C" {All caps}
| "U" {double underline}
| "n" {Narrow also known as Condensed}
| "w" {Wide also known as Extended}
| "s" {Subscript} | "S" {Superscript}
| "O" {Outline} | "h" {Shadow}
Note: you may approximate different styles. For example if you can
only do underline then you can approximate double underline with
underline. Please do not approximate "All caps"! All caps shows the
All uppercase letters as large uppercase letters and all lower case
letters as small uppercase letters. If you simply convert all letters
to uppercase you will misrepresent the intended style.
Examples:
---------
Double quoted characters are message text.
1) "^aCHRS: GERMAN 1"
Means text contains German characters, but still uses 7 bit
character representation.
FIDONEWS 14-13 Page 28 31 Mar 1997
2) "^aCHRS: IBMPC 2"
Means the text contains IBM PC graphic or extended characters.
This would normally only appear in locally held messages.
3) "^aCHRS: LATIN-1 2"
"^aCHRC:u"
"Hi Joe,"
"^aCHRC:D"
Means the text contains LATIN-1 extended characters (not
displayed in this example) and that "Hi Joe," is underlined.
Also the "^aCHRC:" kludges do not result in new lines on
message readers that support these kludges.
The "CHRS: LATIN-1 2" is compatible with FSC-0051.
4) "^aCHRS: ASCII 2"
Means the text is standard ASCII, but hidden style and/or font
changes are contained therein.
5) "^aCHRS: Roman 3"
Means that a level three editor has created this text. An
editor (with the roman character set, that's ours by the way)
that does not understand level 3 will only be able to read
this text if the string "^aCHRC:L xxx" (with xxx being
something other than Roman) is not contained in the text.
Actually this should not happen as the Roman font is the
default and the above kludge implies that another language
character set is used somewhere in the text.
Summary:
--------
Level 0:
This is the initial default mode for CHARSET software.
No additional work required. However an implementor of CHARSET
should include the following feature: remap non standard ASCII to
ASCII. This is Level 2 to ASCII remapping and is trivial to do.
No kludge is required. No special handling is required. The
messages are just as they always are, with a little less
non standard ASCII.
Level 1:
This is similar to the optional Level 0 remapping but allows the
use of foreign characters which are found in the ISO character
sets. Unfortunately the ISO foreign character sets are not
complete. I decided to restrict the Level 1 to this subset to
assure that compatibility with virtually all hardware is guaranteed.
The "^aCHRS: cccccccc 1" kludge is required. One of two things can
happen:
(a) the message is entirely in ASCII (no kludge),
everybody can read it.
(b) the message contains ISO codes,
- the user has an older reader and does not have these
FIDONEWS 14-13 Page 29 31 Mar 1997
codes as his default codes, he gets a few garbage
characters (this is often the case at present).
- the user has an older reader and has these codes as his
default, he sees the message properly displayed (e.g.:
user has an IBM is reading a Swedish area, as he has the
Swedish codepage loaded; he will see things properly).
- the user has an editor that supports the charset
kludge, he sees the message properly displayed.
Level 2:
Remaps characters above decimal 127 up to decimal 255 to the "best
match" character(s) available on the present system. On graphic
based systems the use of a different font (e.g.: an IBM-PC font
on an Amiga) would give perfect display results. For keyboard
entry the remapper is required to convert the local codes to the
codes required by the intended target.
Example: An Amiga user is reading an IBM echomail area. The IBM
specific character set is allowed on this echo area. For
best results a IBM character set font might be used to
display messages in the area. Perhaps the software just
remaps the IBM characters to the appropriate Amiga
characters. When the Amiga user enters text he may (a)
enter standard ASCII, (b) enter standard ASCII with Level
1 extensions, (c) enter characters in the IBM extended
character set.
The software may optionally support font changing and style
changes. Font changes could be easiest to implement on graphically
oriented systems, text displays could change the color of text.
The "^aCHRS: xxxxx 2" kludge is required.
Level 3 & 4:
The message is probably unreadable unless you have a level 3 (or
level 4) editor. They are required for true international software
however.
Implementation Sample:
----------------------
An easy and fast way to implement such a remapper is to use a look-
up table mechanism. The implementation described here is based on
an expandable, data driven structure. The following routines
describe the READ routines.
Function Charset_Kludge_Detected (Ptr_To_Text, Level)
{This function implements the basic level 2 requirement}
If our character set then
print (Text)
If Level = 1 then
For each character in text
output( lookup_table [character] )
FIDONEWS 14-13 Page 30 31 Mar 1997
If Level = 2 then
If supported character set then
For each character in text
If Kludge then
skip it
{we are not supporting style and font changes
here}
If character > 127 then
output( lookup_table [character] )
If level = 3 then
exit with error
{we are being lazy here}
End of Function Charset_Kludge_Detected.
Function Output (character)
{this is the core of the implementation.
It is also usable in slightly modified form as the write subroutine}
define:
lookup_table =
array [0...127 x 2] of type byte
{ = array [127 elements] x [2 elements] }
{see below for exact definition}
case lookup_table [character][0] of
0...1:
{ we have a single character replacement }
{ IMPORTANT: graphic characters must have a
single character match }
print (lookup_table [character][1])
32...127:
If lookup_table [character][1] >= 32 then
{ we have a two character replacement }
{ Examples: ae, oe, <<, Pt, pi, >=, etc. }
print (lookup_table [character][0])
print (lookup_table [character][0])
Else
{ reserved for implementors use,
e.g.: more than two character replacement? }
1...31:
{ reserved for FSC use }
end of case
End of Function Output.
Lookup Table
------------
The lookup_tables are external (described below) files and have the
following format:
FIDONEWS 14-13 Page 31 31 Mar 1997
4 bytes: identification
2 bytes: module version number
2 byte: level
8 bytes: reserved for future use (should be zero)
8 bytes: from charset
8 bytes: to charset
256 bytes: lookup table
The identification is usually 0 (= FTSC set), numbers less than 65536
are reserved for FSC use. Implementation specific modules should use
a timestamp (always the same number after it has been generated once)
to mark them as non-standard modules.
Module version number starts at zero and works upwards. The first
official release is "1". The early sample implementations have
version number "0".
Level is the charset kludge level this module is intended for.
From charset, is the character set this module translates from. To
charset, is the character set this module translates to. Both are in
C format (no leading length byte and filled up with zeros).
The lookup table is a 127 element table with two bytes per element.
The following rules apply:
first byte = 0 or
first byte = 1:
second byte = 0: no output
second byte > 0: second byte is output
first byte < 32: reserved for FSC use
first byte > 31:
second byte > 31: output first & second byte
second byte < 32: implementation specific switch useable by
programmer
If the first byte is 1 in the lookup table, that is a marker to
tell you that this character does not translate to the destination
character set. A "?" should be in the second byte. Characters that
are approximated with another character do NOT have a 1 as the first
byte, they have a 0 in the first byte, or a printable character if it
is a two character approximation.
Note that you require two tables for each type of character set
supported. One to translate the alien characters to the local format
and one to translate the local characters to the alien format.
The advantage of this module system, is that additional "modules" can
be added easily at a later date. Example: the implementor of an
Atari message editor has the following lookup tables: ASCII (requi-
red), IBMPC, MAC and LATIN-1. The user wants to take part in a UNIX
echomail that allows VT100 codes, so he gets himself the required
tables and binds them into the lookup table file. The editor will
now support the additional translations as it knows its capabilities
by looking up the level and the kludge identifier in the lookup table
file. No code changing was needed.
FIDONEWS 14-13 Page 32 31 Mar 1997
External Mapping Files
----------------------
The lookup tables above are held in external files (READMAPS.DAT and
WRITMAPS.DAT). These files have the following format:
1 byte: machine architecture identifier
3 bytes: filler (should be zero)
8 bytes: charset this mapping file is for.
Lookup tables: described above
The machine architecture identifier can have one of three values:
0 = Sparc & 680x0
1 = 80x86 & VAX
2 = PDP-11
these values reflect the byte ordering of those machines.
The lookup tables should be ordered in the following way:
o Sort by level (lowest first)
o READMAPS.DAT:
- sort by "from set"
- each from can have 2 tables, the first is to the
local characterset, the second is to ASCII
o WRITEMAPS.DAT:
- sort by "to set"
This allows fast binary tree searches to be done.
The appropriate sort code (in C) is given below:
int compare_read(r1, r2)
CHARREC *r1,
*r2;
{
/* sort by level first */
if (r1->level < r2->level)
return(-1);
if (r1->level > r2->level)
return(1);
/* ASCII comes after local set (this is only for the read_maps) */
if(strncmp(r1->from_set, r2->from_set, 8) == 0)
{
if (strcmp(r1->to_set, "ASCII") == 0)
return (1);
if (strcmp(r2->to_set, "ASCII") == 0)
return(-1);
}
/* else sort alpha */
return(strncmp(r1->from_set, r2->from_set, 8));
}
int compare_write(r1, r2)
CHARREC *r1,
*r2;
{
/* sort by level first */
if (r1->level < r2->level)
FIDONEWS 14-13 Page 33 31 Mar 1997
return(-1);
if (r1->level > r2->level)
return(1);
/* if from_set is the same sort the to_set */ if(strncmp(r1-
>from_set, r2->from_set, 8) == 0)
return (strncmp(r1->to_set, r2->to_set, 8));
/* else sort alpha */
return(strncmp(r1->from_set, r2->from_set, 8));
}
Together with this document there should be a sample implementation
containing:
A complete set of level 1 maps.
A complete set of level 2 maps (IBM, MAC, VT100 and LATIN-1).
IBM, Mac and ASCII sample messages containing level 2 kludges, a
German language level 1 message, a sample message reader and a
sample message writer. A module checker and a mapping file creator.
If you want the latest version (or the sample implementation is not
included with this document) you can file request at 2:243/100 with
the magic name CHARSET , 1:1/20 has a copy as well. The file is also
distributed via SDS.
-30-
-----------------------------------------------------------------
FIDONEWS 14-13 Page 34 31 Mar 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 087
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-059|Nodelist-066|Nodelist-073|Nodelist-080|Nodelist-087|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 9405| 9405 0 | 9107 -298 | 9088 -19 | 9088 0 |33|
| 2 | 16116|16083 -33 |15996 -87 |15956 -40 |15923 -33 |58|
| 3 | 807| 800 -7 | 800 0 | 800 0 | 800 0 | 3|
| 4 | 541| 545 4 | 547 2 | 548 1 | 548 0 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1088| 1088 0 | 1088 0 | 1088 0 | 1090 2 | 4|
+----+------+------------+------------+------------+------------+--+
| 28044|28008 -36 |27625 -383 |27567 -58 |27536 -31 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-13 Page 35 31 Mar 1997
=================================================================
COMIX IN ASCII
=================================================================
Chris,
I've been
|~-_
||||~-_
| | ~-------|
|::::::_-------|:.
|:::_-~ ::
|_-~ __::__
| __ |
| __ |
|____|
over my stash of original ASCII artwork, trying to decide what piece
to send you next, but I just haven't been able to make up my mind. Oh
well. Maybe next week.
-Dave
(For the monitor-impaired, and the pun-impaired, it's an Erlenmeyer
flask (ahem) pouring something into a beaker.)
-30-
-----------------------------------------------------------------
FIDONEWS 14-13 Page 36 31 Mar 1997
=================================================================
ADVERTISE YOUR FREE SERVICE/EVENT
=================================================================
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Sun Mar 23 19:25:45 1997
From: Alex Grasic @ 1:2424/109
To: Sysop @ 1:18/14
Date: 22 Mar 97 13:09:00
Subj: Important
This message is going out to all present and former Nanet
nodes. Even though I am not directly associated with Nanet and the
owners of Nanet, I am offering to hub any system who wishes to
receive Nanet mail again. I realize that you may not wish to call
long distance for mail, but you can telnet to Westonia BBS to
download your QWK packets. You can telnet to Westonia Computer
Systems of Canada at WESTONIA.COM. I would like to see this network
resurect itself and get the kind of mail it used to have. If there
are any nodes that are not a member of Fidonet that you know of,
please forward this message to them, if you do not wish to contact
Westonia directly, just netmail me any relevant info to sign you up.
I will be glad to relay information to them. Remember, the network
can only survive with your support. Thanks!!
-30-
-----------------------------------------------------------------
FIDONEWS 14-13 Page 37 31 Mar 1997
=================================================================
NOTICES
=================================================================
Future History
17 May 1997
Independence Day, Norway.
6 Jun 1997
National Commemoration Day, Sweden.
11 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
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 14-13 Page 38 31 Mar 1997
--- Following message extracted from MEADOW @ 1:18/14 ---
By Christopher Baker on Tue Mar 25 20:39:28 1997
From: Trev Roydhouse
To: All
Date: 24 Mar 97 01:14
Subj: FTP by mail
Thanks to Ronald Bruintjes in the Netherlands, an FTP by mail OpusInfo
facility is now available for the current Opus 1.73 files which are
available at http://www.suburbia.com.au/~trev.
Usage: send mail to ftpmail@deimos.nl. In the body of the message
include the command GET [filename]. Do not include paths nor
wildcards. If the file is available, it will be sent back to you via
email in uuencoded form.
A magic filename is available for OPUSINFO. This will send you the
Opus 1.79 feature list. When Opus 1.79 is released, OPUS179 will send
you the Opus 1.79 release files.
TREV.
Origin: Sentry -- Sydney, New South Wales, Australia (3:711/401.0)
-30-
-----------------------------------------------------------------
FIDONEWS 14-13 Page 39 31 Mar 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
[This is a repost of last week's version of the Software List. Peter
is still catching up on real life.] Ed.
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Awk! I didn't realize how far behind I've gotten. Events in my
personal life have conspired to keep me away from the keyboard
during my recreational time. Heck, I'm late for a meeting right
this very second.
Phased out this week: "Amiga" and "Atari ST/TT" Sections.
-=- Snip -=-
Submission form for the Latest Greatest Software Versions column
OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :
Please include a sentence describing what the package does.
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.1 O S Peter Karlsson 2:206/221 ANNOUNCE
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
CheckPnt 1.0 O G Michiel 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
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
FIDONEWS 14-13 Page 40 31 Mar 1997
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.20 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
MakePl 1.9 N G Michiel 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.63a O S Peter Hampf 2:241/1090 OT
PcMerge 2.7 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
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
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:
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
FIDONEWS 14-13 Page 41 31 Mar 1997
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
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.10 P S Mats Wallin 2:201/329 FDAPXW
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
Maximus 3.01 B P Tech 1:249/106 MAXN
Msged/NT 4.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 ...tx7.9 M G Pablo Saratxaga 2:293/2219 IFMAILTX
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
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
FIDONEWS 14-13 Page 42 31 Mar 1997
Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY
Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, F-Fossil, O-Other. Note: Multifunction will
be listed by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems Other Utilities Other Utilities
-------------- Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
PKPak 3.61 GMM 1.21 TGroup 1.13
PKZip 1.10 GROUP 2.23 TIRES 3.11
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FIDONEWS 14-13 Page 43 31 Mar 1997
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-13 Page 44 31 Mar 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-13 Page 45 31 Mar 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 14: http://www.netins.net/showcase/fidonet/
Region 15: http://www.smrtsys.com/region15/
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://ccove.n-link.com/ [not answering]
============
Zone 2: http://www.z2.fidonet.org
ZEC2: http://fidoftp.paralex.co.uk/zec.htm [not answering]
Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm
Region 24: http://www.swb.de/personal/flop/gatebau.html (in German)
Region 25:
http://members.aol.com/Net254/
Region 27: http://telematique.org/fidofr.shtml (in French)
Region 29: http://www.rtfm.be/fidonet/ (in French)
Region 30: http://www.fidonet.ch (in Swiss)
FIDONEWS 14-13 Page 46 31 Mar 1997
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 48: http://www.fidonet.org.pl
============
Zone 3: http://www.z3.fidonet.org
============
Zone 4: (not yet listed)
============
Zone 5: (not yet listed)
============
Zone 6: http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-13 Page 47 31 Mar 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, cbaker84@digital.net
cbaker84@aol.com
cbaker84@msn.com
(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-13 Page 48 31 Mar 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:
jbarchuk@worldnet.att.net
with a Subject line of: subscribe fnews-edist
and no message in the message body. To remove your name from the email
distribution use a Subject line of: unsubscribe fnews-edist with no
message to the same address above.
*=*=*
You can read the current FidoNews Issue in HTML format at:
http://www.geocities.com/Athens/6894/
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.
=*=*=*=
The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:
http://ddi.digital.net/~cbaker84/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
A PGP generated public-key is available for the FidoNews Editor from
FIDONEWS 14-13 Page 49 31 Mar 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-
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink