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

3320 lines
129 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
F I D O N E W S -- Volume 14, Number 18 5 May 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. |
+----------------------------------------------------------------------+
ANOTHER YEAR, ANOTHER NO IC?
Table of Contents
1. EDITORIAL ................................................ 1
How about that ZEC Election process? ..................... 1
2. LETTERS TO THE EDITOR .................................... 2
NEW Opus Version 1.79 Available! ......................... 2
Response to BBS Week notice .............................. 2
3. ARTICLES ................................................. 4
New Beanie Babies Echo! .................................. 4
NOT the death of a friend! ............................... 4
4. COLUMNS .................................................. 6
Lock and Load: Guerilla Marketing for BBSes ............. 6
5. GETTING TECHNICAL ........................................ 8
FSC-0064 - InterDomain Message Identification ............ 8
FSC-0065 - Type 3 ASCII .................................. 12
FSC-0066 - Type 3 Binary ................................. 22
FSC-0067 - Proposal for Sensible New Kludge Lines ........ 24
6. WE GET EMAIL ............................................. 28
More security holes in Internet Explorer? ................ 28
7. NET HUMOR ................................................ 32
The Microsoft Restaurant ................................. 32
8. COMIX IN ASCII ........................................... 34
Animated ASCII? .......................................... 34
9. NOTICES .................................................. 45
Future History ........................................... 45
Action Alert for Privacy on the Internet ................. 46
And more!
FIDONEWS 14-18 Page 1 5 May 1997
=================================================================
EDITORIAL
=================================================================
Lots of fun and interesting stuff in today's Issue although I did not
receive the usual Z2 stats file this week from ZC2.
For those of you who still run BBSes, Opus has FINALLY released a new
version this week. Opus 1.79 is making the rounds and has also been
hatched into SDSOPUS file echo. For those of you who've never heard of
it, Opus was the first multi-function BBS/Mailer developed after Fido.
There is an announcement further down the page with sources.
Still no IC. [sigh]
C.B.
-----------------------------------------------------------------
FIDONEWS 14-18 Page 2 5 May 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
Sender: trev@guard.bbs.org
Date: Fri, 02 May 1997 01:10:38 +1000
From: Trev Roydhouse <trev@ibm.net>
Organization: Worldwide Opus Consortium
To: Bill Swisher <bswisher@micronet.net>,
Christopher Baker <cbaker84@digital.net>,
Eelco de Graaff <EELCO@humako.nl>,
Jim Barchuk <jbarchuk@worldnet.att.net>,
Joe Rowehl <jhrowehl@juno.com>,
Mike Burgett <mburgett@cmnsens.zoom.com>,
Peter Bruneau <pbruneau@ican.net>,
Rob Lerman <rlerman@treknet.gigo.com>,
Roger Dunk <roger@arcadiatech.com.au>, Ron Stalzer
<ron@futureone.com>, Ronald Bruintjes
<ronald.bruintjes@deimos.nl>,
Sue Blake <sue@welearn.com.au>
Subject: Opus v1.79
Last night, May 1st, a brick was hurled through the window with the
following scrawled note attached:
"On behalf of the Opus Covert Action Committee and the Not Ready for
Mainframe Players, Sydney and Elsewhere ...
OEXE179.ZIP Opus v1.79 Main executables
OUTIL179.ZIP Opus v1.79 Utility files
OMAKE179.ZIP Opus v1.79 Installation kit
OSOM179.ZIP Opus v1.79 Sysop Operations Manual
OTEC179.ZIP Opus v1.79 Technical Reference Manual
File requestable from 3:3/113 aka 3:711/401 and 1:1/113.
Available on the WWW at http://www.suburbia.com.au/~trev
Anonymous FTP at ftp://ftp.fido.net/pub/bbs/ibmpc/opus
FTP by mail by sending email to opsu179@deimos.nl
Guido & Nunzio."
Cheers, TREV.
-30-
-----------------------------------------------------------------
From: newsbob@kwhn.com
To: -david.chord@cobra.galaxy.gen.nz, cbaker84@digital.net
Date: Mon, 28 Apr 1997 16:05:06 -0700
Subject: International BBS Week
FIDONEWS 14-18 Page 3 5 May 1997
Hi, David!
Saw your note in Fidonews about International BBS Week. Thought I'd
let you know I'll do what I can to help. I'm a Broadcast Journalist
by trade, author of the BBS Guide to Public Relations, a BBS user (not
a sysop), and few weeks ago I started writing a column on BBS
Marketing for Fidonews.
I can lend my expertise to anyone who wishes it, but I have no money
to spend (a wife and three kids pretty well take care of that). I'm
drawing up a draft news release that Sysops can adapt for their own
use. I should have it done by Wednesday (April 30).
Warmest regards,
Robert Parson
Fidonet 1:3822/1
Internet newsbob@ipa.net
-----------------------------------------------------------------
FIDONEWS 14-18 Page 4 5 May 1997
=================================================================
ARTICLES
=================================================================
New Beanie Babies Echo
by Ronnie Toth, 1:135/71
BEANIE BABIES * BEANIE BABIES * BEANIE BABIES * BEANIE BABIES *
They're here! They're there! They're everywhere!
(If you can find them.)
And now the FidoNet Beanie Baby echo, BEANIES, is here too!
If you're into BEANIE BABIES, join the fun in the new BEANIES echo.
It's all about having fun with these adorable critters, and a forum
for Private Collectors to chat, exchange ideas and stories about
them, and trade, buy and sell them. Commercial pricing and
availability is NOT permitted.
Links are available at 1:135/71 until the echo is backboned, which
we hope will be very soon.
A netmail to the above FidoNet node will link you up immediately!
Ronnie Toth
FidoNet 1:135/71
Tagname: BEANIES
-----------------------------------------------------------------
NOT the death of a friend!
by Louie Gonsalves, 1:2808/100, sysop@phosphor.datasync.com
----------------------------------------------------------------
NOT the death of a friend!
I was saddened by the news of Clay Tannacore's (1:372/4) dog's
death. However, it is my opinion that Clay let his companion of
years, Fido, to die.
You see, Fido *is* a sick little pup... but he can't get better if
we don't help him. Fido is getting old, true, and there are other
animals in town that are better looking, and bigger... but Fido is
not ready for the gas just yet.
Fido is NOT dying. He's going through a rebellious period. You
remember those, right? When you decided that enough was enough, and
rebelled against your parents, your school. Long hair, loud,
strange music.
Fido is rebelling. It is rebelling against those that for so long
FIDONEWS 14-18 Page 5 5 May 1997
have ignored him. Fido is trying to get attention, and frankly, he
needs all of it.
Fido can be nursed back to health. The first thing that must be
done is make his masters realize that his last proper training was
done in 1989... his masters must realize that no longer dogs run at
300 bits per second. His masters MUST realize that things have
changed.
Only us, the folks that have taken Fido as a friend can help our
sick dog's masters realize all that.
Netmail the masters, email them, send them letters, what have you.
The masters:
Bob Satti (Z1C)
David Nugent (FTSC Chair)
And all the RC's and NC's.
AND MOST IMPORTANTLY: ALL THE NODES.
It is time for action. Or Fido will die.
Or will it?
-----------------------------------------------------------------
FIDONEWS 14-18 Page 6 5 May 1997
=================================================================
COLUMNS
=================================================================
Lock and Load: Guerilla Marketing for BBSes
Robert Parson 1:3822/1
I've spent the last twenty years writing for a living. You'd think
I'd know by now that I shouldn't entirely trust my spell checker when
proofreading articles. But that's what I did last time. And of
course, I found three errors when it was published in Fidonews. (I
checked, and they were indeed my mistakes, not the fault of Editor
Chris Baker's). I've learned my lesson.
I know I promised we would discuss how to deal with journalists today.
But the sun is out, the temperature is fairly warm and I need to whack
the grass. Instead, we'll take our modems for a walk. Anything to
get out of mowing.
Good word of mouth is the key to growth. But in order to get good
word of mouth, you have to get the word out in the first place. Last
time, we talked about writing news releases. While that's a good
start, you can't rely on getting published or aired. You have to find
other ways to get the word out.
A prime example of this is Apple Computer. In the early to mid '80s,
they came out with the revolutionary Macintosh. But they didn't rely
on getting good press. Apple was out beating the bushes, scraping for
every possible user. Contrast this with the Amiga. Another
incredible system. They also got good reviews in the media. But it
failed, in large part, because Commodore didn't proselytize (Apple is
down, but I wouldn't count them out quite yet).
So where does this fit in with your BBS?
If you answered "Get out of the house" you win the grand prize.
Sure, you will likely get some new callers, or attract a few old ones
who haven't called in a while, by advertising your BBS on other BBS in
the area. But you are preaching to the converted.
What we're looking for is fresh blood. We're going hunting. (How
many different metaphors can I sneak into this article?)
Today, I want you to procrastinate. You can put off for another day
adding yet another door game to the BBS, or tweaking the color in the
bulletins. Grab your business cards, put on some shades and hit the
road.
Amazingly enough, there are people EVERYWHERE! Everytime you turn
around, THERE'S ANOTHER ONE! Okay, I'm being facetious here, but the
point is you are going to have to get out and find new potential
callers. And springtime is the perfect time to find them.
Your Chamber of Commerce probably publishes a monthly calendar of
FIDONEWS 14-18 Page 7 5 May 1997
events or knows where to find one. Try to get on their mailing list.
It may not be possible to be placed on the mailing list unless you are
a member, which is quite expensive. Worst case: you'll have to go
down to the Chamber offices and get one.
Right about now there are little arts and crafts shows popping up all
over the place. There are civic groups such as the Rotary and
Exchange Clubs. Kids groups such as the Boy Scouts or school
carnivals. We're getting set for the summer parade season. Later
this year, county fairs. If there is some kind of public event going
on, you have an opportunity to invite new folks to call your BBS.
Make yourself available.
Steve Prado, the Sysop of my friendly neighborhood BBS (Jackalope
Junction 1:3822/1), has visited with the local Genealogical Society to
talk about the genealogical echos he carries and how useful they would
be for people researching their ancestors.
In many cases, you can get involved in something at no cost. Civic
groups are always looking for speakers and could be an easy mark. You
may have to pop a few bucks for some events, such as a table at a
county fair or an entry in a parade (now that's something I'd like to
see: a float for a BBS. Maybe something like those flying creatures
in the Macy's parade).
If you have an annual picnic for users, invite the local media to come
around.
Now suppose you run into someone that doesn't know how to do anything
other than call their local Internet Service Provider or one of the
commercial services. Make sure you are well versed enough in Windows
Terminal to at least tell them how to log on. It probably couldn't
hurt to create a little fact sheet, or maybe even give them a disk
that has the appropriate configuration (if you're like me, you've got
disks to burn). Once they get on, then you can get them set up with
other comm programs and/or offline readers.
No. This is not easy work. But you can't expect users to come
running when they don't know you even exist.
So stop reading right now and head out the do--*
Hey! Where'd everybody go!?
Robert Parson
-----------------------------------------------------------------
FIDONEWS 14-18 Page 8 5 May 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing series of FidoNet History publishing
all of the FTSC Standards and Proposals. These docs have been
reformatted to 70 columns where required and Node and phone numbers
may be outdated.] Ed.
Document: FSC-0064
Version: 007
Date: 10-May-1992
InterDomain Message Identification, Gating,
Reply Linking and Addressing
Jamie Penner
1:153/1025
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Copyright (C) 1990, 1991, 1992 by Jamie Penner
All Rights Reserved
Originally written: Sept 3, 1990
Revised: November 12, 1990
Revised: June 23, 1991
Revised: August 26, 1991
Revised: January 22, 1992
Revised: February 4, 1992
Revised: February 12, 1992
Use of this proposal is encouraged and permitted by the author without
further notification in any software which is being written to conform
to FTSC specifications.
Suggestions and discussion are strongly encouraged. The author may
be reached at:
jamie.penner@f1025.n153.z1.fidonet
jamie.penner@f0.n24.z24.signet.admin
Echomail Basics:
All echomail passing through an interdomain echomail gateway
must have all information in the message header changed to
reflect the proper address of the domain in which the messages
are entering. The PATH and SEEN-BY lines should also reflect
FIDONEWS 14-18 Page 9 5 May 1997
these changes with only the SEEN-BY line containing any
information from the domain previous. This information shall
be the single address of the system passing the mail to the
gateway system. In addition, all gateway software should
recognize, by the message itself, whether it has EVER passed
through the gateway in the past. CRC records, SEEN-BY lines,
PATH lines and MSGID lines are not sufficient for this purpose
as most systems purge recorded logs of this info after a given
time.
InterDomain Echomail/Netmail Flags:
-----------------------------------
^ADOMORG:
usr.nme@[!][p.f.n.z.]network[.nid][[#nodelist_name][#point[x]]
^ADOMDES:
usr.nme@[!][p.f.n.z.]network[.nid][[#nodelist_name][#point[x]]
These lines would be a complete domain signature for any user
on any system in any FTN network.
The DOMORG line would be the actual origin information of the
user and system sending the information.
The DOMDES line would be the actual destination information of
the recipient user and system.
There are essentially two variations to the domain signature.
The ! immediately following the @ denotes a Type B, otherwise
defaulting to Type A.
Type A:
e.g. jamie.penner@f1025.n153.z1.fidonet
This has the complete FTN information needed for any
processor to send the message.
Type B:
e.g. jamie.penner@!signet.admin#ic.signet
The ! immediately preceeding the network signifies
that no FTN information is available but the
information after the # will give the name of the
system as denoted in the nodelist for that network.
This way, processors can be designed in a fashion that
they can look up the system name. Should this be
going to a point, the domain may be:
jamie.penner@!signet.admin#ic.signet#point
If I have two points and I want to send it to a
different point, I might use:
jamie.penner@!signet.admin#ic.signet#point2
FIDONEWS 14-18 Page 10 5 May 1997
The domain identifier in a Type B signature can be
further used for further locating a system if needed.
In both signature types, the nid (network identifier)
is optional (eg fidonet.org or signet.admin - only the
first field actually identifies the network name).
This information is completely dependant upon each
domain. For example I might send this:
rob.macare@!signet.eur.r331#maasstad.bbs
This kind of structure would get the message to the
right system. If there was two of the same system in
Region 331, I could use:
rob.macare@!signet.eur.n4601#maasstad.bbs
This format of domain signatures is provided solely for
compatibility purposes to provide software developers with a
platform on which they can structure new programming
techniques and can be used in conjunction with the other flags
as laid out in this document.
# GateOrigin: zzz:NNN/nnn.ppp@dmn (note leading space)
This line is currently inserted into all stripped down
echomail passing through interdomain gateways by GateWorks.
This allows the message overhead to be cut down by properly
replacing the origin line for users to read in the text yet,
not creating a second full originline. This line shall be
added immediately before the tearline with a single blank line
following it.
e.g. # GateOrigin: 24:24/0.0@signet
^AGATECHK: zzz.NNN.nnn.ppp [zzz.NNN.nnn.ppp] [zzz.NNN.nnn.ppp]
Any echomail passing through a particular gateway should have
this line inserted at the beginning of the message text.
Everytime the message passes through another echomail gateway,
the address would be added to the line. This way, if a
message passes back through with the same ID, it is a known
duplicate and can be vaporized.
e.g. ^AGATECHK: 24.24.0.0 8.8.7001.0
^AMSGORG: <originating-address> <originating-ID>
The MSGORG line keeps a standard original address and message
id in the message for reply, identification, dupe checking,
and origination purpose. This line would vanish and be
replaced with the necessary lines if passed through a gateway.
e.g. ^AMSGORG: 24:24/0.0@signet 0123456789abcdef
The originating ID is no different than other 16 bit IDs being
generated. It must be unique in a sense that no other
message originating from that system will have the same number
FIDONEWS 14-18 Page 11 5 May 1997
(at least within a short time span).
^AGATEWAY: <zonegate-address>
This field is inserted by the packer. The user-defined
zonegate fields give the message its destination to the
zonegate and may be routed through whatever channels to get
there.
e.g. ^AGATEWAY: 1:153/1025.0@fidonet.org
^GRPLY: <zonegate-address> <originating-address>
When replying to a message, this line would be looked up so as
to find the actual message destination and give the system its
zonegate information. If the message passes through a
gateway, the MSGORG line would be removed upon insertion of
this line.
e.g. ^AGRPLY: 1:153/1025@fidonet.org 24:24/0.0@signet
An example echomail message from 24:11/7777.0@signet across the domain
to 1:153/85.0@fidonet should read:
To: Bill Herringshaw, 1:153/85.0@fidonet
From: Jamie Penner, 1:153/1025.0@fidonet
Subject: Testing
AREA: TEST_ECHO
^AGATECHK: 24.24.0.0
^AGRPLY: 1:153/1025.0@fidonet 24:11/7777.0@signet
^ADOMORG: jamie.penner@f7777.n11.z24.signet.admin
^ADOMDES: bill.herringshaw@f85.n153.z1.fidonet.org
^APID: RA 1.01
Hi Bill, just testing out this new software
# GateOrigin: 24:11/7777.0@signet
--- GateWorks v4.00a
* Origin: Home of GateWorks!! (1:153/1025.0)
SEEN-BY: 24/0 153/1025
^APATH: 153/1025
An editor programmed to handle these fields would recognize GRPLY line
and know that the message had passed through a gateway. An echomail
reply would simply pass through the gateway. If a netmail reply was
required, this would be the reply message:
To: Jamie Penner, 24:11/7777@signet
From: Bill Herringshaw, 1:153/85.0@fidonet
Subject: Testing
^AGATEWAY: 1:153/1025.0@signet
^AGRPLY: 24:24/0.0@signet 1:153/85.0@fidonet
^ADOMORG: bill.herringshaw@f85.n153.z1.fidonet.org
^ADOMDES: jamie.penner@f7777.n11.z24.signet.admin
FIDONEWS 14-18 Page 12 5 May 1997
> Hi Bill, just testing out this new software
Got it here!
via InterMail @ 24:24/0.0@signet, 17:23:17 22 Jan 92
The mailer and/or packer would check for the GATEWAY flag and route
the message through that gateway.
Under this method of flags, all systems in all domains should have
access to the ability to reply via netmail to a system in a different
domain. In addition, by following this specification, all
interdomain echomail should be clean and troublefree. This
eliminates the need for some of the other ^A lines being used.
It is the intention that all addresses in these flags may use the 5d
addressing scheme, or either of the Type A or B domain signatures.
The software should be written to determine the type of address used
and manipulate the situation accordingly.
The following list of software may be incomplete but lists all
software currently available or under development using this spec:
GateWorks v4.00
ContactBBS
TOSSworks
FASTmail
<EOF>
-30-
-----------------------------------------------------------------
Document: FSC-0065
Version: 001
Date: 02-Aug-1992
Type 3 ASCII: A proposal
=========================
Mark Kimes
FidoNet 1:380/16
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
FIDONEWS 14-18 Page 13 5 May 1997
Introduction:
============
This document describes a type of mail packet called type 3 ASCII.
Type 3 ASCII was designed with how Fidonet Technology Networks (FTNs)
handle mail (netmail, echomail, groupmail) in mind. It was also
designed to allow new distribution methods to be introduced. For
instance, it is possible to combine the best of echomail and groupmail
methods using type 3 ASCII packets. Finally, type 3 ASCII provides
reliability, space and speed advantages over the current mail packet
type 2 (see "Type 3 ASCII vs. Type 2" section below).
Packet structure:
================
(See "Definitions" section below for the meaning of any arcane
symbols)
Type 3 ASCII packets and archived bundles will ride existing transport
services (mailers) as attached files. Type 2 mail and type 3 ASCII
mail can both be sent to a node without conflicts. Naturally, the
receiving node should be able to process type 3 ASCII mail before it
is sent.
Type 3 ASCII packets are named <fileroot><.><3KT> when sent to a
remote site. Archives containing type 3 packets are named
<fileroot><.><3?A> when sent to remote sites. How these files are
stored or named locally is not within the scope of this document.
A type 3 ASCII packet consists of a packet header, followed by a
carriage return, followed by zero or more messages, followed by a NUL.
A type 3 ASCII message consists of a message header, followed by a
carriage return, followed by zero or more characters of message text,
followed by a NUL.
Diagramatically speaking,
(Text in brackets [] indicates optional data)
Type 3 ASCII packet: header
<cr>
[messagehdr1
<cr>
[text]
NUL
messagehdr2
<cr>
[text]
NUL
...
messagehdrn
<cr>
[text]
NUL
]
NUL
FIDONEWS 14-18 Page 14 5 May 1997
Breakdown:
=========
(See "Description of Fields" section below for information on
individual fields.)
Packet header:
=============
<3ASCII><cr>
From<cr>
[To]<cr>
Creator<cr>
[Password]<cr>
[Area]<cr>
[Tag1<sp>data1<cr>]
[Tag2[<sp>data2]<cr>]
...
[Tagn[<sp>datan]<cr>]
Message header:
==============
From<cr>
[To]<cr>
[Subject]<cr>
Date<cr>
[Area]<cr>
ID<cr>
[Ref]<cr>
[Tag1<sp>data1<cr>]
[Tag2[<sp>data2]<cr>]
...
[Tagn[<sp>datan]<cr>]
Message body:
============
Free-flowing, NUL-terminated text. May be composed of any
combination of ASCII characters > 31 (from the space character,
ASCII character 32, onward) and may include <cr> as a "paragraph
terminator." Systems which display message text should wrap long
lines to suit their application.
To be in compliance with this document, implementations must be
able to forward messages with at least 131,072 (128K) characters
of text (including the terminating NUL). Network politics may
outlaw messages of lesser size, but that is beyond the scope of
this document. If a compliant implementation encounters a message
longer than the 128K limit, it may truncate the message text
before forwarding. However, since it is easy to support messages
of a length limited only by available disk space, it is encouraged
that you do so and not impose artificial restrictions. The
purpose of this limit is to guarantee a minimum size that will be
passed, _not_ to restrict implementations to the "minimum."
FIDONEWS 14-18 Page 15 5 May 1997
Line feeds (ASCII character 10) are reserved and should not
normally appear in message text. Future plans call for their use
as "escape codes." So called "soft carriage returns" (ASCII
character 141) should not be contained in transmitted message text
unless the actual character itself is desired.
Tabs (ASCII character 9) should not be used in message text as
their use often leads to unreadable messages. How many spaces
should be used at a remote site to represent them?
Description of Fields:
=====================
Note: the maximum length of any field line (excluding, of course,
message text) is 255 characters including the terminating
<cr>. In practice, a bit of restraint should be practiced to
keep fields as small as possible. The maximum length of any
header is 32767 bytes, including terminating <cr>. In
practice, this limit should never be approached.
Date:
====
YYYYMMDDhhmmss<optional time zone>
where
YYYY = year with century, as in 1991 or 2001
MM = month, as in 01 to 12
DD = day of month, as in 01 or 28
hh = hour of day, as in 00 to 23
mm = minute of hour, as in 00 to 59
ss = second of minute, as in 00 to 59
<optional time zone> = offset from GMT in 15 min. increments
(i.e. "+4" (sans quotes) for GMT + one
hour)
All numbers are represented in decimal.
Samples: 19990419143200
(April 19, 1999 at 2:32:00 pm)
19921223020303+8
(December 23, 1922 at 02:03:03 GMT + 2 hours)
The Date field is required.
From and To:
===========
The From field contains the writer's name followed by a valid FTN
network address. For the purposes of this document and current
implementations of type 3 ASCII packets, the format of a valid FTN
network address is:
Domain<#>Zone<:>Net</>Node[<.>Point]
where
FIDONEWS 14-18 Page 16 5 May 1997
Domain is a text string from 1 to 8 characters in length
containing only alphabetical [A-Za-z] and/or numerical [0-9]
characters.
Zone is a decimal number from 1 to 65533.
Net is a decimal number from 1 to 65533.
Node is a decimal number from 0 to 65533.
Point is a decimal number from 0 to 65535 (may be omitted if
0).
The FTSC or whatever body guards tech specs may change this
definition in the future as it sees fit.
The full format of a type 3 ASCII From or To field is:
[User Name<@>]Domain<#>Zone<:>Net</>Node[<.>Point]
If User Name<@> is missing, assume user name is Sysop. User Name
may be composed of any combination of ASCII characters > 31 (from
the space character, ASCII character 32, onward) excluding <@>.
If <.>point is missing, assume point 0.
The To field contains the recepient's name and address as above.
The To field is optional. If it is missing, message/packet is
broadcast mail (no definite, single recipient). In this case
there must be an area (if the To field is omitted in the packet
header, there must be an area in the packet header and all
messages must be broadcast mail for that area. If omitted in the
message header, the message or the packet must have an area and
message may be displayed as being addressed to "All@Anywhere"). A
<cr> must still be present as a "space holder." In broadcast
mail, it is permissible to give only the name of the user (without
following address) in a message header; however, the name must end
with <@> (to distinguish it from an address with no User Name).
Note this means a single broadcast mail packet can be sent to many
nodes.
The From field is required.
In the case of From and To fields in the packet header,
[user name<@>] is probably unimportant.
In the interests of saving space, domains such as "Fidonet.org"
should be replaced with just "Fidonet," as the ".org" modifier has
no meaning to an FTN site. Domains should be treated case
insensitively.
Sample: John Doe@Fidonet#1:380/16
(User "John Doe" in domain "Fidonet" zone 1 net 380
node 16, implied point 0)
Creator:
FIDONEWS 14-18 Page 17 5 May 1997
=======
Name of the product that produced the packet. This field is
required.
Password:
========
A password to use for security. This field is optional. If
omitted, a <cr> must still be present as a "space holder." How
this field is used is implementation-defined.
Subject:
=======
The subject field should contain text hinting at the subject of
the message text. It may be composed of any combination of ASCII
characters > 31 (from the space character, ASCII character 32,
onward). The subject field is optional. If omitted, a <cr> must
still be present as a "space holder."
Area:
====
Area fields consist of a string of alphanumeric characters plus
space, "-" and "_" (ASCII characters 32, 45 and 95 respectively).
Area fields are optional with the following consequences:
If the area field in a packet header is missing, the messages in
the packet will have area fields present for broadcast mail,
omitted for personal mail.
If the area field in a packet header is present, all the
messages in the packet will be broadcast mail for the area
specified in the packet header. The message area fields will
not be present.
When an area field is omitted, a <cr> must still be present as a
"space holder."
ID:
==
An ID consists of the originating address of the message plus a
serial number, in the form:
origaddr<sp>serialno
The originating address should be specified in a form that
constitutes a valid return address for the originating network.
If the originating address is enclosed in double-quotes, the
entire string between the beginning and ending double-quotes is
considered to be the orginating address. A double-quote
character within a quoted address is represented by by two
consecutive double-quote characters. The serial number may be
any eight character hexadecimal number, as long as it is unique
FIDONEWS 14-18 Page 18 5 May 1997
- no two messages from a given system may have the same serial
number within one year. The manner in which this serial number
is generated is left to the implementor.
Notes: The "old" format of
Zone<:>Net</>Node[<.>Point][<@>Domain]
for FTN addresses is allowed in this field.
The address portion of the ID may be omitted if it is
exactly the same as the From address (less User
Name<@>). In this case, the ID field should begin with
a space followed immediately by the serial number.
In the case of foreign network addresses, this address
gives you the "true" origin, and the From address gives
you the gateway at which the message entered FTN
territory. This allows you to gate replies to
"foreign" sites.
Samples: some.other.net.addr ABCDEF12
12345ABC
(Assume From field of second sample contained
"Joe Blow@Fidonet#1:380/16",so complete constructed ID would
be Fidonet#1:380/16 12345ABC
Note address would be copied exactly from the From field.)
The ID field is required.
Ref:
===
A Ref consists of the ID of the original message to which this
message refers (usually as a reply).
Sample: Fidonet#1:380/16 12345ABC
(would reference the second ID sample above)
The reference field is optional. If omitted, a <cr> must still be
present as a "place holder."
Tag<sp>Data:
===========
The tag+data lines are type 3 ASCII's method of automatically
expanding its headers. A tag consists of a sequence of uppercase
alphabetic (A-Z inclusive) and/or numeric sequence of characters
and possibly a hyphen (ASCII character 45) and/or underline (ASCII
character 95), up to 12 characters in length (a name). A tag name
can be followed optionally by a space (ASCII character 32) and
data. Data may be composed of any combination of ASCII characters
> 31 (from the space character, ASCII character 32, onward).
To aid in developer experimentation with tags in type 3 ASCII, it
is guaranteed that the FTSC or whatever body guards tech specs
FIDONEWS 14-18 Page 19 5 May 1997
will never "canonize" a tag beginning with the two characters "X-"
(ASCII character 88 followed immediately by ASCII character 45).
Thus, tags may use this combination before tag names to guarantee
uniqueness.
Experimental tags may be stripped by conforming implementations
during message passthrough. This helps prevent experimental tags
from escaping from test sites.
Samples (tag names are invented):
FOLLOW AFILEN.AME
X-TAG SOMEDATA
LONETAG
Tag<sp>data fields are optional and may be completely omitted when
creating a packet. Exception: all tag<sp>data fields except,
possibly, experimental fields, should be passed through with a
message being forwarded.
Predefined tags:
===============
Tag Where Data Meaning
--- ----- ---- -------
PRIV Msg Hdr None Message is private
FOROK Pkt Hdr None Packet may be forwarded
without unpacking -- all
messages are
to the To: address in the
packet header
Type 3 ASCII vs. Type 2:
=======================
Type 3 ASCII saves between 6% to 11% in raw packet size over type 2
(using Tiny Seenbys with the type 2 packets to make the test as fair
as possible), depending on how area tags for echos are used in the
type 3 ASCII packet (in packet header vs. message headers). 7%
smaller would be the norm for the way we do echomail business now.
The tests conducted were most unscientific but should be close to
everyday echomail-oriented reality.
Compressed packets are a slightly different story. Type 3 ASCII
compresses the same as type 2 when using area tags for echos in the
message headers. Type 2 compresses approximately 2.5% better when
area tags are used in the type 3 ASCII packet headers instead. Either
way, compressed type 3 ASCII packets are smaller than comparable type
2 packets due to the smaller raw packet size. Even compression ratios
would be the norm for the way we do echomail business now.
Type 3 ASCII imports between 2% to 5% faster (depending on algorithms
used). There is no discernable difference on export. Keep in mind
that this particular test has too many variables (software, hardware,
relative efficiency of code, etc.) to be considered a real benchmark.
Most of the speed savings is in not having to process SEEN-BY and PATH
FIDONEWS 14-18 Page 20 5 May 1997
lines. The lack of end-of-text control information is a real boon.
Type 2 has no method for reliably obtaining the full 5-D origin
address of a message. Type 3 ASCII provides a reliable method of
obtaining full origin address information for both the true origin (in
whatever network) and the gateway which brought the message into FTN
territory (if from a foreign network). This means that even if a
message originated in a network with which your software has no idea
how to communicate, you can still send a reply to an FTN node for
gating.
Type 2 has no reliable method for stopping dupes. Type 3 ASCII has a
mandatory ID field, very similar to type 2's optional MSGID, which can
be used for reliable dupe checking.
Type 2 echomail has control information scattered throughout the
message body, including SEEN-BY and PATH information at the end of the
message. This causes problems for developers, who often opt for
fixed-length buffers and arbitrary message length limits. All control
information for Type 3 ASCII is in the extensible message header.
Moreover, type 3 ASCII has generous set limits to which programmers
can work, and which users can therefore rely on.
Definitions:
===========
Except where noted otherwise, numbers are in decimal.
Although the ASCII character set is normally defined as being
limited to characters from 0 to 127, this document acknowledges the
existence of an eighth bit in most bytes and uses the term (loosely)
to mean characters from 0-255. Network politics may or may not
"outlaw" the use of some of those bytes; that is outside the scope
of this document.
Note: text in brackets [] indicates an optional field. See
"Definitions" section below for meaning of text in <>. See
"Description of Fields" section below for information on
individual fields.
Alphabetic:
==========
A-Z and a-z, ASCII characters 65 to 90 and 97 to 122 inclusive.
Numeric:
=======
0-9, ASCII characters 48 to 57 inclusive.
Alphanumeric:
============
All characters alphabetic and numeric.
Hexadecimal:
FIDONEWS 14-18 Page 21 5 May 1997
===========
0-9 and A-F (or a-f), ASCII characters 48 to 57 and 65 to 70 (or 97
to 102) inclusive.
NUL:
===
ASCII character 0.
<cr>:
====
Carriage return, ASCII character 13.
<lf>:
====
Line feed, ASCII character 10.
<sp>:
====
Space, ASCII character 32.
<@>:
===
@, ASCII character 64.
<#>:
===
#, ASCII character 35.
<:>:
===
:, ASCII character 58.
</>:
===
/, ASCII character 47.
<.>:
===
., ASCII character 46.
<3ASCII>:
========
The literal string "3ASCII" (not including quotation marks). This
text, followed by a <cr>, identifies a type 3 ASCII packet.
Implementations should *not* processes a file unless this
FIDONEWS 14-18 Page 22 5 May 1997
identifier is found on the first line, but should probably log the
occurrence.
<fileroot>:
==========
Eight alphanumeric characters that serve as the "root" of a
filename.
<3KT>:
=====
The literal string "3KT" (not including quotation marks).
<3?A>:
=====
The literal string "3?A" (not including quotation marks) with the
question mark (?) being replaced by a decimal integer from 0 to
9 (ASCII 48 to 57 inclusive).
Miscellaneous notes:
===================
jim nutt invented MSGIDs and REPLYids (ref. FTS-0009), which were
lifted very nearly whole to become IDs and Refs in this document. Tom
Jennings invented Fido and Fidonet <tm and stuff> from whole cloth and
RAM chips. NET_DEV's continual foolishness inspired me to do instead
of whine. Let's see if this cuts down on the whining...
-end-
Mark Kimes
1:380/16.0@Fidonet
(318)222-3455 data
542 Merrick
Shreveport, LA, USA 71104
-30-
-----------------------------------------------------------------
Document: FSC-0066
Version: 001
Date: 02-Aug-1992
Type 3 Binary: A proposal
==========================
Mark Kimes
FidoNet 1:380/16
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
FIDONEWS 14-18 Page 23 5 May 1997
community, and requests discussion and suggestions for
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Preliminary specifications for type 3 binary mail format:
========================================================
Type 3 binary is a new form of mail for Fidonet Technology Networks
(FTN).
The basic unit of type 3 binary mail is a chunk. A chunk looks like
this:
+-------------------------------------+
| 2-byte integer length (type + data) | (A 2-byte integer is
+-------------------------------------+ a signed integer in
| 2-byte integer type | Intel format, giving
+-------------------------------------+ a length range of
| length - 2 of data | 2-32767 (0 is unused))
+-------------------------------------+
Predefined chunk types:
======================
Mnemonic VAL Where Data format
-------- --- ----- -----------
*EOP 0 PKT None
*FROM 1 BOTH FTN address in packet, name + FTN address in msg
TO 2 BOTH [FTN address in packet,] name + [FTN address] in
msg
SUBJECT 3 MSG Text
*ID 4 MSG 4-byte long integer
REF 5 MSG 4-byte long integer followed by FTN address
*DATE 6 MSG Packed date
ATTRIB 7 BOTH 2-byte integer (bit field)
PASSWORD 8 PKT Text
*PRODUCT 9 PKT Text
AREA 10 BOTH Text
*MSG 11 MSG 4-byte long integer (length of total msg)
TEXT 12 MSG Text
ORIG 13 BOTH origin address in native network's format
Notes:
-----
* = required field
Addresses are always in text.
An FTN address is in the form: domain<#>zone<:>net</>node<.>point
Name + address form is: user
name<@>domain<#>zone<:>net</>node<.>point Address in TO field may be
omitted for broadcast mail.
Defined attributes: 1 = PRIVATE in messages, Forward ok in pkt
header Packed date:
+---------------------------------------------------------+
FIDONEWS 14-18 Page 24 5 May 1997
| unsigned int year |
+---------------------------------------------------------+
| unsigned byte month (1-12) |
+---------------------------------------------------------+
| unsigned byte day-of-month |
+---------------------------------------------------------+
| unsigned byte hour |
+---------------------------------------------------------+
| unsigned byte minute |
+---------------------------------------------------------+
| unsigned byte second |
+---------------------------------------------------------+
| signed int gmt offset (15 min increments, -32767 = n/a) |
+---------------------------------------------------------+
A type 3 binary packet always begins with a single byte containing the
binary number 3. This is followed by the first chunk. A packet
"header" is composed of all chunks until the first MSG chunk is
encountered. A header should contain at least a FROM chunk, either a
TO chunk or an AREA chunk, and a PRODUCT chunk. PASSWORD, ORIG and
ATTRIB chunks might also be used.
The rest of the "specs" can be gleaned or clarified from the (working)
code included in the 3bcsrc.lzh archive. Personally, I don't think
this type of packet is much suited to FTN mail; too much of what we do
is text oriented. But here it is, to possibly get your tails moving
(or convince you that type 2 or type 3 ASCII is more what we need).
The main reasons for the 3binary archive are to show you I've done my
homework, to give working examples of the "other type" of type 3 mail
some folks advocate, and for comparison to type 3 ASCII and type 2.
Mark Kimes
fidonet#1:380/16.0
(318)222-3455 data USA
-30-
-----------------------------------------------------------------
Document: FSC-0067
Version: 001
Date: 02-Aug-1992
A Proposal For Sensible New Kludge Lines
========================================
Mark Kimes
FidoNet 1:380/16
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
FIDONEWS 14-18 Page 25 5 May 1997
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
MSGTO: This kludge line, together with a MSGID: kludge (see FTS-
0009), would provide full address specs for both the
originating and destination nodes of a netmail message (MSGTO
should _not_ be used in echo mail). Its format is simple:
^aMSGTO: <FTN address>
MSGTO (coupled with MSGID) would eliminate the need for the
INTL, FMPT, TOPT and DOMAIN kludges. A MSGTO kludge line
should go just below any MSGID and REPLY kludge lines. See
also discussion on FTN address representation below.
ASSOC: ASSOC introduces a filename that should follow the message (is
associated with the message). Format is, again, simple:
^aASSOC: <filename>
A message tosser would forward the file along with the
message, if so configured for the AREA: of the message
(assuming echomail) or other criteria. Paths would probably
not be useful in the <filename> field and should not normally
be included or used if found to be present. ASSOC kludge
lines should go below any addressing kludge lines.
SPTH: Clint Adams described this as a "5D, sensible order, top-of-
the-message path" line. I like that. Stands for "Sticky
PaTH." SPTH displaces the current PATH line. Instead of
being located at the bottom of the message, it's located at
the top of the message. Instead of being 2-D (net/node), it's
5-D (domain#zone:net/node.point). It's sticky like a normal
PATH line so that the size doesn't get outrageous. Because
it's 5-D instead of 2-D it can be used for dupe checking
(which a normal 2-D PATH line cannot; is 1/1 Fidonet#1:1/1 or
Dufusnet#2:1/1?). Because it's 5-D we would no longer have to
go through hideous gyrations when gating echo mail from one
domain to another; just let it flow. Using SPTH it becomes
trivial to cut SEEN-BYs down to Tiny Seenbys (only required
for backward compatibility with old mail processors that barf
without some SEEN-BYs, and to protect fully enclosed polygon
topology).
SPTH is to be used only in echo mail. It's format is
basically:
^aSPTH: <address> <address> ... <address>
SPTH lines, like PATH lines, contain only addresses of mail
processors that actually processed the message. SPTH lines
are specifically not sorted and are "sticky" so that they
carry the least amount of information that will convey a full
address when coupled with preceding addresses. For example,
if 1:380/16.0@Fidonet, 1:380/16.1@Fidonet,
1:380/100.0@Fidonet, 1:396/100.0@Fidonet, 2:4177/1.0@Fidonet
and 2:4177/1.0@Othernet processed a message, in that order,
you'd have:
FIDONEWS 14-18 Page 26 5 May 1997
^aSPTH: Fidonet#1:380/16 .1 100 :396 #2:4177/1 Othernet
Note that point 0 is assumed if missing and that punctuation
*precedes* an address element except in the case of a domain
change (and when the net element is the first change -- this
dictates that domain names begin with an alphabetical
character). This compacts SPTH entries as much as possible
for most typical topologies.
When an SPTH-aware processor forwards a message containing (a)
PATH line(s) but no SPTH line(s), it should create a new SPTH
line (or lines as required; SPTH lines shouldn't get longer
than 80 characters, including terminating carriage return)
containing "fleshed-out" addresses from the PATH line(s), then
add itself. If this is done at all zone/domain gates, the
SPTH will always be current even if intermediate nodes are not
SPTH-aware. In the event an SPTH-aware processor receives a
message containing both SPTH line(s) and PATH line(s), it
should concatenate the "fleshed-out" addresses from the PATH
line(s) to the SPTH line(s), then add itself. The PATH
line(s) may then be discarded from the message. When
exporting new messages, only a SPTH line should be created; no
PATH line should be generated. Tiny Seenbys should be added
at the end of the message for the reasons noted above.
Note that all the kludge lines above are in actual use and have been
for some time; they do work, and work as presented. Code is available
on request, but implementation is trivial (only SPTH takes any real
work at all).
FTN address representation:
==========================
The current convention for representing an FTN address has become:
zone:net/node[.point]@domain
I propose we change this to:
domain#zone:net/node[.point]
Why? It's all in one order, highest to lowest; it's consistent. "@"
is used, in the former method, in a way rather opposed to normal usage
in network addressing.
While we're on the subject of domains, let's knock off using
"fidonet.org" in FTN addresses. That only means something in
Internet. It's going to gum up the works for FTN domains, where we'll
want things like "fidonet.eu" to mean Fidonet Europe some day.
I'm done now.
Mark Kimes
Fidonet#1:380/16
(318)222-3455 data
FIDONEWS 14-18 Page 27 5 May 1997
-30-
-----------------------------------------------------------------
FIDONEWS 14-18 Page 28 5 May 1997
=================================================================
WE GET EMAIL
=================================================================
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)
Date: Sat, 03 May 97 11:50:28 -0600
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
Subject: Fwd: Norton/Microsoft Security Breach (Long)
==================BEGIN FORWARDED MESSAGE==================
>Sender: rkodner@popd.ix.netcom.com
>X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
>Date: Sat, 03 May 1997 11:29:30 -0500
>To: network2d-l@austin.onu.edu, solosez@abanet.org,
>lawtech@abanet.org >From: Ross Kodner <rkodner@ix.netcom.com>
>Subject: Norton/Microsoft Security Breach (Long)
>Sender: owner-solosez@mail.abanet.org
Holy Moley! The latest chapter in the Internet Explorer Security Hole
of the Day saga from www.winsources.com:
Norton Utilities, Internet Explorer Combo Puts Systems in Harm's Way
(by Jesse Berst)
Combination of NU 2.0 for Windows 95 and Internet Explorer 3.x
highlights security weaknesses in ActiveX controls
Your worst fears have come true. McAfee Associates has discovered, and
Windows Sources has confirmed, a flaw in the underlying architecture
of Internet Explorer and Windows 95 that renders users of the Web
vulnerable to a range of catastrophes. These disasters range from an
involuntary reformatting of your hard drive to breach of information
once thought to be secure.
Users running the combination of Windows 95, Internet Explorer 3.x,
and Symantec's Norton Utilities 2.0 for Windows 95, one of the most
popular and widely used software utility products for Windows 95, are
currently known to be at risk. (In the spirit of disclosure, users
should be aware that McAfee Associates and Symantec Corp. are
competitors in the utilities and anti-virus software market.)
Neither Verisign's Authenticode (which is built-in to Internet
Explorer) or recent IE security patches posted on Microsoft's Web site
offer any protection. According to Reston, VA-based research firm PC
Data, 143,559 licenses have been issued for Norton Utilities, and
125,825 users have Internet Explorer. The number of users who have
actually deployed both at the same time is unknown.
The problem lies in TUNEOCX.OCX, a core component of Norton Utilities'
System Genie. When installed, this OCX is marked as scriptable, which
allows ActiveX-aware Web page scripts to make use of this ActiveX
control. This control supports a "run" option that allows the script
to execute any local application, such as the FORMAT or FTP (net-based
file transfer) commands.
FIDONEWS 14-18 Page 29 5 May 1997
Windows Sources analysis of Norton Utilities found that this component
essentially granted unauthorized access to any system resource that is
normally accessible from the desktop itself. As a result, any
programmer with access to one of Microsoft's scripting tools
(VBScript, MS C++, Visual C++, Visual J++, etc.) can leverage this
control to perform any task on the target system -- unbeknownst to the
system's user.
For example, a Web page hacker could build a page that, when viewed by
Internet Explorer, runs a few lines of VBScript code that wipes out a
hard drive, installs a Trojan horse, or invokes file transfer and
directory utilities to retrieve confidential information. Worse yet,
all these tasks could be performed in the background without the user
ever knowing what's happening to their system.
Verisign's Authenticode, billed by Microsoft as a protection mechanism
built into Internet Explorer that allows users to intervene before
potentially dangerous code is downloaded, is ineffective against this
sort of invasion. That's because Authenticode watches for software
that's about to be downloaded, but not VBScripts that activate
software components that are already installed on the system (e.g.:
TUNEOCX.OCX).
Although the aforementioned combination of software is currently the
only known group at risk, there could be other combinations of
application and ActiveX-based browsers that are equally vulnerable.
The smoking gun in this example is Norton Utilities 2.0, but NU simply
exposes an important and oft-debated feature/weakness in Microsoft's
ActiveX architecture. Other products that are already deployed en
masse could be "offering" the same service to those with malicious
intent.
In tests, Windows Sources found the same combination running on
Windows NT (including the NT-based version of NU) to be safe.
HealthyPC, another PC tune-up utility from Symantec also tested safe
at Windows Sources.
SYMANTEC, MICROSOFT RESPOND
According to Symantec Sr. Product Manager Tom Andrus, "It is a
problem. We know how serious it is. But we think that it is very
uncommon. To our knowledge, there are no Norton Utilities users in the
world that have run into this."
To Symantec's credit, Norton Utilities 2.0 includes a feature called
Live Update that automatically updates a user's system with new
drivers and software, when that system is connected to the Internet.
"We've worked out a fix and it's in the hands of our quality assurance
group right now," said Andrus. "By this afternoon, a fix will be up
on-line so that any PC that connects to the Internet while running
Live Update will be automatically fixed so as not to allow this
again." For more information, users can go to www.symantec.com.
Microsoft sought to put this situation in a more positive light,
highlighting the ability to quickly fix the problem rather than the
FIDONEWS 14-18 Page 30 5 May 1997
problem itself.
"The fact that [Symantec] could fix it so quickly is a major testament
to the flexibility of the ActiveX architecture," said Microsoft
Program Marketing Manager Cornelius Willis. "Yes, this is a threat but
there are so many threats. Vendors can mark off-the-shelf software
safe-to-script or not-safe-to-script. For example, Microsoft Excel is
marked not-safe-to-script because it has access to system resources.
Therefore Excel is invulnerable to such attack. VBScript and
JavaScript will only instantiate controls that are marked safe-to-
script and this was one of them."
"Plug-ins (a la Netscape's Navigator) have no digital certificates or
safe-to-script toggles and we feel that ActiveX is the only
architecture that offers any kind of accountability for downloaded
software," added Willis.
But, in Windows Sources tests of the Norton Utilities example, ActiveX
offered no opportunity to engage this accountability since it involved
a script acting against an already installed component (from shrink-
wrapped software) rather than the downloading of software.
SOLVING THE PROBLEM
There are preventative measures users can take to protect themselves.
Following one of these five steps will help protect your system from
the effects of the toxic software combination:
1) Download the patch from Symantec
2) Uninstall Norton Utilities
3) Disable support for ActiveX-scripting in Internet Explorer
4) Switch to a non-ActiveX-based browser such as
Netscape's Navigator,
5) Stay off the Net.
Be warned also that, going forward, addressing the problem through
Norton Utilities is not a complete fix. Downloading a patch or
uninstalling NU will not protect a system if other equally vulnerable
software is already installed. Additionally, disabling ActiveX
scripting or switching to a non-ActiveX browser may disable other web-
and ActiveX-based applications. Manually disabling Norton Utilities
without uninstalling it is unlikely to safeguard the system and
therefore is not recommended.
Corporate sites that use Windows 95's centralized policy management
features may also disable the ability to run Internet Explorer
throughout their local area networks. Unfortunately, the same policy
management feature doesn't provide centralized management of Internet
Explorer's run options, making it impossible to reach across corporate
nets and just disable support for ActiveX scripting.
Finally, for those who are really paranoid, switching to Windows NT
might be one last measure of assurance. Under Windows NT, software
cannot be executed without a security token that authenticates the
code's privileges to the system's resources. Such code usually
inherits the rights of the user sitting at the machine, thus limiting
FIDONEWS 14-18 Page 31 5 May 1997
intruding code to only the resources the user has rights to access.
Provided that the user doesn't have administrator-level rights, the
malicious code's impact could be far less catastrophic.
For further discussion on this important issue, ask questions and
express your opinions in the ActiveX Expert Answers Forum."
Ross
______________________________________________________
Ross L. Kodner, Esq. Voice: 414-476-8433
MicroLaw, Inc. FAX: 414-476-8461
825 S. 60th St. E-Mail: rkodner@ix.netcom.com
Milwaukee, WI 53214
Web1: http://www.microlaw.com
Web2: http://www.wisbar.org/legalres/rosslegal.html
Web3: http://www.microlaw.com/kodner/index.htm
ABA LPM "Network 2d" Ass't Editor Always Seeking Great Articles!
______________________________________________________
===================END FORWARDED MESSAGE===================
-30-
-----------------------------------------------------------------
FIDONEWS 14-18 Page 32 5 May 1997
=================================================================
NET HUMOR
=================================================================
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)
Date: Thu, 24 Apr 97 11:31:50 -0600
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
Subject: Fwd: The Microsoft Restaurant
==================BEGIN FORWARDED MESSAGE==================
"If restaurants functioned like Microsoft:
Patron: Waiter!
Waiter: Hi, my name is Bill and I'll be your Support Waiter. What
seems to be the problem?
Patron: There's a fly in my soup!
Waiter: Try again, maybe the fly won't be there this time.
Patron: No, it's still there.
Waiter: Maybe it's the way you're using the soup; try eating it
with a fork instead.
Patron: Even when I use the fork, the fly is still there.
Waiter: Maybe the soup is incompatible with the bowl; what kind
of bowl are you using?
Patron: A SOUP bowl!
Waiter: Hmmm, that should work. Maybe it's a configuration
problem; how was the bowl set up?
Patron: You brought it to me on a saucer; what has that to do with
the fly in my soup?
Waiter: Can you remember everything you did before you noticed
the fly in your soup?
Patron: I sat down and ordered the Soup of the Day!
Waiter: Have you considered upgrading to the latest Soup of the Day?
Patron: You have more than one Soup of the Day each day?
Waiter: Yes, the Soup of the Day is changed every hour.
Patron: Well, what is the Soup of the Day now?
Waiter: The current Soup of the Day is tomato.
FIDONEWS 14-18 Page 33 5 May 1997
Patron: Fine. Bring me the tomato soup and the check. I'm running
late now.
[Waiter leaves and returns with another bowl of soup and the check.]
Waiter: Here you are, Sir. The soup and your check.
Patron: This is potato soup.
Waiter: Yes, the tomato soup wasn't ready yet.
Patron: Well, I'm so hungry now, I'll eat anything.
[Waiter leaves.]
Patron: Waiter! There's a gnat in my soup!
----------
The check:
Soup of the Day . . . . . . . . . . . $ 5.00
Upgrade to newer Soup of the Day. . . $ 2.50
Access to support . . . . . . . . . . $10.00
Editors Note:
Bug in the soup........included at no extra charge
(will be fixed with Tomorrow's soup of the day)"
:-)
Ross
______________________________________________________
Ross L. Kodner, Esq. Voice: 414-476-8433
MicroLaw, Inc. FAX: 414-476-8461
825 S. 60th St. E-Mail: rkodner@ix.netcom.com
Milwaukee, WI 53214
Web1: http://www.microlaw.com
Web2: http://www.wisbar.org/legalres/rosslegal.html
Web3: http://www.microlaw.com/kodner/index.htm
ABA LPM "Network 2d" Ass't Editor Always Seeking Great Articles!
______________________________________________________
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 14-18 Page 34 5 May 1997
=================================================================
COMIX IN ASCII
=================================================================
--- Following message extracted from MENSANS_ONLY @ 1:18/14 ---
By Christopher Baker on Wed Apr 30 12:31:45 1997
From: Francois Thunus
To: All
Date: 29 Apr 97 20:16:00
Subj: Learning to dive (fwd)
======================================================================
* Forwarded by Francois Thunus (2:270/25.2)
======================================================================
Dear Friends, this is a work of art, that I hope will work on all
your screens.
Yours
Martin
Start scrolling down with the arrow key, and AS SOON AS
"** Start Hitting Spacebar Now **" appears on the bottom line of you
screen, start hitting the spacebar/page down slowly.
>>>
>>>
>>>
>>>
>>>
>>> o ___
>>> /|\ /___\______
>>>__/_\___/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>> ** Start Hitting Spacebar Now **
>>>
>>>
>>
>>
>>>
>>> o ___
>>> /|\ /___\______
>>>___/_\__/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
FIDONEWS 14-18 Page 35 5 May 1997
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o ___
>>> |=/___\_______
>>>_____/>/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> |=___
>>> /|/___\_______
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> /|\
>>> //_\\_______
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
FIDONEWS 14-18 Page 36 5 May 1997
>>>
>>>
>>> o
>>> _/|\
>>> /_/_\_______
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___/|\
>>> /___/_\_____
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___ /|\
>>> /___\/_\____
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___ /|\
>>> /___\_/_\____
FIDONEWS 14-18 Page 37 5 May 1997
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___ /|\
>>> /___\__/_\_
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___ /|\
>>> /___\____/_\
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___ |=
>>> /___\______|
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
FIDONEWS 14-18 Page 38 5 May 1997
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___ o
>>> /___\__ |=
>>>_______/____|_ ---_>
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> ___ |=
>>> /___\______>
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> o
>>> /=
>>> ___ _>
>>> /___\___---
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
FIDONEWS 14-18 Page 39 5 May 1997
>>>
>>>
>>> o
>>> /=
>>> /
>>> ___
>>> /___\_______
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __o
>>> / \
>>> ___
>>> /___\_____
>>>_______/____|_ --
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ____o
>>> ___ \
>>> /___\_______
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __
FIDONEWS 14-18 Page 40 5 May 1997
>>> ___ \o
>>> /___\_______ \
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___ \
>>> /___\_______ \o
>>>_______/____|_ \
>>> |
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______ \
>>>_______/____|_ \
>>> | |o
>>> |
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_ \|
>>> | |
>>> | |o
FIDONEWS 14-18 Page 41 5 May 1997
>>> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> | \|
>>> | ' |..'
>>> |~~~~~~~~~~~~~~~~~~~/o'~~~~~~
>>>
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_ . .
>>> | . '. '
>>> | '.\/..'.
>>> |~~~~~~~~~~~~~~~~~~~~~~/,~~~~
>>> /o
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> | .'..''..
>>> | . .'.' '
>>> |~~~~~~~~~~~~~~~~~~~~~~;|/,~~
>>> _o/
>>>- /
>>>
>>>
FIDONEWS 14-18 Page 42 5 May 1997
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> | . .
>>> | ..'.'.
>>> |~~~~~~~~~~~~~~~~~~~~~~;,;~~~
>>> _o__/'
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> |
>>> | . .
>>> |~~~~~~~~~~~~~~~~~~~~~~~;~~~~
>>> o__// ''
>>>- //
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> |
>>> |
>>> |~~~~~~~~~~~~o~~~~~~~~~~~~~~~
>>> |\__
>>>- \
>>>
>>>
>>>
>>>
>>>
>>>
>>>
FIDONEWS 14-18 Page 43 5 May 1997
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> |
>>> | o
>>> |~~~~~~~~~/|\~~~~~~~~~~~~~~~~~~
>>> / \
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> |
>>> | o/
>>> |~~~~~~~~~/|~~~~~~~~~~~~~~~~~
>>> / \
>>>-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> /___\_______
>>>_______/____|_
>>> | , CIAO in next mail!
>>> | o/
>>> |~~~~~~~~~/|~~~~~~~~~~~~~~
>>> / \
>>>-
>>>
>>>
>>>------------ Forwarded Message ends here ------------
-+-
======================================================================
Hello All!
-= Francois =-
Thunus@Club.TeleMatique.org
http://www.telematique.org/ft
Of course I'm running Windows NO CARRIER
FIDONEWS 14-18 Page 44 5 May 1997
Origin: Gasperich - Luxembourg (zone 2!) ->> (FidoNet 2:270/25.2)
-----------------------------------------------------------------
FIDONEWS 14-18 Page 45 5 May 1997
=================================================================
NOTICES
=================================================================
Future History
17 May 1997
Independence Day, Norway.
3 Jun 1997
2 years since FidoNet had an International Coordinator.
6 Jun 1997
National Commemoration Day, Sweden.
12 Jun 1997
Independence Day, Russia.
1 Jul 1997
Canada Day - Happy Birthday Canada.
9 Jul 1997
Independence Day, Argentina.
13 Oct 1997
Thanksgiving Day, Canada.
1 Dec 1997
World AIDS Day.
10 Dec 1997
Nobel Day, Sweden.
12 Jan 1998
HAL 9000 is one year old today.
22 May 1998
Expo '98 World Exposition in Lisbon (Portugal) opens.
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
1 Jan 2000
The 20th Century, C.E., is still taking place thru 31 Dec.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
1 Jan 2001
This is the actual start of the new millennium, C.E.
-- If YOU have something which you would like to see in this
FIDONEWS 14-18 Page 46 5 May 1997
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
To: vtw-announce@vtw.org, crypto-news@panix.com
From: shabbir@vtw.org (Shabbir J. Safdar)
Reply-To: shabbir@vtw.org (Shabbir J. Safdar)
Subject: ALERT: Groups urge passage of pro-crypto legislation
(4/28/1997)
Date: Mon, 28 Apr 1997 22:26:58 -0400
Sender: owner-crypto-news@lists.panix.com
Reply-To: crypto-news@lists.panix.com
======================================================================
___ _ _____ ____ _____ _
/ _ \| | | ____| _ \_ _| | HOUSE PREPARES TO ENSURE ENCRYPTION
| |_| | | | _| | |_) || | | | AND PRIVACY ON THE INTERNET; SAFE
| _ | |___| |___| _ < | | |_| BILL (HR 695) ABOUT TO BE VOTED ON!
|_| |_|_____|_____|_| \_\|_| (_) April 28, 1997
Do not forward this alert after June 1, 1997.
This alert brought to you by:
Americans for Tax Reform Center for Democracy and
Technology
Eagle Forum EF-Florida
Electronic Frontier Foundation Electronic Privacy Information
Ctr.
Voters Telecommunications Watch Wired Magazine
______________________________________________________________________
Table of Contents
What's Happening Right Now
What You Can Do To Help Privacy And Security On The Internet
Background On SAFE (HR 695)
Why Is This Issue Important To Internet Users?
About This Alert / Participating Organizations
______________________________________________________________________
WHAT'S HAPPENING RIGHT NOW
HOUSE JUDICIARY COMMITTEE TO VOTE ON "SAFE" PRO-INTERNET PRIVACY BILL
The House Judiciary Committee is set to vote on a bill designed to
protect privacy and promote electronic commerce on the Internet as
early as the second week of May. The SAFE bill will also be
considered by a Judiciary subcommittee this week and is expected to
pass without difficulty.
The House Judiciary committee vote on HR695 will mark a critical stage
in the effort to pass real reform of US encryption policy in a way
that protects privacy, promotes electronic commerce, and recognizes
the realities of the global Internet.
FIDONEWS 14-18 Page 47 5 May 1997
Although no bill is perfect, Internet advocates including CDT, EFF,
EPIC, VTW and others, including the Internet Privacy Coalition, have
expressed support for the bill. Supporters agree that the SAFE bill
holds great promise for enhancing privacy and security on the Internet
and have offered their strong support and suggestions to improve it in
a detailed letter at http://www.privacy.org/ipc/safe_letter.html
Please take a moment to read the attached alert, and make a phone call
to urge the committee to pass the bill.
______________________________________________________________________
WHAT YOU CAN DO TO HELP PRIVACY AND SECURITY ON THE INTERNET
1. Check out the information on the SAFE bill below.
2. Call the Representative on the Judiciary committee from your state.
Note that there may be more than one person from your state on the
committee. The list is enclosed below the telephone script.
SAMPLE SCRIPT
You: <dial Capitol switchboard +1.202.224.3121>
May I speak to the office of Rep. (INSERT NAME FROM LIST
BELOW)
Them: Hello, Rep. Mojo's office!
You: May I speak with the staffer who deals with Internet or
telecom issues?
Them: One minute..
SAY THIS-> You: Hello! HR695 will be voted on by the Judiciary
committee in a couple of weeks. I'm calling to urge Rep.
Mojo to pass the bill because it's important to security
and privacy on the Internet.
Them: Thanks, goodbye!
You: Goodbye! <click>
If you have concerns about specific improvements to the bill,
bringing them up when you're on the phone with the staffer is a
good opportunity for raising issues.
Judiciary Committee Members (from committee Web page)
MR. HYDE (ILLINOIS), CHAIRMAN
Mr. Sensenbrenner (Wisconsin) Mr. Conyers (Michigan)
Mr. McCollum (Florida) Mr. Frank (Massachusetts)
Mr. Gekas (Pennsylvania) Mr. Schumer (New York)
Mr. Coble (North Carolina) Mr. Berman (California)
Mr. Smith (Texas) Mr. Boucher (Virginia)
Mr. Schiff (New Mexico) Mr. Nadler (New York)
Mr. Gallegly (California) Mr. Scott (Virginia)
Mr. Canady (Florida) Mr. Watt (North Carolina)
FIDONEWS 14-18 Page 48 5 May 1997
Mr. Inglis (South Carolina) Ms. Lofgren (California)
Mr. Goodlatte (Virginia) Ms. Jackson Lee (Texas)
Mr. Buyer (Indiana) Ms. Waters (California)
Mr. Bono (California) Mr. Meehan (Massachusetts)
Mr. Bryant (Tennessee) Mr. Delahunt (Massachusetts)
Mr. Chabot (Ohio) Mr. Wexler (Florida)
Mr. Barr (Georgia) Mr. Rothman (New Jersey)
Mr. Jenkins (Tennessee) Mr. Hutchinson (Arkansas)
Mr. Pease (Indiana) Mr. Cannon (Utah)
3. *IMPORTANT* Touch base with us at http://www.crypto.com/feedback/
and let us know how the phone call went. Fill out the easy to use
form to let us know what happened during your phone call.
4. Pass this alert on to others until June 1
You've taken the first step to being a part of the powerful
political force of Americans concerned about the health and safety
of the Internet, but have your friends? Forward this alert to them
until June 1, 1997 and urge them to adopt their legislator at
http://www.crypto.com/adopt/
5. Be proud of yourself and relax!
You've done more to protect the Internet in five minutes than many
people will do this year.
______________________________________________________________________
BACKGROUND ON SAFE (HR 695)
In early May, the Judiciary Committee will be voting on whether to
send HR 695, the Security and Freedom Through Encryption (SAFE) Act,
on to the full House of Representatives.
The SAFE Bill, introduced by Reps. Bob Goodlatte (R-VA) and Anna Eshoo
(D-CA), would promote privacy and security on the Internet by:
* relaxing current export controls on encryption technologies;
* prohibiting the government from imposing "key-escrow" or "key-
recovery" inside the United States, and;
* addresses concerns from law enforcement about the use of encryption
in the furtherance of a crime.
The SAFE bill enjoys broad bi-partisan support and currently has 78
co-sponsors.
Although no bill is ever perfect, the SAFE bill, along with Pro-CODE,
a similar bill in the Senate sponsored by Sens. Burns (R-MT) and Leahy
(D-VT), represent the best chance yet of passing real reform of US
encryption policy. The Senate Commerce Committee is expected to hold
a markup on Pro-CODE soon.
The Clinton Administration, through the FBI and NSA, is working hard
behind the scenes to block passage of SAFE and Pro-CODE. The
FIDONEWS 14-18 Page 49 5 May 1997
Administration favors an approach which would limit the availability
of privacy-protecting encryption technologies and compel American
Citizens to ensure law enforcement access to their private online
communications.
By passing the SAFE bill and sending on to the floor, the House
Judiciary Committee will send a strong signal to the Administration
that Congress is serious about passing real reform of US encryption
policy, and would represent an important victory in the fight for
privacy on the Internet.
Detailed background information, including the full text of the bill,
and analysis is available online at http://www.crypto.com/
______________________________________________________________________
WHY IS THIS ISSUE IMPORTANT TO INTERNET USERS?
Encryption technologies are the locks and keys of the Information age
-- enabling individuals and businesses to protect sensitive
information as it is transmitted over the Internet. As more and more
individuals and businesses come online, the need for strong, reliable,
easy-to-use encryption technologies has become a critical issue to the
health and viability of the Net.
Current US encryption policy, which limits the strength of encryption
products US companies can sell abroad, also limits the availability of
strong, easy-to-use encryption technologies in the United States. US
hardware and software manufacturers who wish to sell their products on
the global market must either conform to US encryption export limits
or produce two separate versions of the same product, a costly and
complicated alternative.
The export controls, which the NSA and FBI argue help to keep strong
encryption out of the hands of foreign adversaries, are having the
opposite effect. Strong encryption is available abroad, but because of
the export limits and the confusion created by nearly four years of
debate over US encryption policy, strong, easy-to-use privacy and
security technologies are not widely available off the shelf or "on
the net" here in the US.
A recently discovered flaw in the security of the new digital
telephone network exposed the worst aspects of the Administration's
encryption policy. Because the designers needed to be able to export
their products, the system's security was "dumbed down". Researchers
subsequently discovered that it is quite easy to break the security of
the system and intrude on what should be private conversations.
This incident underscores the larger policy problem: US companies are
at a competitive disadvantage in the global marketplace when competing
against companies that do not have such hindrances. And now, for the
first time in history, the Clinton Administration has proposed
DOMESTIC RESTRICTIONS on the ability of Americans to protect their
privacy and security online.
All of us care about our national security, and no one wants to make
it any easier for criminals and terrorists to commit criminal acts.
FIDONEWS 14-18 Page 50 5 May 1997
But we must also recognize encryption technologies can aid law
enforcement and protect national security by limiting the threat of
industrial espionage and foreign spying, promote electronic commerce
and protecting privacy.
What's at stake in this debate is nothing less than the future of
privacy and the fate of the Internet as a secure and trusted medium
for commerce, education, and political discourse.
______________________________________________________________________
ABOUT THIS ALERT / PARTICIPATING ORGANIZATIONS
For more information, contact the following organizations who have
signed onto this effort at their web sites.
Americans for Tax Reform
http://www.atr.org
Center for Democracy and Technology
http://www.cdt.org
Eagle Forum
http://www.eagleforum.org
EF-Florida
http://www.efflorida.org
Electronic Frontier Foundation
http://www.eff.org
Electronic Privacy Information Center
http://www.epic.org
Voters Telecommunications Watch
http://www.vtw.org
Wired Magazine
http://www.wired.com
______________________________________________________________________
end alert
======================================================================
-30-
-----------------------------------------------------------------
FIDONEWS 14-18 Page 51 5 May 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Note: Mid-May, I will phase out the entire "Old Info" section. As
always, I'll be happy to process any information I get, either before
or after it is phased out.
-=- Snip -=-
Submission form for the Latest Greatest Software Versions column
OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :
Please include a sentence describing what the package does.
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.11 O S Peter Karlsson 2:206/221 ANNOUNCE
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
CheckPnt 1.0a O G Michiel vd Vlist 2:500/9 CHECKPNT
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO
FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S JoHo 2:201/330 FD
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO
GEcho 1.00 T S Bob Seaborn 1:140/12 GECHO
GEcho/Plus 1.11 T C Bob Seaborn 1:140/12 GECHO
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
GoldED/386 2.50 O S Len Morgan 1:203/730 GEX
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
FIDONEWS 14-18 Page 52 5 May 1997
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
InfoMail/86 1.21 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.21 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
MakePl 1.9 N G Michiel vd Vlist 2:500/9 MAKEPL
Marena 1.1 beta O G Michiel vd Vlist 2:500/9 MARENA
Maximus 3.01 B P Tech 1:249/106 MAX
McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP
Msged 4.10 O G Andrew Clarke 3:635/728 MSGED41D.ZIP
Msged/386 4.10 O G Andrew Clarke 3:635/728 MSGED41X.ZIP
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.66 O S Peter Hampf 2:241/1090 OT
PcMerge 2.8 N G Michiel vd Vlist 2:500/9 PCMERGE
PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP
QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS
RAR 2.00 C S Ron Dwight 2:220/22 RAR
RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP
Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE
Squish 1.11 T P Tech 1:249/106 SQUISH
StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK
StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Telegard 3.02 B F Tim Strike 1:259/423 TELEGARD
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TosScan 1.01 T C JoHo 2:201/330 TSINFO
TransNet 1.00 G S Marc S. Ressl 4:904/72 TN100ALL.ZIP
TriBBS 11.0 B S Gary Price 1:3607/26 TRIBBS
TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG
TriToss 11.0 T S Gary Price 1:3607/26 TRITOSS
WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
XRobot 3.01 O S JoHo 2:201/330 XRDOS
OS/2:
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
FIDONEWS 14-18 Page 53 5 May 1997
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S JoHo 2:201/330 XROS2
Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
FrontDoor APX 1.12 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.10 M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX
ifmail-tx.rpm ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
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
FIDONEWS 14-18 Page 54 5 May 1997
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPDOOR
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPBETA
TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS
Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY
JetMail 0.99beta22
T S Joerg Spilker 2:2432/1101 JETMAIL
Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA
Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, F-Fossil, O-Other. Note: Multifunction will
be listed by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems Other Utilities Other Utilities
-------------- Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
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
FIDONEWS 14-18 Page 55 5 May 1997
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
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
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-18 Page 56 5 May 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-18 Page 57 5 May 1997
=================================================================
FIDONET BY INTERNET
=================================================================
This is a list of all FidoNet-related sites reported to the Editor as
of this appearance.
============
FidoNet:
Homepage http://www.fidonet.org
FidoNews http://ddi.digital.net/~cbaker84/fidonews.html
HTML FNews http://www.geocities.com/Athens/6894/
WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
FTSC page http://www2.blaze.net.au/ftsc.html
Echomail http://www.portal.ca/~awalker/index.html
WebRing http://ddi.digital.net/~cbaker84/fnetring.html
============
Zone 1: http://www.z1.fidonet.org
Region 10: http://www.psnw.com/~net205/region10.html
Region 11: http://oeonline.com/~garyg/region11/
Region 13: http://www.smalltalkband.com/st01000.htm
Region 14: http://www.netins.net/showcase/fidonet/
Region 15: http://www.smrtsys.com/region15/ [disappeared?]
Region 16: http://www.tiac.net/users/satins/region16.htm
Region 17: http://www.portal.ca/~awalker/region17.htm
Region 18: http://www.citicom.com/fido.html
Region 19: http://home1.gte.net/bhamilt/index.htm
============
Zone 2: http://www.z2.fidonet.org
ZEC2: http://fidoftp.paralex.co.uk/zec.htm [shut down?]
Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm
Region 20: http://www.fidonet.pp.se (in Swedish)
Region 24: http://www.swb.de/personal/flop/gatebau.html (in German)
Region 25:
http://members.aol.com/Net254/
Region 27: http://telematique.org/ft/r27.htm
FIDONEWS 14-18 Page 58 5 May 1997
Region 29: http://www.rtfm.be/fidonet/ (in French)
Region 30: http://www.fidonet.ch (in Swiss)
Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish)
REC34: http://pobox.com/~chr
Region 36: http://www.geocities.com/SiliconValley/7207/
Region 41: http://www.fidonet.gr (in Greek and English)
Region 48: http://www.fidonet.org.pl
============
Zone 3: http://www.z3.fidonet.org
============
Zone 4: (not yet listed)
Region 90:
Net 904: http://members.tripod.com/~net904 (in Spanish)
============
Zone 5: (not yet listed)
============
Zone 6: http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-18 Page 59 5 May 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-18 Page 60 5 May 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-18 Page 61 5 May 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 Copy Permalink