2195 lines
99 KiB
Plaintext
2195 lines
99 KiB
Plaintext
F I D O N E W S -- Volume 14, Number 23 9 June 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. |
|
||
+----------------------------------------------------------------------+
|
||
|
||
|
||
IT'S ONLY LAME WITH AN F
|
||
|
||
|
||
Table of Contents
|
||
1. EDITORIAL ................................................ 1
|
||
What would it take to get YOU to submit something? ....... 1
|
||
2. LETTERS TO THE EDITOR .................................... 2
|
||
To Compress Mail or Not to Compress Mail? ................ 2
|
||
3. ARTICLES ................................................. 4
|
||
FidoNet Via Internet Hubs ................................ 4
|
||
Some thoughts on a possible future direction for Fidone .. 4
|
||
SILLYSEASON Echo forming ................................. 6
|
||
Why I bother ............................................. 7
|
||
4. COLUMNS .................................................. 9
|
||
Lock and Load: Guerilla Marketing for BBSes .............. 9
|
||
5. GETTING TECHNICAL ........................................ 11
|
||
FSC-0080 - Describing FidoNet with layered model ......... 11
|
||
FSC-0081 - A TYPE-3 Packet proposal ...................... 13
|
||
6. COORDINATORS CORNER ...................................... 28
|
||
Nodelist-statistics as seen from Zone-2 for day 157 ...... 28
|
||
7. NET HUMOR ................................................ 29
|
||
Nevermore? ............................................... 29
|
||
8. NOTICES .................................................. 31
|
||
Future History ........................................... 31
|
||
9. FIDONET SOFTWARE LISTING ................................. 32
|
||
Latest Greatest Software Versions ........................ 32
|
||
10. FIDONEWS PUBLIC-KEY ..................................... 36
|
||
FidoNews PGP public-key listing .......................... 36
|
||
And more!
|
||
FIDONEWS 14-23 Page 1 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
EDITORIAL
|
||
=================================================================
|
||
|
||
|
||
What? No urge to write something for FidoNews? You don't have to do a
|
||
formal article or column. You can just send in something via Netmail.
|
||
You can pick something new or forward something of yours from an Echo
|
||
or some other forum.
|
||
|
||
It's your newsletter.
|
||
|
||
C.B.
|
||
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 2 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
LETTERS TO THE EDITOR
|
||
=================================================================
|
||
|
||
|
||
[This wasn't a Letter to the Editor, but it should have been. Folks
|
||
should not be sending compressed mail to strangers. It adds an extra
|
||
step when receiving mail from unsecured sources among other
|
||
concerns. Unless you're sending a ton of mail, why bother?] Ed.
|
||
|
||
--- Following message extracted from FTSC_PUBLIC @ 1:18/14 ---
|
||
By Christopher Baker on Thu Jun 05 15:17:35 1997
|
||
|
||
From: Lisa Gronke
|
||
To: All
|
||
Date: 03 Jun 97 06:45:02
|
||
Subj: ARC
|
||
|
||
* Original Area: PDX.SYSOP
|
||
* Original To : Phil McCloud (1:105/61)
|
||
|
||
The gospel says you should use either use ARC or no compression when
|
||
sending to strangers.
|
||
|
||
The reality is that you're more likely to run into someone who can't
|
||
unARC than someone who can't unZIP.
|
||
|
||
There is a networking precept that says, "Be liberal in what you
|
||
accept; be conservative in what you send."
|
||
|
||
As long as a sysop understands the landscape, there shouldn't be much
|
||
of a problem either way.
|
||
|
||
The biggest problem is passing around configuration files with ZIP
|
||
configured as the default. That breeds new sysops who can't unARC and
|
||
don't even know that they should be able to.
|
||
|
||
I recommend ARC as the default, but encourage everyone to explicitly
|
||
address the archiver issue at the time an echomail link is
|
||
established. Alternatively, if you have ZIP as your default, the first
|
||
interchange with a stranger should ask if it is OK.
|
||
|
||
And for gawds sake, don't get into a policy pissing contest over the
|
||
issue.
|
||
|
||
> I believe some form of .ZIP can be compiled for any platform,
|
||
> however none has ever changed the 'standard'.
|
||
|
||
ZIP is very difficult to implement on 8-bit, 64K RAM systems. The
|
||
lookup tables are too big to be kept in RAM. But 8-bit FidoNet systems
|
||
are becoming as rare as ivory billed woodpeckers.
|
||
|
||
No one has ever changed the 'standard' (which, btw, is durned
|
||
difficult to find in the FTSC documents), but almost everyone has
|
||
managed to minimize the effect. Other than the nodediff, ftsc and
|
||
policy documents, nothing of any size is sent ARCed. The amount of
|
||
FIDONEWS 14-23 Page 3 9 Jun 1997
|
||
|
||
|
||
bandwidth actually lost in ARC transfers is probably less than the
|
||
bandwidth that will be used in arguing about what the replacement
|
||
should be <g>.
|
||
|
||
A more cogent argument for the future is that zip/unzip are widely
|
||
available in the unix world, whereas arc is not. I have three unix
|
||
shell accounts. All have zip/unzip. None of them has arc. One has
|
||
lharc. Oh, I'm sure that I can find unix arc source somewhere and
|
||
compile it, but that's a lot of trouble if all I want to do is read
|
||
policy4.arc from ftp.paonline.com.
|
||
|
||
Incidentally, the "ARC" issue is a FidoNet (the network) issue, not a
|
||
FidoNet (technology) issue. FTN OtherNets could have a different
|
||
archiver policy.
|
||
|
||
Origin: EastSide Data Services (1:105/61)
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 4 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
ARTICLES
|
||
=================================================================
|
||
|
||
|
||
Fidonet Via Internet Hubs
|
||
|
||
Speed|Node# |Operator | Facilities | Basic Rate
|
||
-----+-----------+------------------+-------------------+-----------
|
||
T1 |1:270/101 |George Peace | FTP | $30mo.
|
||
T1 |1:396/1 |John Souvestre | FTP | $25mo.
|
||
T1 |1:12/12 |Ken Wilson | FTP | $24mo.
|
||
T1 |1:140/12 |Bob Seaborn | FTP, Transx | $5/$20
|
||
64k |1:124/7008 |Ben Hamilton | FTP, VFOS, Transx | $20mo.
|
||
56k |1:13/25 |Jim Balcom | FTP | $20mo.
|
||
33.6 |1:2604/104 |Jim Mclaughlin | FTP, VFOS, UUEMAIL| $1mo.
|
||
33.6 |1:2624/306 |D. Calafrancesco | VFOS | $15yr.
|
||
33.6 |1:281/169 |Brian Greenstreet | FTP | $2mo.
|
||
28.8 |1:330/204 |Patrick Rosenheim | Transx | $25yr.
|
||
|
||
--
|
||
compiled by Cindy Ingersoll, 1:2623/71, (609)814-1978,
|
||
fbn@cyberEnet.net Posted on the 1st of every month in FN_SYSOP,
|
||
R13SYSOP and Fidonews.
|
||
---
|
||
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
Some thoughts on a possible future direction for FidoNet:
|
||
by Ron Dwight
|
||
2:220/22
|
||
|
||
|
||
I have been giving consideration lately to a future direction in
|
||
which Fidonet could go and the following is offered for your
|
||
consideration:
|
||
|
||
.. Fidonet is a vastly different medium than the internet and should
|
||
not be swallowed by it. Fidonet should retain it's current character,
|
||
freedom and flexibility.
|
||
|
||
.. FidoNet nodes need the speed and reduced cost of internet access,
|
||
to communicate, this is why such things as Vmodem are being written.
|
||
|
||
.. The FidoNet nodelist appears to be the largest single obstacle
|
||
standing in the way of major changes to Fidonet methodology and either
|
||
the nodelist can be changed to accommodate the new methods or
|
||
alternative methods can be devised which make use of the current
|
||
nodelist.
|
||
|
||
What I am going to propose here, is a method of using the
|
||
current nodelist, with almost no changes and yet allow those nodes
|
||
which require access to internet transport, to obtain it quickly and
|
||
easily.
|
||
FIDONEWS 14-23 Page 5 9 Jun 1997
|
||
|
||
|
||
The basic concept revolves around the actual method of
|
||
operation of the internet itself to satisfy the needs of Fidonet
|
||
nodes. Whenever a connection is made, using a web browser, the
|
||
address which you are seeking, http://.... is sent to a Network Access
|
||
Point computer which translates that name into a TCP/IP address. This
|
||
is sent back to your browser which then uses it to reach the
|
||
destination computer on the internet.
|
||
|
||
What I propose for Fidonet, is something very similar which
|
||
will allow us to maintain the current nodelist format and content and
|
||
yet obtain full access to internet capable systems willing to
|
||
accept callers running Vmodem, Binkd or something similar..
|
||
|
||
1) A computer, or computers, serve as Fidonet Internet Access Points.
|
||
This would best be provided by a reliable system owned and
|
||
operated by a large corporation. To that end we would perhaps
|
||
need to obtain a sponsor, IBM would do nicely, so would US
|
||
Robotics, to provide access to an internet server to act as the
|
||
Fidonet Name Information Center. The load on this machine would
|
||
not be great, but a little software would need to be written for
|
||
it.
|
||
|
||
2) We then write a series of specifications for software which would
|
||
use this service to access other Fidonet nodes via the internet.
|
||
Part of this software specification would be something like:
|
||
|
||
.. All internet capable nodes would be flagged in the nodelist
|
||
with a single flag to indicate internet capability. The flag could
|
||
be, for example: INET or something similar and the flag would indicate
|
||
ONLY that the system was connected to the internet and was capable of
|
||
accepting FidoNet callers. No other information would be carried in
|
||
the nodelist and the nodelist entry could be used to indicate a normal
|
||
PSTN node as well as an internet capable one.
|
||
|
||
.. Mailers wishing to access an internet capable node must send a
|
||
message, containing ONLY the FidoNet node number
|
||
(Zone:Net/Node.point), over the internet to the FidoNet Name
|
||
Information Center. The reply from that server would be a message
|
||
containing the capabilities of that node which could then be used to
|
||
establish (or refuse) a session. The time overhead for such a service
|
||
would be a matter of milliseconds under normal conditions and would
|
||
not add significantly to the length of a session.
|
||
|
||
.. Mailer software, in order to reduce the number of transactions
|
||
to the Name Information Center, would check if the information is
|
||
locally available for the called number and use that if it was, say,
|
||
less than 7 days old. In other words if the system had been called
|
||
within the last 7 days, it is expected that the same session
|
||
parameters can be used without requesting them again from the Name
|
||
Information Center.
|
||
|
||
3) The information contained, and updated, on the Name Information
|
||
Center would be such things as:
|
||
|
||
.. Transport capability
|
||
.. Open hours
|
||
FIDONEWS 14-23 Page 6 9 Jun 1997
|
||
|
||
|
||
.. Protocol availability
|
||
|
||
In other words, all the stuff that folks are trying to cram
|
||
into the nodelist now. It could be in IEMSI format or similar.
|
||
|
||
A Fidonet node, ZC?/IC? or designated SysOp, would be
|
||
responsible for ensuring that the Name Information Center was properly
|
||
updated and functional.
|
||
|
||
This is only the basic outline of a concept which could be
|
||
used to enhance Fidonet capability. I believe the sponsorship would
|
||
be easy to obtain as the load on the Name Information Center machine
|
||
would be very light as long as the mailers obeyed reasonable rules as
|
||
to access. More important would be laying down the rules and
|
||
mechanisms for the software to take advantage of the capabilities
|
||
offered. Obviously a lot of technical detail needs to be worked out,
|
||
but I believe this could be used as a basis to move FidoNet into a
|
||
closer cooperation with the internet to our mutual advantage.
|
||
|
||
Someone is going to object that using a single Name
|
||
Information Center gives the entire system a central weakness. In
|
||
answer to that I would reply that:
|
||
|
||
.. Most of the entire WORLDWIDE internet services rely on only a few
|
||
such centers.
|
||
|
||
.. There is no reason why more than one machine could not be used and
|
||
that these could be indicated in the nodelist, perhaps as comment
|
||
lines, which mailer software can locate. Of course the more Name
|
||
Information Centers which are created, the more difficult it becomes
|
||
to keep them updated.
|
||
|
||
This mini-article is intended as a START. Andy, Jo, Arjen
|
||
and other developers, it's up to people like you to carry it further
|
||
and make it become a reality.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
SILLYSEASON Echo forming
|
||
Fredric L. Rice (frice@linkline.com)
|
||
The Skeptic Tank - 1:102/890.0
|
||
(818) 335-9601 24hrs N81
|
||
|
||
A new FidoNet echo -- tag named "SILLYSEASON" -- is forming and I'm
|
||
soliciting participation. The forum will discuss the "Millennium"
|
||
television series yet will also cover the broad spectrum of phenomena
|
||
from which the series draws upon for its subject matter.
|
||
|
||
The so-called "Millennium lunacy" phenomena has been commented upon
|
||
and researched in growing frequency this last decade -- and for
|
||
obvious reasons: The year 2,000 is only three years away. The
|
||
phenomena labels the cyclic rise and fall of destructive behavior and
|
||
beliefs plotted against the year number; yet it has nothing to do with
|
||
numerology. It's a matter of the human psychology behind how humans
|
||
contrive notions of significance when there are none. The phenomena
|
||
FIDONEWS 14-23 Page 7 9 Jun 1997
|
||
|
||
|
||
is also called the "silly season" and has been the subject of several
|
||
books and magazine articles.
|
||
|
||
Even though the contemporary calendar is a hodge podge of badly formed
|
||
months, weeks, and days, societies ever since the contemporary
|
||
calendar was widely adopted have placed great significance to the year
|
||
number whenever a new decade, century, or millennium comes along.
|
||
Though the year numbers aren't predicated upon any meaningful event or
|
||
indicate any meaningful demarcation, when a year number ends with a
|
||
zero, a large portion of the so-called "Westernized societies" feel
|
||
inclined to believe any damn silly thing and to "prophecy" much
|
||
disaster. Sadly, many such believers work hard to bring about their
|
||
images of doom and destruction in self-fulfilling prophecy. We
|
||
observe the results of such beliefs in our newspapers and on
|
||
television news reports.
|
||
|
||
For a link to the forum, contact me and I'll set it up. I suspect
|
||
that this will be a fairly low-volume forum except for times
|
||
immediately following some Millennium lunacy --such as repeats of the
|
||
"Heaven's Gate" mass suicides which are expected and the violent
|
||
activities of self-proclaimed "militias."
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
Why I bother
|
||
by Troy H. Cheek (1:362/708.4)
|
||
|
||
Some say Fidonet is dead. Obviously, since I'm writing this, and
|
||
you're reading it, and it went through Fidonet, then Fidonet isn't
|
||
dead. As long as Fidonet isn't dead, it will require people to run
|
||
BBS's, maintain nodelists, move messages, and moderate echoes. People
|
||
who catch a lot of flak and get very little praise, but people who are
|
||
required nonetheless.
|
||
|
||
I've moderated a few Fidonet echomail conferences over the years for
|
||
various reasons. The ones I moderate right now, however, have exactly
|
||
one thing in common: They were abandoned without notice by their
|
||
previous moderators.
|
||
|
||
I took over echoes which were "dead" or "dying". You want to hear
|
||
something funny? All of them are still active and still on the
|
||
backbone. Had I not taken over, it's possible some of these echoes
|
||
would no longer exist. But they would not have died because of lack
|
||
of interest of the end users; they would have died because nobody with
|
||
the proper knowledge bothered to update an echolist entry.
|
||
|
||
In my mind, there's no doubt that the eventual demise of Fidonet will
|
||
_not_ be because there are no longer any end users (lured away by the
|
||
promise of the Internet and other factors), but because the people who
|
||
do the vital jobs of Fidonet will give them up under the mistaken
|
||
impression that they are no longer needed.
|
||
|
||
Back in the early Fidonet days, the stand-alone BBS was declared dead.
|
||
After all, what single BBS could possibly compete with a nation-wide
|
||
network? And, hearing this solemn announcement that they were dead,
|
||
FIDONEWS 14-23 Page 8 9 Jun 1997
|
||
|
||
|
||
BBS's closed shop or joined Fidonet. A funny thing happened on the
|
||
way to the funeral, though. Some of the BBS's didn't listen and
|
||
continued to operate for as long as they still had callers. Some
|
||
operated for years. A few are _still_ operating to this day. And I've
|
||
been known to call a few every now and then.
|
||
|
||
Fidonet has been declared dead, killed by the Internet. In spite of
|
||
being dead, there are still a lot of people using it daily. So,
|
||
should we close up shop, forcing all these users to find other means
|
||
of communication? Or maybe, just maybe, should we keep the doors open
|
||
until the message packets actually stop coming in?
|
||
|
||
By all means hook into the Internet! Learn about the World Wide Web
|
||
and news services and electronic mail! Make new friends! Discover
|
||
new sources of knowledge! But since you can do all these things
|
||
without giving up Fidonet, why do so many people demand we do exactly
|
||
that? Are they afraid that if we don't take their word that Fidonet
|
||
is dead, instead of waiting for the mail packets to actually quit
|
||
coming in, that it just might take years or even decades before
|
||
Fidonet really ceases to exist?
|
||
|
||
As long as I still have access to Fidonet, and as long as there are
|
||
still echoes that interest me, I'll keep posting messages. And as
|
||
long some of these echoes need somebody to send in echolist entry
|
||
updates and perform the various administrivia functions, I'll still be
|
||
a moderator.
|
||
|
||
Troy H. Cheek, VID_GAME Echo Moderator (among others)
|
||
--
|
||
|Fidonet: Troy H. Cheek 1:362/708.4
|
||
|Internet: 362-708-4!Troy.H..Cheek@river.chattanooga.net
|
||
|
|
||
| Standard disclaimer: The views of this user are strictly his own.
|
||
| River Canyon Rd. BBS <=> Chattanooga OnLine! Gateway to the World.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 9 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
COLUMNS
|
||
=================================================================
|
||
|
||
|
||
Lock and Load: Guerilla Marketing for BBSes
|
||
(A Parenthetical Column) (Robert Parson) (1:3822/1)
|
||
|
||
Every month, a major owner shuts down operations. More operations are
|
||
rumored to be on the brink of going under. Everyone moans about the
|
||
state of the industry. "The end is near!"
|
||
|
||
Sounds familiar, doesn't it? Sure sounds like BBSes. But it isn't.
|
||
This is newspaper.
|
||
|
||
True, the total number of newspapers is down, as is total circulation.
|
||
But revenues are at an all time high. That's because they maximize
|
||
their audience. That's consultantspeak for targeting the readership.
|
||
Do you really think they created "Food" sections solely because it
|
||
would be a nice thing for the reader? No. They were created as a
|
||
showcase for grocery ads.
|
||
|
||
(Printed newspapers will never die, as some people have predicted, but
|
||
that's another column for another time)
|
||
|
||
BBSes can learn an important lesson here. This doesn't mean everyone
|
||
should go out and create big "Food" areas on their BBSes (although
|
||
we'll get to that shortly). However, you can focus some of your
|
||
marketing on specific areas of your BBS.
|
||
|
||
Many of you have already experienced success with Genealogy areas or
|
||
possibly even dedicating your BBS to Genealogical research. Some of
|
||
you look at gaming or chatting to draw in callers. But there are
|
||
plenty of other topics that are ripe for the pickin'.
|
||
|
||
Let's get back that "Food" section (this is going to be in a rather
|
||
circular fashion, so hang with me.)
|
||
|
||
Most BBSes have their messages bases numbered in some way or another.
|
||
In many cases they are also alphabetized. But for the most part, they
|
||
are not organized in any particular way.
|
||
|
||
Pull together a text file or a bulletin of some sort that puts the
|
||
message bases into topic order. Your callers can download this file
|
||
or bulletin, do a search for "FOOD" and there will be a list of the
|
||
message areas that are food-related. You could also include a few
|
||
lines that will point them to files available on your BBS that are
|
||
food-related (such as "Search the file section for 'meal' and/or
|
||
'recipe'!")
|
||
|
||
While this doesn't create quite the same atmosphere as a "Food"
|
||
section in the newspaper, it gives your callers a fairly easy to
|
||
use index of what to look for when they are setting up their mail
|
||
readers. (Sure, they can do a word search using the echo list you have
|
||
available now, but this way they'll just have to do one search instead
|
||
of a bunch.)
|
||
FIDONEWS 14-23 Page 10 9 Jun 1997
|
||
|
||
|
||
This will also give you a more specific idea of where everything is at
|
||
when you do any sort of outside promotions. For instance, you can
|
||
declare "Food Month" on your BBS. You can highlight the food message
|
||
bases and files in bulletins, local message areas, printed materials,
|
||
in a speech to the local culinary society, on a table at the county
|
||
fair, maybe even enter the local chili cookoff (using a recipe found
|
||
on your BBS, of course).
|
||
|
||
You can easily create and promote other "virtual sections" as well.
|
||
But as I keep saying, you have to do more than leave a message on
|
||
other BBSes saying "Come look at my Food Section. Think "out of the
|
||
box." That's Bobspeak for get "out of the house." At the very least,
|
||
you'll get a tan.
|
||
|
||
But wait! There's more!
|
||
|
||
Steve Prado, the Sysop of my Friendly Neighborhood BBS, Jackalope
|
||
Junction (1:3822/1) this past week was a guest on KWHN-AM Fort Smith,
|
||
AR talking about BBSes and International BBS Week.
|
||
|
||
The tone of the interview was positive. Steve was able to pass along
|
||
some good information, not just about his BBS but others in town and
|
||
even a bit about Fidonet. (By the way, he adapted the sample news
|
||
release I wrote a few weeks back and sent it to the radio station.
|
||
For full disclosure: I happen to work there and did help set up the
|
||
interview. But he did the hard work)
|
||
|
||
Good job, Steve!
|
||
|
||
|
||
Robert Parson
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 11 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
GETTING TECHNICAL
|
||
=================================================================
|
||
|
||
|
||
[This is part of the continuing FidoNet History series publishing the
|
||
FTSC Standards and Proposal documents. FSC-0079 {RTF} is skipped due
|
||
to its length {60K}. These docs have been reformatted to 70 columns
|
||
where required and any tables may be askew as a result. High ASCII
|
||
characters have been removed or replaced. Node numbers and telephone
|
||
numbers may be out of date.] Ed.
|
||
|
||
|
||
| Document: FSC-0080
|
||
| Version: 001
|
||
| Date: 01 Mar 1995
|
||
|
|
||
| Mikael Stoldal, 2:201/337
|
||
|
||
Describing FidoNet with a layered model
|
||
Mikael Stoldal, 2:201/337@FidoNet
|
||
|
||
Introduction
|
||
============
|
||
FTS-1 tries to describe FidoNet with the OSI model, but I don't think
|
||
that description is any good.
|
||
|
||
I have tried to make a better description of FidoNet with the OSI
|
||
model, but without success. I don't think that's possible.
|
||
|
||
Instead I made my own layered model, inspired from OSI. I use seven
|
||
layers with the same name as in OSI, but with Session and Transport
|
||
swapped.
|
||
|
||
Why this model?
|
||
===============
|
||
The main goal with this model is to make FidoNet more flexible make it
|
||
easier to change into newer and better protocols and data structures.
|
||
|
||
It should be possible to change one layer without affecting the
|
||
others.
|
||
|
||
Description of the layers
|
||
=========================
|
||
|
||
Physical layer
|
||
--------------
|
||
The telephone network (PSTN).
|
||
|
||
Link layer
|
||
----------
|
||
Modem with protocols like V.22 and V.32. This layer also include real-
|
||
time error correction (V.42, MNP4) and data compression (V.42bis,
|
||
MNP5).
|
||
|
||
Serial communication hardware (UART).
|
||
FIDONEWS 14-23 Page 12 9 Jun 1997
|
||
|
||
|
||
Network layer
|
||
-------------
|
||
Serial communications drivers (FOSSIL) and file transfer protocols
|
||
(Zmodem etc). Note that this layer can be divided into two sub-layers,
|
||
the file transfer protocol on top on the serial communication driver;
|
||
but upper layers can interact with the serial communication driver
|
||
directly.
|
||
|
||
Session layer
|
||
-------------
|
||
Session handshake protocols (YooHoo, EMSI) implemented in mailers.
|
||
This layer can reliably send files directly between two systems. It
|
||
doesn't perform any routing. It doesn't know about NetMail, EchoMail
|
||
etc.
|
||
|
||
The upper layers uses logical addresses (node numbers), this layer
|
||
performs address resolution (often by using a nodelist) to obtain the
|
||
physical address (telephone number) necessary to establish a
|
||
connection.
|
||
|
||
The upper layers can tell if a file should be sent immediately, when
|
||
appropriate or be placed on hold.
|
||
|
||
When files are received, this layer tells the upper layers.
|
||
|
||
Transport layer
|
||
---------------
|
||
This layer handles routing and transport of NetMail, EchoMail and file
|
||
attaches. The format of mailpackets is defined in this layer, except
|
||
the internal structure of a packed message.
|
||
|
||
A mail processor takes received NetMail and EchoMail and places it in
|
||
the local message base. It also looks there for messages to send.
|
||
|
||
Presentation layer
|
||
------------------
|
||
Here are the internal structure of a packed message defined.
|
||
|
||
In TYPE-2, this layer is totally mixed up with the Transport layer. In
|
||
new packet formats, they will hopefully be separated.
|
||
|
||
Application layer
|
||
-----------------
|
||
Here are the local message base (stored messages) defined.
|
||
|
||
Interaction between layers
|
||
==========================
|
||
|
||
Interaction between Session layer and Transport layer
|
||
-----------------------------------------------------
|
||
The Session and Transport layers does only interact between sessions,
|
||
not during them. The reason is that is should be possible to keep them
|
||
in different programs and implement it in single tasking operating
|
||
systems like MS-DOS. This doesn't prevent the Session and Transport
|
||
layers from running simultaneously in a multitasking system.
|
||
|
||
FIDONEWS 14-23 Page 13 9 Jun 1997
|
||
|
||
|
||
Comments
|
||
========
|
||
There is one problem with this model, how to describe the File Request
|
||
server function. Sending File Requests are no problems, that's just a
|
||
File Attach with a *.REQ file. The File Request server function have
|
||
to be implemented directly in the Session layer.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|
||
| Document: FSC-0081 Part A
|
||
| Version: 001
|
||
| Date: 01 Mar 1995
|
||
|
|
||
| Mikael Stoldal, 2:201/337
|
||
|
||
A TYPE-3 Packet proposal
|
||
Mikael Stoldal, 2:201/337@FidoNet
|
||
|
||
Status of this document
|
||
=======================
|
||
Copyright (C) 1992-1994 by Mikael Stoldal.
|
||
|
||
This document may be freely distributed and copied. The standard
|
||
described may be implemented by anybody. You may not distribute
|
||
modified versions of this document without written permission from the
|
||
author.
|
||
|
||
Fido and FidoNet are registered trademarks of Tom Jennings and Fido
|
||
Software.
|
||
|
||
Introduction
|
||
============
|
||
This is a proposal on a new packet format for use in FidoNet and other
|
||
FTNs (FTN = FidoNet Technology Network). This format can be used for
|
||
both NetMail (private point-to-point mail) and EchoMail (electronic
|
||
conferences).
|
||
|
||
This document defines the transport layer. It also includes a
|
||
presentation layer definition, but that can be changed without
|
||
affecting the transport layer. It also includes a application layer
|
||
(stored messages) definition,
|
||
but it's not mandatory.
|
||
|
||
This packet format conforms with FSC-39, rev 4. It has the PktType
|
||
field in the header at the same position as TYPE-2 and it contains a
|
||
capability word at the same position as TYPE-2+ (but no CW validation
|
||
copy). The packet header has also the same size as in TYPE-2. This
|
||
should make it easy to implement mail-processors supporting both TYPE-
|
||
2 and TYPE-3.
|
||
|
||
This packet format separates the header from the message data and the
|
||
header is extensible. A mail processor (the transport layer) doesn't
|
||
have to look at the message data.
|
||
|
||
This format eliminates most kludges currently used in TYPE-2.
|
||
FIDONEWS 14-23 Page 14 9 Jun 1997
|
||
|
||
|
||
This packet format allows multiple AreaTags in EchoMail.
|
||
|
||
This packet format is much more extensible than TYPE-2 and is probably
|
||
easier to implement.
|
||
|
||
This packet format allows up to 4 GigaBytes large messages and allows
|
||
binary data in messages, this makes it possible to implement
|
||
multimedia capabilities in the future.
|
||
|
||
Definitions
|
||
===========
|
||
|
||
Characters
|
||
----------
|
||
In this document, literal characters are written as two uppercase
|
||
hexadecimal (base 16, 0..9A..F) digits following by lowercase h, e.g.
|
||
"1Fh". The following abbreviations are used: "NUL" means 00h, "CR"
|
||
means 0Dh and "space" means 20h (the quotation marks are not
|
||
included).
|
||
|
||
Basic data types
|
||
----------------
|
||
Name Length Description
|
||
----------------------------------------------------------------------
|
||
ShortInt 1 8-bit unsigned integer.
|
||
Integer 2 16-bit unsigned integer, Intel 8086 byte order.
|
||
LongInt 4 32-bit unsigned integer, Intel 8086 byte order.
|
||
Byte 1 Field of 8 bits.
|
||
Word 2 Field of 16 bits, Intel 8086 byte order.
|
||
String[n] n Fixed length string of n bytes, NUL-padded.
|
||
String{n} max n Variable length string of max n bytes, NUL-
|
||
terminated.
|
||
n includes the terminating NUL.
|
||
String Variable length string, not terminated.
|
||
|
||
Address
|
||
-------
|
||
Field Type Description
|
||
Range
|
||
----------------------------------------------------------------------
|
||
Zone Integer Zone address.
|
||
1..65535
|
||
Net Integer Net address.
|
||
1..65535
|
||
Node Integer Node address.
|
||
0..65535
|
||
Point Integer Point address or zero if boss.
|
||
0..65535
|
||
|
||
FTN address in text format
|
||
--------------------------
|
||
An FTN address in text format must, unless otherwise stated, be in the
|
||
Zone:Net/Node[.Point] format, where .Point must be excluded if point
|
||
is zero, included otherwise.
|
||
|
||
TimeStamp
|
||
FIDONEWS 14-23 Page 15 9 Jun 1997
|
||
|
||
|
||
---------
|
||
A LongInt which contains the number of seconds since 00:00:00 1st
|
||
January 1970 UTC.
|
||
|
||
Organization
|
||
------------
|
||
An organization is a network such as FidoNet, VirNet, SigNet or
|
||
InterNet. It's sometimes called "domain", but I use the term
|
||
organization to avoid confusion with InterNet domains.
|
||
|
||
Reserved
|
||
--------
|
||
All fields marked "reserved for future extension" must be zeroed when
|
||
creating/writing and ignored when reading. They might be defined by
|
||
future revisions of this document.
|
||
|
||
Filenames
|
||
=========
|
||
It's recommended to use the naming scheme in FTS-LIST, for both
|
||
NetMail and EchoMail. There should be no problem with using the same
|
||
name space for TYPE-2 and TYPE-3 packets because the packet headers
|
||
are enough compatible.
|
||
|
||
Packet format
|
||
=============
|
||
Packet header
|
||
Zero or any number of data records.
|
||
00h 00h
|
||
|
||
The first two bytes of a data record is used to check for the end of a
|
||
packet. If both are zero, the end is reached (and the rest, if any,
|
||
should be ignored).
|
||
|
||
Packet header
|
||
=============
|
||
Field Type Description
|
||
----------------------------------------------------------------------
|
||
PktOrig Address The node who created this packet.
|
||
PktDest Address The node who should receive this packet.
|
||
SubType Integer Packet contents (see below).
|
||
PktType Integer Always 3.
|
||
PktDate TimeStamp When the packet was created.
|
||
ProdCode Integer FTSC Product Code.
|
||
Programs without Product Code must use
|
||
65535.
|
||
MajorVer ShortInt Major product version.
|
||
MinorVer ShortInt Minor product version.
|
||
Org String[16] Organization (see below).
|
||
CapWord Word Capability Word (see FSC-39).
|
||
Password String[8] Packet password.
|
||
ExtraInfo String[4] Reserved for future extension.
|
||
|
||
SubType
|
||
-------
|
||
Defines what the packet contains.
|
||
|
||
FIDONEWS 14-23 Page 16 9 Jun 1997
|
||
|
||
|
||
If this field is zero, data record is defined by the "Packed message"
|
||
part of this document. If this field is non-zero, data record is not
|
||
defined by this document.
|
||
|
||
This field can be used for two things. The first is to define new
|
||
packet types without having to use a new packet header. The second is
|
||
to allow distribution of other things than Email.
|
||
|
||
Organization
|
||
------------
|
||
This field contains the name of the organization the packet travels
|
||
in. This field applies to both PktOrig and PktDest since packets are
|
||
intra-organization.
|
||
|
||
Packed message
|
||
==============
|
||
The messages should be in chronological order in a packet.
|
||
|
||
Field Type Description
|
||
----------------------------------------------------------------------
|
||
HeadSize Integer Size of the message header (see below).
|
||
MsgFlags Word Message flags (see below).
|
||
MsgDate TimeStamp When the message was created.
|
||
MsgID LongInt Unique message identifier (see below).
|
||
ReplyID LongInt Reply linkage information (see below).
|
||
MsgLength LongInt Size of MsgData.
|
||
MsgOrig Address The node who created this message.
|
||
MsgDest Address The node who should receive this message.
|
||
CharSet ShortInt Character set (see below).
|
||
MsgType ShortInt Type of MsgData (see below).
|
||
Area String{255} AreaTag(s) (see below).
|
||
OrigAddr String{255} Origin address in text format (see
|
||
below).
|
||
ReplyAddr String{255} Reply linkage information (see below).
|
||
FromUser String{255} Who wrote this message?
|
||
ToUser String{255} To whom?
|
||
Subject String{255} Subject or one filename
|
||
(for file attaches and requests).
|
||
Path String{65535} Path (see below).
|
||
HeadExt String Header extension fields (see below).
|
||
MsgData String Message data (see below).
|
||
|
||
HeadSize
|
||
--------
|
||
The total size of the message header (all fields except MsgData).
|
||
Since this is an Integer, the header can't be bigger than 65535 bytes
|
||
and Path can never reach it's maximum length (how big it can be
|
||
depends on how big the rest of the header is).
|
||
|
||
Message flags
|
||
-------------
|
||
Bit Flag Meaning
|
||
----------------------------------------------------------------------
|
||
0 Pvt Private message.
|
||
1 File File attach message.
|
||
2 FileReq File request message.
|
||
FIDONEWS 14-23 Page 17 9 Jun 1997
|
||
|
||
|
||
3 UpdReq File update request message.
|
||
4 Direct Do not route this message.
|
||
5 Crash High priority mail.
|
||
6 Hold Hold for pickup.
|
||
7 IMM Immediate mail (highest priority).
|
||
8 RRQ Return receipt request (see below).
|
||
9 CRQ Confirm receipt request (see below).
|
||
10 IRR Is return receipt (see below).
|
||
11 Machine Message to a program (see below).
|
||
12 NoForCC CC in NetMail, NoForward in EchoMail (see below).
|
||
13 Permanent Message must not be purged by age (see below).
|
||
14 Foreign Message is from another organization.
|
||
15 reserved Reserved for future extension.
|
||
|
||
RRQ, CRQ and IRR
|
||
----------------
|
||
The RRQ and CRQ flags without IRR is used to ask the software at the
|
||
final destination to generate a receipt message to the sender. The
|
||
receipt to an RRQ flagged message must be generated when the message
|
||
is received, and this receipt must have the IRR and RRQ flags set. The
|
||
receipt to a CRQ flagged message must be generated when it has been
|
||
read by its addressee, and this receipt must have the IRR and CRQ
|
||
flags set.
|
||
|
||
A receipt must have the ReplyAddr and ReplyID fields set as if it was
|
||
a reply to the original message.
|
||
|
||
It's up to each network's policy to decide if all systems must support
|
||
this, no system are allowed to support this or all systems are allowed
|
||
but not forced to support this.
|
||
|
||
Machine
|
||
-------
|
||
The Machine flag indicates that this message is addressed to a program
|
||
and not a human. A mail processor should store such messages as
|
||
defined in the "Stored message" section later in this document so the
|
||
program doesn't have to support 4711 different message base formats.
|
||
The name of the program must be in the ToUser field.
|
||
|
||
Carbon Copy
|
||
-----------
|
||
The CC flag is used for sending a NetMail message to several nodes.
|
||
Which nodes is determined by the MsgDest field.
|
||
|
||
If the message is addressed to a Zone Coordinator, the message is
|
||
destined for all nodes in that zone. If the message is addressed to a
|
||
Region Coordinator, the message is destined for all nodes in that
|
||
region. If the message is addressed to a Net Coordinator, the message
|
||
is destined for all nodes in that net. If the message is addressed to
|
||
a HUB, the message is destined for all nodes under that HUB.
|
||
|
||
If the receiver of a CC message have other coordinators (or HUBs)
|
||
below, it must send the message to them as CC's too.
|
||
|
||
If the ToUser field is empty the message is considered to be addressed
|
||
to the SysOp and the name is taken from the nodelist (or set to
|
||
FIDONEWS 14-23 Page 18 9 Jun 1997
|
||
|
||
|
||
"SysOp"). This must be done by the system immediate before the
|
||
destination (usually the destination's HUB).
|
||
|
||
Permanent
|
||
---------
|
||
This flag indicates that the message must not be removed when old
|
||
messages is cleaned out.
|
||
|
||
A new message with this flag automatically erase an old message with
|
||
the same data in the Subject field. If you want to erase a permanent
|
||
message without replacing it with a new, then post an empty message
|
||
with the Permanent flag and the appropriate data in the Subject field.
|
||
|
||
This flag can only be used in EchoMail.
|
||
|
||
OrigAddr
|
||
--------
|
||
This field must contain the true origin address of the message in text
|
||
format followed by an "@" (40h) and the name of the originating
|
||
organization.
|
||
|
||
Message ID
|
||
----------
|
||
The origin address and MsgID fields are used as a unique message
|
||
identifier. How the MsgID field is generated is left to the
|
||
implementor, but it must be unique for each message generated on a
|
||
given node in at least three years. MsgID must normally not be zero,
|
||
zero is used to indicate lack of Message-ID. With this system these
|
||
two fields together is unique for every message, and can be used for
|
||
duplicate detection and other things.
|
||
|
||
Reply linkage information
|
||
-------------------------
|
||
In a reply the ReplyAddr and ReplyID fields must be identical to the
|
||
origin address, and MsgID fields in the replied message. A message
|
||
which is not a reply must have these fields empty. Use the ReplyAddr
|
||
field to check this.
|
||
|
||
Area
|
||
----
|
||
A list of one or more AreaTags in EchoMail, just a NUL in NetMail. If
|
||
the list contains more than one tag, they are separated by space. 00h
|
||
through 1Fh are not allowed in this field (except NUL as the
|
||
terminator).
|
||
|
||
Path
|
||
----
|
||
This field contains a series of addresses separated by space. The
|
||
first system must place its address in this field and every system
|
||
that routes the message must add its address to this field,
|
||
|
||
Note that the first address in this field and the address in the
|
||
MsgOrig field doesn't have to be the same.
|
||
|
||
The first address must be the origin address in this format:
|
||
zone:net/node.point@organization
|
||
FIDONEWS 14-23 Page 19 9 Jun 1997
|
||
|
||
|
||
In the other addresses organization, zone, net and node must be
|
||
omitted if same as the previous address.
|
||
|
||
The other addresses must be in one of these formats:
|
||
zone:net/node.point@organization
|
||
zone:net/node.point
|
||
net/node.point
|
||
node.point
|
||
.point
|
||
|
||
.point must be excluded if point is zero, except when .0 stands alone.
|
||
|
||
Example:
|
||
1:123/324@FidoNet sends a routed NetMail message to 2:224/546.5;
|
||
1:123/300, 1:123/0, 1:12/0, 1:1/2, 2:22/888, 2:22/0, 2:224/0,
|
||
2:224/546 and 2:224/546.3 routes the message (in that order). The path
|
||
field must in this case be "1:123/324@FidoNet 300 0 12/0 1/2 2:22/888
|
||
0 224/0 546 .3" when
|
||
2:224/546.5 receives the message. Note that the message is routed via
|
||
a point, that might not be so common but it's technically possible.
|
||
|
||
In EchoMail, the Path field can also contain addresses suffixed by an
|
||
exclamation mark ("!", 21h). This means that that node hasn't routed
|
||
the message, but the message has been sent to him. Similar to SEEN-
|
||
BY's in FTS-4. However, this should only be used when necessary.
|
||
|
||
Never send an EchoMail message to a node listed in the Path field;
|
||
regardless if the address is suffixed by an exclamation mark or not.
|
||
|
||
If the message originates in a non-FTN organization, the name of the
|
||
origin organization prefixed by an "@" (40h) must be placed before the
|
||
address of the gateway. In such cases there may also be some other FTN
|
||
addresses before the non-FTN organization name if the message have
|
||
travelled from an FTN, via a non-FTN and to a FTN again.
|
||
|
||
Example:
|
||
someone@one.two.three in InterNet sends a routed NetMail message to
|
||
1:222/345 in FidoNet via the gateway 1:222/111 and 1:222/300. The path
|
||
field must in this case be "@InterNet 1:222/111@FidoNet 300" when
|
||
2:222/345 receives the message.
|
||
|
||
If there's not enough room to update the Path field (add what you
|
||
should and have at least two bytes left), put a single "$" (24h) in it
|
||
instead (and a space between it and the last address).
|
||
|
||
This field has the same format as the PTH line specified in FSC-44
|
||
(except the "$"). Read FSC-44 for more information.
|
||
|
||
HeadExt
|
||
-------
|
||
This field contains zero or more NUL-terminated strings. The end of
|
||
this field can be determined by the HeadSize field, but there must be
|
||
a NUL after the last string anyway. If there are no strings here,
|
||
there must not be any NUL either.
|
||
|
||
Each string here is a header extension field. A header extension field
|
||
FIDONEWS 14-23 Page 20 9 Jun 1997
|
||
|
||
|
||
contains a keyword followed by a space and some data. A header
|
||
extension field can contain only a keyword with no data, in such case
|
||
a space must not be used either.
|
||
|
||
Inter-organization messages
|
||
---------------------------
|
||
To send a message to an other organization place the final address in
|
||
text format followed by an "@" (40h) and the name of the destination
|
||
organization in a header extension field with the keyword "DEST" and
|
||
address the message to a gateway.
|
||
|
||
If the message must travel over more than one organization-border, the
|
||
addresses to each gateway can be pointed out by header extension
|
||
fields with the keyword "ROUTE". ROUTE fields contains addresses in
|
||
the same format as DEST lines. The order of the ROUTE fields is
|
||
important and the DEST field must be after the ROUTE field(s). When
|
||
the gateway pointed by a ROUTE field processes the message it must
|
||
change "ROUTE" to "ROUTD".
|
||
|
||
Note: The gateway from your organization are pointed out by the
|
||
MsgDest field so there must not be a ROUTE field for that gateway.
|
||
|
||
Example:
|
||
You are 34:65/12@StrangeNet and want to send a message to
|
||
someone@one.two.three in InterNet. StrangeNet hasn't got any gateway
|
||
to InterNet, but FidoNet has gateways to both StrangeNet and InterNet.
|
||
In that case the message may have the following header extension
|
||
fields:
|
||
ROUTE 1:1/20@FidoNet
|
||
DEST someone@one.two.three@InterNet
|
||
|
||
Messages from other organizations (NetMail or EchoMail doesn't matter)
|
||
must have their origin addresses (including @organization as mentioned
|
||
before) stored in the OrigAddr field and the Foreign flag set. The
|
||
MsgOrig field in the header must contain the address of a
|
||
bidirectional gateway.
|
||
|
||
The MsgID field must be generated using the message-ID in the
|
||
originating organization, if that is possible. If the originating
|
||
network doesn't have any message-ID that can be used to create the
|
||
MsgID field, the MsgID field must be set to zero. If two identical
|
||
messages (with identical message-ID) enters an FTN organization at two
|
||
different gateways, they should get the same MsgID. The same counts
|
||
for ReplyID. ReplyAddr must also be transferred if present in the
|
||
original message.
|
||
|
||
If the other organization uses a message-ID format that can't be
|
||
transparently mapped to MsgID, a ORIGID header extension field is
|
||
created with a direct copy of the original message-ID (both address
|
||
and serial number). The same is done with reply-linkage information in
|
||
a ORIGREF header extension field. This information is used if the
|
||
message should be gated back to the original network.
|
||
Example with message from InterNet:
|
||
ORIGID <abcd43kxz@somewhere.org>
|
||
ORIGREF <bcdef43gkrt@elsewhere.org>
|
||
|
||
FIDONEWS 14-23 Page 21 9 Jun 1997
|
||
|
||
|
||
Message routing
|
||
---------------
|
||
The transport layer (including intermediate systems (systems handling
|
||
in-transit messages)) are not allowed to change anything in the
|
||
MsgDate, MsgID, ReplyID, MsgLength, CharSet, MsgType, OrigAddr,
|
||
ReplyAddr, FromUser, ToUser, Subject and MsgData fields. No flags may
|
||
be changed by the transport layer except the Foreign flag at gateways.
|
||
The only exception is if the message have to be converted to another
|
||
packet type.
|
||
|
||
An intermediate system must update the Path field, both in NetMail and
|
||
EchoMail.
|
||
|
||
In EchoMail, the Area field may be changed.
|
||
|
||
An intermediate system are allowed to add or change header extension
|
||
fields.
|
||
|
||
An intermediate system can add a header extension field with the
|
||
keyword "Via". The Via field contains information about the system and
|
||
when it processed the message. It's up to each network's policy to
|
||
decide if this is allowed in NetMail, EchoMail or both.
|
||
|
||
If the header is changed, the HeadSize field must be updated.
|
||
|
||
EchoMail
|
||
--------
|
||
This section lists the changes to FTS-4 needed to implement EchoMail
|
||
with this packet format.
|
||
|
||
SEEN-BY lines are not to be used. The Path field is used instead of
|
||
PATH lines. The Area field is used instead of the AREA line. The
|
||
MsgOrig and OrigAddr fields must contain the origin addresses of the
|
||
message. A unaddressed EchoMail message must have the ToUser field
|
||
empty, unless there is a good reason to put something there.
|
||
|
||
The MsgDest field must be used as in NetMail. If you receive a
|
||
EchoMail message not addressed to any of you addresses, you must
|
||
handle it as in-transit NetMail. This makes it possible to route
|
||
EchoMail through nodes not connected to the area. This can be
|
||
performed inter-organization as well.
|
||
|
||
Since the lack of complete SEEN-BY's, an EchoMail processor must use
|
||
the single-pass technique. That means that it must export a message to
|
||
all its downlinks at the same time as it tosses the message, before it
|
||
goes into the local message base (it doesn't even have to get there if
|
||
the area is pass-through). With this technique the tosser can do what
|
||
ever it wants with the message before it stores it in the local
|
||
message base since the message will never get out of it again (except
|
||
when a rescan function is invoked, but the requesting system will have
|
||
to stand that).
|
||
|
||
A system which receives an EchoMail message with the NoForward flag
|
||
set must not export that message. This flag is indented for EchoMail
|
||
processors with a rescan function, all rescanned messages must have
|
||
the NoForward flag set.
|
||
FIDONEWS 14-23 Page 22 9 Jun 1997
|
||
|
||
|
||
The tear and origin lines have no technical meaning (the origin
|
||
address is stored elsewhere) so no program is forced to create them.
|
||
Additionally, a program must not require them.
|
||
|
||
To distinguish EchoMail from NetMail, check the Area field. NetMail
|
||
messages have empty Area fields.
|
||
|
||
Cross-posting a message in several areas is preformed by storing
|
||
multiple AreaTags in the Area field. If some of your downlinks don't
|
||
have all the areas listed in the Area field then you must remove the
|
||
AreaTags for the areas they don't have. All copies must still have the
|
||
same MsgID. If you receive several messages with the same MsgID but
|
||
different Area then you must join them into a single message and put
|
||
all different AreaTags in the Area field (but not the same twice).
|
||
Compare all fields in the header up to and including Subject (except
|
||
Area) and not only MsgID.
|
||
|
||
When preforming dupchecking with MsgID, compare all fields in the
|
||
header up to and including Subject and not only MsgID.
|
||
|
||
CharSet
|
||
-------
|
||
|
||
Value Character set
|
||
----------------------------------------------------------------------
|
||
1..99 ISO 8859 (8 bit)
|
||
100 ISO 10646 16 bit (Unicode)
|
||
101..149 Reserved for other 16 bit character sets
|
||
150 ISO 10646 32 bit
|
||
151 PC8-437 (The Original)
|
||
152 PC8-850 (Multilingual)
|
||
153 PC8-852 (Slavic)
|
||
154 PC8-860 (Portuguese)
|
||
155 PC8-863 (Canadian-French)
|
||
156 PC8-865 (Nordic)
|
||
157..199 Reserved for other 8 bit character sets
|
||
200..255 reserved
|
||
|
||
PC8 means IBM's codepage (8 bit).
|
||
|
||
CharSet=1 means ISO 8859-1 (Latin-1), CharSet=2 means ISO 8859-2 and
|
||
so on.
|
||
|
||
CharSet concerns FromUser, ToUser and Subject. It may also concern
|
||
MsgData.
|
||
|
||
Combined characters are built by 02h followed by a modifier and the
|
||
base character. If you can't display the combined character, just
|
||
ignore the modifier and display the base character unmodified. A
|
||
combined character contains three bytes and are counted as three
|
||
bytes. See FSC-51 for more information on this. There are a few things
|
||
in FSC-51 that doesn't apply to this format: this method is allowed on
|
||
all 8 bit character sets, not only Latin-1, and the byte values 80h
|
||
through 9Fh are allowed. This can only be used for 8 bit character
|
||
sets. Combined character can be used in FromUser, ToUser and Subject,
|
||
it may also be allowed in MsgData.
|
||
FIDONEWS 14-23 Page 23 9 Jun 1997
|
||
|
||
|
||
MsgLength, MsgType and MsgData
|
||
------------------------------
|
||
If the MsgData field contains nothing (MsgLength is zero), it's an
|
||
empty message. An empty message must be forwarded and routed as any
|
||
other message. An empty message must not be stored in the local
|
||
message base (but read about the Permanent flag).
|
||
|
||
If MsgType is zero, MsgData is defined by the "Message text" part of
|
||
this document.
|
||
|
||
If MsgType is non-zero, the MsgData field is not defined by this
|
||
document.
|
||
|
||
Message text
|
||
============
|
||
This part defines the presentation layer.
|
||
|
||
The CharSet field in the header concerns the message text except
|
||
binary extension fields. Combined characters can be used in the
|
||
message text except in binary extension fields.
|
||
|
||
If a 16 or 32 bit character set is used all characters are two or four
|
||
bytes so all control codes must be prefixed by 00h or 00h 00h 00h. The
|
||
bytes alone can be in printable character. The length of binary
|
||
extension fields is still counted in bytes.
|
||
|
||
All 256 byte values (including NUL) are accepted in the message text.
|
||
00h through 1Fh are control codes and must not be used to represent
|
||
printable characters.
|
||
|
||
A paragraph (also called "physical line") is ended with CR.
|
||
|
||
8Dh (sometimes called "Soft CR") must not be used as a line separator
|
||
since it represents a printable character in some character sets.
|
||
|
||
01h first at a physical line (i.e. the first character of the message
|
||
text or the character immediately after a CR) means that this line is
|
||
a extension line. See below for more information.
|
||
|
||
00h first at a physical line (except in another binary extension
|
||
field) indicates the start of an long binary extension field. 00h is
|
||
followed by a LongInt and up to almost 4 GigaBytes of binary data. A
|
||
binary extension field is not terminated in any way, it's length is
|
||
stored in the LongInt (the 00h and the LongInt itself is not included
|
||
in the length).
|
||
|
||
15h first at a physical line (except in another binary extension
|
||
field) indicates the start of an short binary extension field. 15h is
|
||
followed by a ShortInt and up to 255 bytes of binary data. A binary
|
||
extension field is not terminated in any way, it's length is stored in
|
||
the ShortInt (the 15h and the Integer itself is not included in the
|
||
length).
|
||
|
||
Attributes:
|
||
03h = Turn off all attributes
|
||
04h = Bold
|
||
FIDONEWS 14-23 Page 24 9 Jun 1997
|
||
|
||
|
||
05h = Italic
|
||
06h = Underline
|
||
17h = All caps (lower case letters as small caps)
|
||
19h = Subscript
|
||
1Ah = Superscript
|
||
1Ch = Blinking
|
||
1Dh = Inverted
|
||
1Eh = Concealed
|
||
Subscript automatically turns off superscript and vice versa. All
|
||
other attributes can be used together. If an attribute already is on,
|
||
it's turned off by the same code again. If your system doesn't support
|
||
an attribute, just ignore it. CR turns off all attributes.
|
||
|
||
To quote a message begin a physical line with 1Fh followed by the
|
||
initials of the person you are quoting and another 1Fh. Use just two
|
||
1Fh if you don't want any initials. Successive quoting is marked with
|
||
more 1Fh:s immediate after the two first ones. A quote is ended with
|
||
CR. It's up to each implementor to decide how to display quoted text,
|
||
but it must be possible to distinguish it from normal text. It's
|
||
recommended to display it in another color if possible. You must
|
||
translate the quote to the same character set used in the rest of the
|
||
message.
|
||
|
||
The last paragraph of the message text must be terminated by a CR
|
||
(i.e. the last character of the message text must be a CR unless a
|
||
binary extension field is last).
|
||
|
||
Extension lines
|
||
---------------
|
||
An extension line contains a keyword followed by a space and some
|
||
data. A extension line can contain only a keyword with no data, in
|
||
such case a space must not be used either. An extension line is ended
|
||
like a paragraph.
|
||
|
||
Extension lines may not contain 00h through 1Fh. If you want binary
|
||
data, use a binary extension field instead.
|
||
|
||
Extension lines are control information any should not be displayed to
|
||
the user. If you want "hidden lines", then use the Concealed attribute
|
||
rather than an extension line.
|
||
|
||
Information that is relevant for the transport layer must be placed in
|
||
a header extension field rather than in an extension line.
|
||
|
||
Extension lines can be useful for describing a binary extension field.
|
||
|
||
Currently defined extension lines
|
||
---------------------------------
|
||
A extension line with the keyword FILE is used for sending files
|
||
embedded in the message text. The keyword is followed by a eight digit
|
||
uppercase hexadecimal number containing a TimeStamp for the file, a
|
||
space and the filename. The filename can contain all chars valid for
|
||
extension lines (including space) and must be at least 1 char and at
|
||
most 255 chars. The file is stored in a binary extension field
|
||
immediate after the FILE line. Examples:
|
||
FILE AB34F657 FILE.EXT
|
||
FIDONEWS 14-23 Page 25 9 Jun 1997
|
||
|
||
|
||
FILE 1234ABCD This is a filename
|
||
|
||
Stored message
|
||
==============
|
||
This is a description of the application layer, the local message
|
||
base.
|
||
|
||
It is recommended to use this format to store NetMail messages
|
||
locally. It can also be used for EchoMail, but that's not necessary.
|
||
|
||
Each message is stored as a single file which must have a hexadecimal
|
||
number from 00000001 to FFFFFFFF as the base name and the extension
|
||
MS3 (to distinguish from TYPE-2 stored messages).
|
||
|
||
Messages can be stored in two ways. Either the same way as TYPE-2 with
|
||
one directory for each area (including NetMail), in that case the Area
|
||
field must be empty in all messages. Or all messages in the same
|
||
directory with the area field used to indicate what/which area the
|
||
message belongs to (or empty to indicate NetMail). The second format
|
||
is useful if you normally store EchoMail in an other format and only
|
||
use this format for messages with the Machine flag.
|
||
|
||
Field Type Description
|
||
----------------------------------------------------------------------
|
||
SRdate TimeStamp When the message was sent or received
|
||
(see below).
|
||
ReplyTo LongInt Message which this replies (see below).
|
||
Reply1st LongInt First reply to this message (see below).
|
||
ReplyNext LongInt Next reply to this message (see below).
|
||
LocalFlags Word Local flags (see below).
|
||
Cost Integer Cost of sending in the lowest currency
|
||
unit.
|
||
HeadSize Integer Size of the message header (see below).
|
||
MsgFlags Word Same as packed message.
|
||
MsgDate TimeStamp Same as packed message.
|
||
MsgID LongInt Same as packed message.
|
||
ReplyID LongInt Same as packed message.
|
||
MsgLength LongInt Same as packed message.
|
||
MsgOrig Address Same as packed message.
|
||
MsgDest Address Same as packed message.
|
||
CharSet ShortInt Same as packed message.
|
||
MsgType ShortInt Same as packed message.
|
||
Area String{255} AreaTag(s) (see above).
|
||
OrigAddr String{255} Same as packed message.
|
||
ReplyAddr String{255} Same as packed message.
|
||
FromUser String{255} Same as packed message.
|
||
ToUser String{255} Same as packed message.
|
||
Subject String{255} Same as packed message.
|
||
Path String{65535} Path (see below).
|
||
HeadExt String Same as packed message.
|
||
MsgData String Same as packed message.
|
||
|
||
HeadSize
|
||
--------
|
||
The total size of the message header (all fields except MsgData).
|
||
Since this is an Integer, the header can't be bigger than 65535 bytes
|
||
FIDONEWS 14-23 Page 26 9 Jun 1997
|
||
|
||
|
||
and Path can never reach it's maximum length (how big it can be
|
||
depends on how big the rest of the header is).
|
||
|
||
Please note that this won't contain the same value when the same
|
||
message is placed in a packet because SRdate, LocalFlags, ReplyTo,
|
||
Areply and Cost isn't included then and Area might not have the same
|
||
length.
|
||
|
||
Local flags
|
||
-----------
|
||
Bit Flag Meaning
|
||
----------------------------------------------------------------------
|
||
0 Local Message is created locally.
|
||
1 InTransit Message is not destined for this system.
|
||
2 Orphan Unknown destination.
|
||
3 KillSent Remove message after it has been sent.
|
||
4 DelSent Delete attached file(s) after they have been sent.
|
||
5 TruncSent Truncate attached file(s) after they have been
|
||
sent.
|
||
6 Sent Message has been sent.
|
||
7 Read Message has been read by the SysOp.
|
||
8 Rcvd Message has been read by its addressee.
|
||
9 Lock Lock the message for further access.
|
||
10 DontSend Do not send the actual message but send attached
|
||
files, make file requests and poll the destination
|
||
if necessary.
|
||
11 unused Reserved for future extension.
|
||
12 unused Reserved for future extension.
|
||
13 unused Reserved for future extension.
|
||
14 unused Reserved for future extension.
|
||
15 unused Reserved for future extension.
|
||
|
||
Note that "sent" also can mean "picked up".
|
||
|
||
SRdate
|
||
------
|
||
The meaning of this field is determined by the Local and Sent flags.
|
||
Local but not Sent: Meaningless, must be zero.
|
||
Local and Sent: When the message was sent or picked up.
|
||
Not Local: When the message arrived to this system.
|
||
|
||
Reply linking
|
||
-------------
|
||
The ReplyTo field points at the message which the current message
|
||
replies. The Reply1st field points at the first reply to the current
|
||
message (the reply with lowest number); a messages with no replies
|
||
must have this field set to zero. The ReplyNext field points at the
|
||
next reply the same message as the current message; this field must be
|
||
zero if there are no more replies to the message the current message.
|
||
A message which is no reply must have the ReplyTo and ReplyNext fields
|
||
set to zero.
|
||
|
||
With this system there is possible to keep track of an unlimited
|
||
number of replies to any message.
|
||
|
||
Path
|
||
FIDONEWS 14-23 Page 27 9 Jun 1997
|
||
|
||
|
||
----
|
||
If the local flag is set, this field must be empty. It's the mail
|
||
processors responsibility to insert the address here when placing the
|
||
message in a packet.
|
||
|
||
When the mail processor tosses an incoming message, it must copy the
|
||
Path field from the packet.
|
||
|
||
Control file
|
||
------------
|
||
In each message directory (both EchoMail and NetMail) there must be a
|
||
file named LASTREAD. When an area is renumbered, this file must be
|
||
updated.
|
||
|
||
Field Type Description
|
||
----------------------------------------------------------------------
|
||
LastRead LongInt The last message read.
|
||
HighRead LongInt The highest message read.
|
||
HighWater LongInt High-water mark (only used with EchoMail).
|
||
This field is used by the EchoMail
|
||
processor to store the number of the last
|
||
scanned message.
|
||
|
||
Notes
|
||
=====
|
||
If you are implementing this and something confuses you, ask someone
|
||
who knows. Please don't guess how it should be.
|
||
|
||
Credits
|
||
=======
|
||
Thanks to Krister Hansson-Renuad, Johan Olofsson, Nils Hammar, Jonas
|
||
Hogstrom, Mats Gefvert and others who have helped me developing this.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 28 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
COORDINATORS CORNER
|
||
=================================================================
|
||
|
||
|
||
Nodelist-statistics as seen from Zone-2 for day 157
|
||
By Ward Dossche, 2:292/854
|
||
ZC/2
|
||
|
||
+----+------+------------+------------+------------+------------+--+
|
||
|Zone|Nl-129|Nodelist-136|Nodelist-143|Nodelist-150|Nodelist-157|%%|
|
||
+----+------+------------+------------+------------+------------+--+
|
||
| 1 | 8430| 8367 -63 | 8277 -90 | 8277 0 | 8182 -95 |31|
|
||
| 2 | 15904|15879 -25 |15855 -24 |15835 -20 |15774 -61 |60|
|
||
| 3 | 800| 800 0 | 761 -39 | 765 4 | 758 -7 | 3|
|
||
| 4 | 543| 543 0 | 543 0 | 543 0 | 519 -24 | 2|
|
||
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
|
||
| 6 | 1083| 1083 0 | 1077 -6 | 1078 1 | 1078 0 | 4|
|
||
+----+------+------------+------------+------------+------------+--+
|
||
| 26847|26759 -88 |26600 -159 |26585 -15 |26398 -187 |
|
||
+------+------------+------------+------------+------------+
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 29 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
NET HUMOR
|
||
=================================================================
|
||
|
||
|
||
Date: Sun, 25 May 1997 22:08:50 -0700
|
||
From: Shari <bluedawg@concentric.net>
|
||
Organization: OREGON - USA
|
||
To: webheads@softdisk.com
|
||
CC: Jayodee@aol.com
|
||
Subject: NEVERMORE
|
||
Sender: owner-webheads@softdisk.com
|
||
Reply-To: webheads@softdisk.com
|
||
|
||
Once upon a midnight dreary, fingers cramped and vision bleary,
|
||
System manuals piled high and wasted paper on the floor,
|
||
Longing for the warmth of bedsheets,
|
||
Still I sat there, doing spreadsheets:
|
||
Having reached the bottom line,
|
||
I took a floppy from the drawer.
|
||
Typing with a steady hand, I then invoked the SAVE command
|
||
But got instead a reprimand: it read "Abort, Retry, Ignore."
|
||
|
||
Was this some occult illusion? Some maniacal intrusion?
|
||
These were choices Solomon himself had never faced before.
|
||
Carefully, I weighed my options.
|
||
These three seemed to be the top ones.
|
||
Clearly, I must now adopt one:
|
||
Choose Abort, Retry, Ignore.
|
||
|
||
With my fingers pale and trembling,
|
||
Slowly toward the keyboard bending,
|
||
Longing for a happy ending, hoping all would be restored,
|
||
Praying for some guarantee
|
||
Finally I pressed a key --
|
||
But on the screen what did I see?
|
||
Again: "Abort, Retry, Ignore."
|
||
|
||
I tried to catch the chips off-guard --
|
||
I pressed again, but twice as hard.
|
||
Luck was just not in the cards.
|
||
I saw what I had seen before.
|
||
Now I typed in desperation
|
||
Trying random combinations
|
||
Still there came the incantation:
|
||
Choose: Abort, Retry, Ignore.
|
||
|
||
There I sat, distraught, exhausted, by my own machine
|
||
accosted Getting up I turned away and paced across the
|
||
office floor. And then I saw an awful sight:
|
||
A bold and blinding flash of light --
|
||
A lightning bolt had cut the night and shook me to my very core.
|
||
I saw the screen collapse and die
|
||
"Oh no -- my database", I cried
|
||
I thought I heard a voice reply,
|
||
"You'll see your data Nevermore."
|
||
FIDONEWS 14-23 Page 30 9 Jun 1997
|
||
|
||
|
||
To this day I do not know
|
||
The place to which lost data goes
|
||
I bet it goes to heaven where the angels have it stored.
|
||
But as for productivity, well
|
||
I fear that it goes straight to hell
|
||
And that's the tale I have to tell
|
||
Your choice: Abort, Retry, Ignore.
|
||
|
||
-30-
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 31 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
NOTICES
|
||
=================================================================
|
||
|
||
Future History
|
||
|
||
12 Jun 1997
|
||
Independence Day, Russia.
|
||
|
||
1 Jul 1997
|
||
Canada Day - Happy Birthday Canada.
|
||
|
||
9 Jul 1997
|
||
Independence Day, Argentina.
|
||
|
||
1 Aug 1997
|
||
International FidoNet PENPAL [Echo] meeting in Dijon, France
|
||
|
||
13 Oct 1997
|
||
Thanksgiving Day, Canada.
|
||
|
||
1 Dec 1997
|
||
World AIDS Day.
|
||
|
||
10 Dec 1997
|
||
Nobel Day, Sweden.
|
||
|
||
12 Jan 1998
|
||
HAL 9000 is one year old today.
|
||
|
||
22 May 1998
|
||
Expo '98 World Exposition in Lisbon (Portugal) opens.
|
||
|
||
1 Dec 1998
|
||
Fifteenth Anniversary of release of Fido version 1 by
|
||
Tom Jennings.
|
||
|
||
31 Dec 1999
|
||
Hogmanay, Scotland. The New Year that can't be missed.
|
||
|
||
1 Jan 2000
|
||
The 20th Century, C.E., is still taking place thru 31 Dec.
|
||
|
||
15 Sep 2000
|
||
Sydney (Australia) Summer Olympiad opens.
|
||
|
||
1 Jan 2001
|
||
This is the actual start of the new millennium, C.E.
|
||
|
||
-- If YOU have something which you would like to see in this
|
||
Future History, please send a note to the FidoNews Editor.
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 32 9 Jun 1997
|
||
|
||
|
||
=================================================================
|
||
FIDONET SOFTWARE LISTING
|
||
=================================================================
|
||
|
||
|
||
[The SOF Keeper is out of town this week. Here's last week's
|
||
edition.] Ed.
|
||
|
||
Latest Greatest Software Versions
|
||
by Peter E. Popovich, 1:363/264
|
||
|
||
A fairly quiet week around here. Things seems to be settling down into
|
||
some sense of order...
|
||
|
||
-=- 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
|
||
FIDONEWS 14-23 Page 33 9 Jun 1997
|
||
|
||
|
||
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
|
||
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
|
||
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
|
||
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
|
||
InfoMail/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.79 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
|
||
FIDONEWS 14-23 Page 34 9 Jun 1997
|
||
|
||
|
||
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
|
||
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
|
||
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
|
||
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
|
||
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
|
||
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
|
||
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
|
||
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
|
||
GoldED 2.50 O S Len Morgan 1:203/730 GEO
|
||
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
|
||
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
|
||
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
|
||
Maximus 3.01 B P Tech 1:249/106 MAXP
|
||
Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP
|
||
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE
|
||
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
|
||
Squish 1.11 T P Tech 1:249/106 SQUISHP
|
||
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
|
||
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
|
||
XRobot 3.01 O S JoHo 2:201/330 XROS2
|
||
|
||
Windows (16-bit apps):
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
|
||
FrontDoor APX 1.12 P S Mats Wallin 2:201/329 FDAPXW
|
||
|
||
Windows (32-bit apps):
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
Argus 95 2.62 M S Max Masyutin 2:469/77 ARGUS95
|
||
Argus NT 2.62 M S Max Masyutin 2:469/77 ARGUSNT
|
||
Argus NT/IP 2.62 M S Max Masyutin 2:469/77 ARGUSIP
|
||
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:
|
||
FIDONEWS 14-23 Page 35 9 Jun 1997
|
||
|
||
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
|
||
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
|
||
DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
|
||
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
|
||
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
|
||
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
|
||
|
||
TrapDoor 1.86.b2 M S Maximilian Hantsch
|
||
2:310/6 TRAPDOOR
|
||
TrapDoor 1.86.b2 M S Maximilian Hantsch
|
||
2:310/6 TRAPBETA
|
||
TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS
|
||
|
||
Atari:
|
||
Program Name Version F C Contact Name Node Magic Name
|
||
----------------------------------------------------------------------
|
||
ApplyList 1.00 N F Daniel Roesen 2:2432/1101 APLST100.LZH
|
||
BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY
|
||
BTNC 2.00 N G Daniel Roesen 2:2432/1101 BTNC
|
||
JetMail 0.99beta 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
|
||
|
||
Please send updates and suggestions to: Peter Popovich, 1:363/264
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
FIDONEWS 14-23 Page 36 9 Jun 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-23 Page 37 9 Jun 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
|
||
REC17: http://www.westsound.com/ptmudge/
|
||
|
||
Region 18: http://www.citicom.com/fido.html
|
||
|
||
Region 19: http://www.compconn.net
|
||
|
||
============
|
||
|
||
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/
|
||
|
||
FIDONEWS 14-23 Page 38 9 Jun 1997
|
||
|
||
|
||
Region 27: http://telematique.org/ft/r27.htm
|
||
|
||
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-23 Page 39 9 Jun 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-23 Page 40 9 Jun 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-23 Page 41 9 Jun 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-
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|