FidoNews · Vol 14, No 5 · 3 February 1997
F I D O N E W S -- Volume 14, Number 5 3 February 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. |
+----------------------------------------------------------------------+
WHERE WAS THAT GROUNDHOG?
Table of Contents
1. EDITORIAL ................................................ 1
Is it Phat or is it Jolly? ............................... 1
2. ARTICLES ................................................. 3
OpenDOS is Out! .......................................... 3
Fat-o-news? Call Jenny Craig! ............................ 6
3. GETTING TECHNICAL ........................................ 9
FSC-0028 - Note on Moving Files in FidoNet ............... 9
FSC-0030 - Message Identification & Reply ................ 21
FSC-0031 - Echomail dupe checking ........................ 25
FSC-0032 - Uniform Echomail Quoting ...................... 26
FSC-0033 - FidoNet Message ID Proposal ................... 27
4. COORDINATORS CORNER ...................................... 29
Nodelist-statistics as seen from Zone-2 for day 031 ...... 29
5. NET HUMOR ................................................ 30
An irreverent look at FidoLand hierarchy. :) ............ 30
What kind of Users do you have? .......................... 31
6. COMIX IN ASCII ........................................... 35
ASCII art goes hog wild? ................................. 35
7. NOTICES .................................................. 36
Future History ........................................... 36
8. FIDONET SOFTWARE LISTING ................................. 38
Latest Greatest Software Versions ........................ 38
9. FIDONEWS PUBLIC-KEY ...................................... 45
FidoNews PGP public-key listing .......................... 45
And more!
FIDONEWS 14-05 Page 1 3 Feb 1997
=================================================================
EDITORIAL
=================================================================
One of our readers takes the size of FidoNews to task in this Issue.
He doesn't say how long he's been around but only refers to the output
of Tees, the previous Editor as example of FidoNews size past.
Since Tees didn't bother to actively edit FidoNews many times, it's
hardly surprising many of his Issues were miniscule or Editorial only
phosphor padding.
FidoNews has been all sizes the past 13 years from 5K to 157K. Does it
really matter how big an Issue is uncompressed? Nobody has to read it;
part or all of it. Those who enjoy FidoNews for its potential [like
myself] make contributions to it to make it fun or useful. The History
and Standards series is part of what FidoNet is and many newbies and
Echomail weenies [those who only joined FidoNet for Echomail and don't
care or understand FidoNet's purpose] have never been exposed to this
material. It's FidoEducational. That's why it's here and why it's
going to keep going this way. There are FIVE FSCs in this Issue.
There are only sixty or so more to go. [grin]
The software list is also an important part of the FidoNews mission
and we all are indebted to Peter Popovich for the Herculean labors he
has made in organizing and maintaining that list. {Thanks, Peter!} In
these days of uncertified mailers and tossers giving headaches to the
entire Network from time to time, it's good to know what is available
and what does work. Even as many of the Echomail weenies flee FidoNet
for the apparently greener pastures of Internet mailing lists, there
are still BBS Sysops who need to know what is available for them if
they want to put up a system and become part of the World's First and
Largest Amateur BBS Network [and no, Bob, you don't have to run a BBS
to be a FidoNet Sysop]. It serves a purpose. It's in every Issue
because any one Issue may be the only one somebody sees.
There's an old saying that I don't agree with about doing and
teaching. It sez that those who can, do, and those who can't, teach.
That is incorrect. Those who can, do AND teach. Those who can't, get
jobs as critics. I'm doing and teaching. The lessons may be taken or
left at the reader's discretion. [grin]
Speaking of 'otherNets'[tm], it appears that the first major splinter
groups that broke from FidoNet to start true Utopian networks [cough]
have died from lack of interest or commitment. The first to go off was
AlterNet and it stopped publishing a nodelist as of Julian 010 this
year. You had to pay a tithe to belong to that one. It was the first
sourgrapesnet[r]. The second to splinter was EggNet. It didn't cost
anything but it was going to provide all the democratic ideals FidoNet
didn't. They even had a Supreme Court. It stopped publishing last year
as of Julian 138. Ten years ago, I told you so.
There never was any good reason for 'otherNets'[tm]. They were all
ego-driven fantasies of 'the way a network should be operated' when
FIDONEWS 14-05 Page 2 3 Feb 1997
FidoNet didn't move fast enough to suit them. Now, there are bunches
of them. Most of those are Echomail driven which was also unnecessary.
Several of those foolishly used Zone numbers under 10. That was very
short-sighted. FidoNet is bound to expand into those Zone numbers and
a lot of folks in 'otherNets'[tm] are going to start whining about
overlap and 2D addressing that can't tell one Zone's Nodes from
another. Boohoo. If they have any sense, they will shift up to Zone
numbers unlikely to be overrun by FidoNet Zones when expansion takes
place. With the demise of AlterNet's deliberate use of Zone 7, that
will be one less group of whiners to hear from. [grin]
Okay, that should generate some input. Those who complain about
FidoNews content should remember that THEY are dictating the content
with THEIR contributions. If they make none, their griping is
hollow. Those who can, DO. [chuckle]
C.B.
-----------------------------------------------------------------
FIDONEWS 14-05 Page 3 3 Feb 1997
=================================================================
ARTICLES
=================================================================
Cindy Ingersoll
@ 1:107/71
http://www.caldera.com/dos/dos.htm
The secret is out! I just happen to catch the above URL on the #linux
channel of Undernet IRC, which points to OpenDOS! Let's let it speak
for itself, here are some blurbs:
Caldera OpenDOS
Caldera OpenDOS 7.0 is based on the Novell DOS 7.0 DOS operating
system, and expands on some of Novell's DOS' strengths.
OpenDOS:
* A genuine DOS (100% compatible)
* A Rommable DOS - designed from the start to execute out of ROM
* Fully featured - A comprehensive DOS utility set
* Complete with extensions - including drivers for CD-ROMs etc.
* Genuine multi-tasking, with API for developers
* Includes 286 DPMS memory manager in addition to DPMI
* Comprehensive Networking Client solution, NetWare 3.X, 4.X and
Personal NetWare
* Includes PC-based Personal NetWare Server
* Includes defacto Disk compression - STAC
* Includes new NetWars 2.0 network game
Availability
For private/evaluation and education use Caldera OpenDOS is
available for download from Calderas Web site - to [1]Download
Click Here BUT read our license agreement before downloading.
Downloading constitutes acceptance of Calderas terms and
conditions. For commercial and OEM usage of Caldera OpenDOS contact
Caldera sales for more information.
Return to [2]OpenDOS Main Menu
References
1. http://www.caldera.com/dos/html/opendoslicense.htm
2. http://www.caldera.com/dos/index.html
.....................................................................
Caldera OpenDOS Programming Documentation
Caldera OpenDOS 7.0 is a complete DOS operating system.
FIDONEWS 14-05 Page 4 3 Feb 1997
Consequently you can use all the available DOS development tools
for the platform, allowing creation of software that will run on
Caldera OpenDOS, MS-DOS, and DR DOS versions. In addition Caldera
OpenDOS provides extensions that allow your application greater
flexibility.
Example additional features include:
* Multi-tasking
Caldera OpenDOS provides a full multi-tasking environment on
Pentium, 486, or 386-based harware. This is built into the memory
management extensions provided in the operating system, and is
accessible for standard un-aware applications when using the
Taskmanager (Taskmgr) utility. Programs however can have direct
access to create separate threads etc, via the extended Application
Programming Interface.
* DPMS
A memory manager that even works on 286-based Pcs, allowing device
drivers to reside outside of the regular DOS application area.
Drivers or Terminate and stay resident applications can thereby
avoid using valuable application memory,
* Romming tools
Caldera OpenDOS is the ideal embedded DOS system, designed for
straightforward out-of-the-box romming. Caldera will also be making
these tools available for prototyping embedded systems. If you wish
to use Caldera OpenDOS in your embedded application contact Caldera
Sales for more information
.....................................................................
Caldera Ships OpenDOS 7.01 for Free Internet Download
New DOS Version Provided Free for Non-commercial use. Caldera
OpenDOS makes a Solid, Low-Cost Solution for Running Windows 3.X
Applications and DOS Applications on Intel and Compatible-based
Workstations
Andover, UK and Provo Utah, USA
January 27, 1997
Caldera Inc. today shipped Caldera OpenDOS 7.01. OpenDOS is the
first Caldera Release of DOS, based on the Novell DOS 7 technology
acquired from Novell in 1996. The release is notable as it is the
first commercial DOS Operating System to be downloadable from the
Internet. OpenDOS is a true DOS operating system, supporting all
DOS applications including Microsoft Windows applications, and
networking systems including Novell NetWare, Windows for
Workgroups, and LANtastic.
FIDONEWS 14-05 Page 5 3 Feb 1997
Caldera OpenDOS comes complete with comprehensive networkability.
The inclusion of Novell Personal NetWare means that OpenDOS fulfils
all DOS workgroup requirements. End-users can easily network their
PCs. It even includes a brand-new version of the NetWars Arcade
game for single or multiuser use.
"OpenDOS underlines Calderas commitment to making essential
technology openly available as widely as possible" commented Jon
Williams, Director of Marketing of Caldera UK Ltd. "Non-commercial
users can download the latest DOS direct from our Web site.
Commercial users and OEMs can download the system for evaluation
and easily test-integrate into their solutions"
"Caldera OpenDOS 7.01 represents the first 're-generation' of DOS
Operating Systems, with its particular suitability to specialist
OEM applications" he continued (The DRDOS product line that OpenDOS
is derived from was the first purposely ROMmable DOS with industry
leading features like power management)
Brian Sparks, President and CEO Caldera Inc. said "Caldera is
working with the Internet community to make productive commercial
systems as open and available as possible. Dependable and reliable
commercial systems software such as OpenLinux and OpenDOS are
enabling users to make affordable and open choices on which to base
their business solutions."
Caldera uses its own technological and marketing resources to
leverage technologies including the Linux operating system created
by independent developers worldwide, and the OpenDOS product range.
Visit the Caldera web site at [2]http://www.caldera.com/. For
orders and information call (800) 850-7779 in the US or +1 801 269
7012 internationally.
Caldera is a registered trademark; and Caldera OpenLinux, Caldera
Network Desktop, Caldera Solutions CD and Caldera OpenDOS are
trademarks of Caldera Inc. NetWare and Personal NetWare are
registered trademarks of Novell Inc, Microsoft, Microsoft Windows,
and Microsoft Windows for Workgroups are trademarks or registered
trademarks of Microsoft Inc., UNIX is a registered trademark, in
the United States and other countries, licensed exclusively through
X/OPEN Company Limited. Netscape Communications, the Netscape
Communications logo, Netscape and Netscape Navigator are trademarks
of Netscape Communications Corporation. All other products,
services, companies and publications are trademarks or registered
trademarks of their respective owners.
Press Contacts:
Europe: Jon Williams - Director of Marketing Tel: +44 1488 71945 or
+44 385 317 477
Email: jonw@caldera.com
USA and Rest Of World: Lyle Ball - Marcoms Manager Tel +1 801 377
7687
FIDONEWS 14-05 Page 6 3 Feb 1997
Email: lyle@caldera.com
Contact: [3]info@caldera.com
References
1. http://www.caldera.com/dos/gifs/caldico.gif
2. http://www.caldera.com/
3. mailto:info@caldera.com
CiAo
---
-----------------------------------------------------------------
Fidonews, The "lard ass" of newsletters
by gary gilmore, 1:2410/400
First off, let me say, I take nothing away from Chris on running
Fidonews. I know it's not easy to produce, and I know he's trying
hard. I didn't see a mass rush of people volunteering to take it
over when Sylvia/Don gave it up.
OK, enough of the prefacing... time to get out the axe. <grin>
A few of the locals here were talking about Fidonews, and mentioning
how much larger it's gotten... unfortunately, that's mostly due to
a bunch of bloated junk that I'm willing to bet a majority doesn't
care about.
Just for the hell of it, I took this week's news and did a little
slash and burn to it.
FIDO1404.NWS 123592 01-27-97
That's the whole enchilada, all the poop included. Hefty, eh?
Wait.. there's more.
Lets remove the huge "how to get Fidonews from every place in
the world that we know of & Internet addresses of those that
can spell 'Fidonews'" listing, the "Jurassic park" section
(those FTSC documents that were originally written on stone tablets
by guys with modems that had tubes in them), and the oh-so-popular
"All the software in the world that has the word "mail" somewhere
in it's source code" segment, oh, I left in some "humor" <ahem>
that probably managed to offend most everyone who might be a
Fidonet sysop. (Not only was that emailed to almost the entire
world, it wasn't funny the first time I saw it.)
FIDO1404.NWS 27118 1-28-97
Whoops! What happened? Fidonews gets anorexic!
Now again, I don't -really- want to bash the Snooze.. honest.
I'm one of the few weirdos that actually bother reading it weekly.
FIDONEWS 14-05 Page 7 3 Feb 1997
(Of course, I also like to read the nodelist now and then, so
go figure...)
Honestly though.. do we really need reprints of FTSC docs? If
someone wants them, there's many, many places that offer them
up for reading. Fer chrissakes, there's even a listing of the
FTSC Internet site! (Though where's the FIDOnet listing for it?)
About the only people that DO want to read them are programmers,
or those preparing to "go after someone" over some arcane
specification. Do we really need them in Fidonews? I don't
think so. I'll betcha that most folks just PgDwn furiously past
them.
How about the giant PGP key? Have we -really- had a huge problem
in the past with "bogus" copies of Fidonews? Oh please... I have
to laugh just imagining some kiddies whipping out a Fidonews
proclaiming himself the new International Coordinator or writing
that Bruce Bodger and Bob Satti were seen on a plane with Bigfoot
and Elvis, and that John Souvestre has moved in with Steve Winter.
Bwaahahaha! :-)
(Hmmm... come to think of it, I think I'd -rather- read an issue
like that...)
Uhhh, I don't think there's much doubt on the "authenticity" of
the Fidonews I get, so I don't think we need to bloat with a
huge key in every issue. Hell, just use AV mode when you Zip it
up... that'll do nicely. (Oh, gahead... tell me how you can crack
a zip password... yep, I'll bet there's LOTS of people dying to do
that with Fidonews too! <laugh>)
Today in history... umm, do I -really- need to know what's happening
in 2000? Do I care? Should I jot it down in my Dayrunner?
OK, ok... whatever, but how about limiting it to 6mo in advance?
That's fair. Oh, and while we're at it, how about something like
"Zone 1 Mail hour changes for areas observing Daylight Savings
Time"... or something that REALLY would be helpful/matters to the
Fidonet sysop. Ain't this "FIDOnews"?
Peter E. Popovich.. bless him. Nice guy. But do we -really- need
him to go to all the trouble of submitting this encyclopedia-sized
listing each and every week? C'mon, some of this software hasn't
been updated in four -years-, so why not just let Peter send in one
listing every four -weeks-. I think that's fair, and gives Peter
some rest.
Jim Henry.. Hey! Here's a guy in FIDOnews talking about FIDOnet!
Imagine! Hurrah for Jim! I don't own a palmtop, but I might just
turn his echo for being one of the FEW things in this issue that is
FIDOnet related, not INTERnet.
Oh, Internet? Geez, hey, you forgot to list that our net's home page
also has a link to Fidonews. Oh, and Infoseek? I'll also find the
phrase "Fidonews" too, so let's not leave them out..
(Get the idea?) Auugh! Do I -have- to be told each and every place
FIDONEWS 14-05 Page 8 3 Feb 1997
in the galaxy that I can find Fidonews, or each place that has
another dreary all-black "Fidonet" web page? (Hmm, is that an
oxymoron? "Fidonet web page"?) Doesn't POLICY4 (you know, it relates
to FIDOnet) say that my NC has to give me Fidonews if I want it?
(Well, I -am- the NC here, but you know what I'm saying..) I notice
that of all the junk about where I can get Fidonews, I don't see one
mention of the -main- way to get it... the FIDONEWS file echo.
<knock knock> Hello? Anyone there?
Sheesh, do we have an Internet boner or what?
I think there's also something inherently wrong with FIDOnews in
HTML format. I dunno, but all this Internet all over FIDOnet makes
me itch. Umm, it happens to be that beloved Internet that's
shrinking our ranks, for the most part.
Is it too much to ask that FIDOnews do more coverage of FIDOnet, and
-not- the Internet? If it doesn't, lets just change the name of it
to INTERnews, and be done with it. After all, it -does- say "The
newsletter of the FidoNet community", doesn't it? <sigh>
Sure, many want to put Internet features in their BBS systems.
That's great. Keeping up on the bleeding edge of technology and all,
but where's the "how to gate newsgroups into your Fidonet BBS"
articles, or "How to gate email into your Fidonet BBS"... (note that
I say "into your Fidonet BBS" a lot there... that's because it's
what Fidonews should be concerned about.
What's the point of this behemoth article? Simple. A little less
INTERnet in my FIDOnews, please. A little less rehashing of old
crap, and ancient postings. (I'll also kill you if you post more
damned childlike ASCII "artwork"... Christ, that's so lame. My
cat's litterbox has better artwork in it.) A little less bloat and
needless information, and more FIDO-related meat in the S'nooze,
please.
If this means some issues will be slim, then so be it. No problem.
Donald Tees had some issues that were nothing more than an editorial,
but know what? They were -good- editorials, and worth reading.
At least he didn't include reprints of "My favorite nodediffs from
1988-1990" just to keep the size up. Let it be what it will be,
and let it be FIDOnet related first and foremost.
Again, I like Fidonews, and I hope no one will be offended by all
this rambling. If you are, well, go read "The history of nodelist
flags in Guam and Easter Island" for a while until you get over it.
(Or wait until it's reprinted in Fidonews. <laugh>)
As they say, "Flames>nul". :-)
-----------------------------------------------------------------
FIDONEWS 14-05 Page 9 3 Feb 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of a continuing series publishing FidoNet Standards and
Proposals submitted to the FTSC. It is also part of the FidoNet
History series. These have been reformatted to 70 columns as
required.] Ed.
FSC-0028
FwdSpec - A Collection of Notes on Moving Files in FidoNet
Preamble
Copyright 1988 Greylock Software, Inc.
POBox 730
Gt Barrington MA 01230
FidoNet>1:321/202.0
Synopsis
This started as a reverse-engineered technical description of the
core operations of Ron Bemis' Flea program, and an attempt to
formulate a new specification which is a more symmetric superset
of that functionality. Specifications for Mr. Bemis software is
available with that software, which is not freely distributed.
This document ONLY addresses the format of files transferred
between systems. It does not address configuration information,
which is really an implementation specific issue.
This is currently only a base for discussion, which should be
carried on in the SOFTWARE (SDS) and FTSC conferences.
Distribution
This document may be freely distributed, so long as it is
complete.
Comments should be directed to:
Barry Geller: 266/12
Tom Hendricks: 261/662
Harry Lee: 321/202
Rick Moore: 115/333
1 General
1.1 Existing Tools
1.1.1 FileFwd
FIDONEWS 14-05 Page 10 3 Feb 1997
FileFwd is a program by Joe Keenan whose primary purpose is to
move consistently named files on a routed, regular basis. It is
extremely useful for routing echomail packets through intermediate
nodes without unpacking and re-packing at each of the stations.
1.1.2 Flea
Flea is a program created by Ron Bemis which is used to broadcast
files in a manner similar to EchoMail. It is the primary tool
used by the FidoNet Software Distribution System.
Specifications for the Flea program are ostensibly available from
the author.
1.1.3 GlueFwd
GlueFwd is a distributed document control system from Greylock
Software that was considered and rejected for use by the FidoNet
Software Distribution System.
Unlike Flea and Tick, GlueFwd uses messages to contain the
associated routing information.
1.1.4 Tick
Tick is a program by Barry Geller, which performs approximately
the same functions as Flea, but uses a unique associated
information file format.
1.2 Basics
1.2.1 Associated Routing Information
There are a number of problems associated with file routing,
either point to point, or broadcast. The basic problem is how to
handle the associated routing information. The approaches involve
a spectrum ranging from information contained ONLY on the systems
handling the files to carrying the information WITH the files
being handled.
In addition, there is the choice of how this information is to be
conveyed. The choices range from associated files, to messages.
1.2.2 Name Collisions
1.2.3 Larva - starting the process
The "Larva" process is usually invoked by the user at the command
line. This is how a file is put in motion. It creates the
appropriate outbound .Fle files and the file attach information
required by the given mailer environment.
1.2.4 Flea - moving stuff along
The "Flea" process is the one that moves the files along. It does
the following:
FIDONEWS 14-05 Page 11 3 Feb 1997
Check the inbound for .Pre file, and process any that are
releasable as you would a normal .Fle file
Check the inbound for .Fle files, and process each as follows:
Parse the .Fle file, making sure its associate file exists, it
comes from a valid source, and that it is not a pre-release. If
any of those conditions are violated, the file is renamed either
to .Bad or .Pre.
If all is well, move the file to the appropriate path associated
with the area, and, if possible, update the FILES.BBS file.
Using a Larva-like process, send the file along to any nodes in
your echo list that have not seen the file.
A Flea process is generally run whenever inbound mail is received.
1.3 Nomenclature
1.3.1 [Required]
1.3.2 {Optional}
1.3.3 Address: {Domain>}{Zone:}Net/Node{.Point}
In the context of Flea 2.x, only Net/Node style addressing is
supported.
1.3.4 Dates
2 New Forwarding Format (TICK)
2.1 General Goals
2.1.1 Removing order dependency
The current structure of .Fle files is very order dependent. In
some cases, .Fle file lines have verbs, in others, they do not.
Presumably, Flea proper will have problems processing lines beyond
the description that are not in the proper order.
This weakness should be eliminated, essentially by insisting on a
verb per line, which makes possible free-form parsing, eliminating
order dependency. Within some groups of entries with the same
verb, order dependency may be required.
2.1.2 Limiting the type of information contained in a given datum
Flea 2.x very often carries different types of information on a
given line. While on the surface, this seems like an economical
way to do things, it can lead to complications later on.
Therefore, it is a general design goal to keep the type and use of
a given datum associated with a given verb very clean.
FIDONEWS 14-05 Page 12 3 Feb 1997
2.1.3 Removing Case Sensitivity
Flea is currently very case sensitive. Software should be soft.
An argument has been made that case sensitivity is a protection
against bad files being inserted into the system. If someone
wants to generate a trojan horse, they will need passwords (the
primary protection), and in all likelihood would use some sort of
Larval tool to generate it anyway. Case sensitivity makes it
slightly more difficult for a developer to "enter the fray".
2.1.4 Removing Inconsistent Colon Usage
Flea currently is haphazard in its usage of colons after verbs.
Colons should be made optional (or eliminated) on all verbs.
2.1.5 Optional Multiple DESC lines
Flea currently supports a single description line, which is
additionally position sensitive. By creating a DESC verb, the
position sensitivity can be eliminated, and multiple DESC lines
can optionally be supported.
At the current time, .Tic files use the DESC verb, but multiple
DESC lines are not permitted. Minimal compliance will be to
handle one; multiple lines will be addressed later.
2.1.6 App (Application) line support
In general, all mechanisms in FidoNet should allow for
growth/variation by other developers in a non-harmful manner.
In the case of Flea routing files, an APP verb with non-specific
data should be provided for. For example, let's assume that UPCL
supports some sort of a "return receipt" functionality - when a
file hits you, so long as it's posted to your area, and with the
sysop's consent (in the form of a configuration option), a message
is sent to the Origin node.
This might be done as follows:
APP GREYLOCK Return-Receipt
The "Greylock" sub-verb would keep APP conflicts from occurring.
Processors other than UPCL would pass the line through to any
rebroadcast .Tic files intact. (In fact, so would UPCL.)
App lines, taken as a group, are order dependent. A Tick
processor should output App lines created during forwarding in the
same order they read them, and if a Tick processor creates new App
lines, they should be added to the end of the existing App line
list.
Once the majority of processors support a given APP functionality,
it might be moved to the spec proper.
FIDONEWS 14-05 Page 13 3 Feb 1997
Indeed, any lines with "unrecognized verbs" should be passed
through intact, and in the order encountered.
2.1.7 Use of PATH construct rather than sby kludge
Seenby information is more easily digested by humans (and
programs) if it is sorted. Unfortunately, such sorting removes
the ability to use it for both seenby, and path information as it
is in Flea 2.2. In addition, the mechanism used by Flea 2.2
precludes tiny seenby's, or Zone gating.
Therefore, a PATH construct, much like an EchoMail PATH line
should be used, instead of the current mechanism. Once again,
order dependency should be discouraged. Within a group of path
lines, obviously, order is important.
2.1.8 Multiple Sby's per Sby line
The current seen-by construct, with one seenby per line, with the
word seen-by required on each line is hideously inefficient.
This should be changed to mimic echomail's seen-by handling, where
multiple seenby's are contained on each line, up to 78 or so
characters worth.
A possible reason to keep the seenby down to a single entry per
line is if information on how and when that node got the file is
to be included. While this might be worth considering, it will
add considerable weight to the .Fle file.
At the current time, Tick files are assumed to have one seen-by
per line.
2.1.9 Full (Optional) Domain, Zone, and Point support
In order to allow for the future growth of the network, and
interactions with other networks, addresses should be able to
contain a fully qualified FidoNet address:
Domain>Zone:Net/Node.Point.
Further, given that many authors' primary machines are points, the
result is as shown in the sample above: completely unknown
addresses appearing in the .Fle files.
Of course, these should not be required, but used as necessary.
At the current time, Domains are completely unsupported, and
should not be used.
2.1.10 Different extensions to avoid problems with Opus Style
Outbound
The extension .Fle was chosen because it leads to some expedient
side effects in the form of file truncation/elimination by Opus or
Binkley when the files reside in the outbound directory.
FIDONEWS 14-05 Page 14 3 Feb 1997
On the other hand, both Opus and Binkley explicitly specify their
outbound areas should be used ONLY for that. A number of
Binkley/Opus developers have expressed concern with this problem.
For this, and other reasons, .Fle files should be given a new
extension of some sort, one that is not closely related to the
commonly used routing/message file extensions. In addition,
rather than the three divergent extensions now used by Flea (.Fle,
.Bad, and .Pre), any and all extensions used by file routers based
on this technology should use extensions that are more closely
grouped.
As an ancillary note, the FTSC should consider a "File
Specification Pattern Registry". This would not be limited to
network tools, and it would not be an indication of ownership, it
would simply be a reference.
2.1.11 RFC-822 Format
It might make some sense to consider using an RFC-822 compatible
format for these files. In a future version of this document,
I'll detail this possibility.
It would also be nice from the point of view of implementing a
similar system on UseNet/Internet flavored systems.
2.1.12 Valid pairing of associated info file and file proper
We need a mechanism to insure that the primary file and the
associated information file are a valid pairing.
Consider the following scenario ...
System allows overwrites. A file and associated .Tic arrive.
They are, for whatever reason, not processed. A file by the same
name comes in. The pair is no longer valid, but given current
technology, it would be passed along.
2.2 Considerations
2.2.1 Up and downness
2.2.1.1 Single Uplink
2.2.2 Table driven duplicate elimination
2.2.3 Mapping between distribution and on-line organization
There is a problem in the current implementation in that the local
organization of a system tends to defeat the duplicate catching
aspects of the system.
I.E., the SDS currently sends out ALL FidoNet files in one
"channel". Many systems move files of this category or that to
unique directories.
FIDONEWS 14-05 Page 15 3 Feb 1997
2.2.4 Many features are intended for local optional implementation
Many of the features in this specification obviously affect how
individual sysops run their systems. As such, these features
should be optionally supported by each sysop, although the
information should be passed through the associated information
file regardless of whether or not they support the feature.
2.3 Schematic of .Tic file
Area{:} [AreaName]
{Release{:} [Time]}
{Replaces{:} [FileName]}
File{:} [FileName]
DESC{:} [Description]
{DESC{:} [Description]}
{Size{:} [Bytes]}
{Date{:} [FileDate]}
{CRC{:} [Calculated CRC-32 (in hex?)]}
Origin{:} [Address]
From{:} [Address] [Pwd]
{Created{:} [Program Banner]}
Seenby{:} [Address] {Address} ...
{Seenby{:} [Address] {Address} ...}
{APP{:} [Application Specific Information]}
Path{:} [Address] {Address} ...
{Path{:} [Address] {Address} ...}
Note this file is NOT order dependent. Some of the newer features
are more for discussion than anything else.
2.4 Nomenclature and Rules
2.4.1 Address Format: Zone:Net/Node{.Point}
2.4.2 Don't Barf on appended or unknown stuff
Lines that are unrecognizable (i.e., non-existent or non-supported
verbs) should be passed through untouched.
Lines that have additional data beyond the required data
(separated by whitespace) should not cause the system to fail,
although it is obviously difficult to pass this information
through.
2.4.3 One or zero items of a given type unless otherwise specified
2.4.4 Simple ASCII Alphabet
2.4.5 Unix Date Time Formats
All times are expressed as a long decimal in Unix format - the
number of seconds since 1970.
2.4.6 [Required Data]
FIDONEWS 14-05 Page 16 3 Feb 1997
2.4.7 {Optional Data}
2.5 Detail
2.5.1 App [Ref] {Info}
This is a "pass through" line to allow developers some room for
development without breaking other developer's work.
An APP line should have the following form:
APP [AppRef] {App Information}
or
APPLICATION [AppRef] {App Information}
Application lines should have their order preserved, and
applications adding lines should do so at the end of the existing
application list.
2.5.2 Area [Name]
Area names should probably be limited to 8 characters, with
alphabet restrictions, to simplify their implementation.
This is a mandatory line, and only one should exist in the file.
2.5.3 Author [Name]
This is an item for discussion.
2.5.4 CRC [Decimal CRC Value]
As .Fle files stand, it is possible to "slip something in" to the
pipe, particularly if .Fle files are processed only once in a
while as opposed to after each inbound call.
A number of the proposed (and optional) features here provide
safeguards against this. Specifically, computing the file CRC,
and preserving the original file date and size in the .Tic file.
This has some value as a verification tool, without the legal
encumbrances of PKSCrypt, etc.
This probably should be a CRC-32 value. This would also closely
follow some of the ideas that are being considered for echomail
processing.
This is currently a point for discussion. It probably should be a
mandatory field.
2.5.5 Created [Program Banner]
This should contain some program identification information of the
program that generated the attach information.
FIDONEWS 14-05 Page 17 3 Feb 1997
There might be some standard format for the first part of this
line, allowing for variant information after this.
This is an optional line.
2.5.6 Date [Date/Time of creation]
This is a check for valid file pairing between the associated
information file and the primary file. It is the file date stamp
of the primary file in Unix format.
2.5.7 Desc [File Description]
This is a description of the file. There is as yet unspecified
length restriction on this line.
At the current time, exactly one of these lines should appear in
the Tick file.
In the future, more than one line may be supported.
2.5.8 Dest [Address]
This is related to Route (qv)
2.5.9 Encrypted [PKS Key]
Read the section on "GARBLE", and change it as follows:
The file is initially encrypted using a PKS style encryption.
This would be the ONLY time the file is encrypted. The FTSC or
someone would have to collect a list of valid public keys of
authors (and probably eventually everyone). The file would then
be of "known-quality", or at least from a known source. The key
would be included in the .Tic file for ease of operation.
The ramifications of this are considerable. First off, PKSCrypt
is something the spook types in the world are bothered by.
Secondly, the source is not available, and the program does not
work on some machines (i.e., my 386.) Large keys would probably
have to be used so a large number of possible keys will exist,
which means considerable encryption and decryption processing
time. Finally, there is the question of a "Key registry", and how
you verify them.
I am not sure if this and Garbled are and/or or either/or.
2.5.10 File [FileName]
ONLY a filename (no path information) is contained on the FILE
line. No wildcards.
Exactly one of these lines must exist in a Tick file.
2.5.11 From [Address]
FIDONEWS 14-05 Page 18 3 Feb 1997
This is the address of the system sending the file on the current
leg.
2.5.12 Garbled
This is really just a thought for consideration than anything
else.
If this is present, the file referenced by the .Tic file is
assumed to be archived (we'd have to address the issue of
"deviant" archivers") by an agreed upon password between the
sender and the sendee.
The ramifications of this are considerable. It would mean that
individual archives would need to be created for any node so
protected, which would need to be deleted after sending. This
implies a considerable expenditure of time and resources to create
and store these archives.
2.5.13 Log [Comment]
This is another one for consideration. Any such lines would be
displayed on the console and/or the system log.
2.5.14 Magic [FileName]
This is food for thought.
In order to resolve and standardize version numbering in file
names, and magic file names, this might be used to distribute a
"magic file name" with a given file.
More than one of these lines might exist.
2.5.15 Origin [Address]
Where the file originally entered the system.
2.5.16 Path [Address] {Arrival}
Path lines are, among themselves, order dependent. However, they
need not be contiguous.
The current path specification allows for only one address per
path statement.
It might make sense to leave it this way, and add an "Arrival
time", which would be the time the file was processed.
I.E., the file would start out with the path for this node and the
next node with the time of creation. When it gets to the next
node, he changes his time to the time of processing, and puts out
a similar line for the node(s) he sends to.
2.5.17 Pw [Password]
FIDONEWS 14-05 Page 19 3 Feb 1997
This is the password between the sender and the sendee. This
password is not case sensitive.
Exactly one of these lines must exist in a Tick file.
It would be nice to have some method of password securing that did
not require the password to be exchanged in clear text.
2.5.18 Release [DateTime]
This is an optional line used to contain a Unix Date Time (seconds
since 1970) of the release of the file.
The handling of this is really murky as far as I can tell. A
brief digression into "political structures."
Let's consider the case of the SDS. In SDS, it has generally been
assumed that ONLY nodes that are a part of the SDS get their files
using Flea/Tick technology. However, whether it is aware of it or
not, this is not the case.
Here's what I think was intended: a file comes in with a
Pre-release time set. That is the time at which the file is moved
to the publicly available area. I am not sure whether it is
passed along the chain until that date, or if it is simply not to
be made "publicly available" until that date.
2.5.19 Replaces [FileName]
Only a filespec, no path information, is contained on this flavor
line.
A REPLACES line is used to optionally (at each given node) dispose
of older versions of the file being sent out. For instance,
Binkley releases are named:
BEXE_XXX.Arc
Assuming the next version of Binkley was 2.10, and assuming
REPLACES was enabled for the given area, the file named on the
REPLACES line would either be erased or moved if found.
I.E.:
FILE BEXE_210.Zoo
REPLACES BEXE_*.Arc
If these lines are encountered, and replacement is allowed, and
BEXE_200.Arc was found, it would, in some way, be removed from the
access directory.
Wildcards should be allowed, but should also be used with care.
Multiple REPLACES lines should be allowed.
2.5.20 Route [Address]
FIDONEWS 14-05 Page 20 3 Feb 1997
This is just thinking out loud.
These would have to be order dependent. They would be set up at
the point of creation, and there would have to be agreements all
along the way.
A political nightmare, but very useful in a corporate environment.
Collisions are a very real problem here.
2.5.21 RtRcpt {Address}
This is an item for discussion more than anything else. It would
be nice to have a means to find out how far your files have
moved. On the other hand, there are significant Policy type
considerations for such a functionality.
If the optional address is omitted, the ORIGIN is used.
2.5.22 Seenby [Address] {Arrival}
The current seenby specification allows for only one seenby per
line.
Seenby's are NOT order dependent. Seenby information is more
useful in "alphabetical" than encountered order, although it is
not a requirement.
2.5.23 Size [File Size in Bytes]
2.5.24 Source [Address]
Where the file actually came from.
This is a point for discussion. Let's consider the SDS again.
In theory, SDS is a controlled system. Files are only supposed to
enter it from a very limited subset of FidoNet. Currently, the
Origin is the location the file was "launched" from, a very
different thing than the author's address.
The Source address, if present, is the address of a primary system
used by the actual author.
For instance, consider Binkley. Binkley is supposed to enter the
system at the region 16 SDS node, although it is written by nodes
that do not participate in SDS.
2.5.25 Topo {Address}
This feature, if enabled, can be used to generate a topology
report for the area specified to the given node. If no node is
specified, the report should be sent to the Origin node.
2.5.26 Unidentified Verb Handling
FIDONEWS 14-05 Page 21 3 Feb 1997
Lines with unrecognized verbs should be passed through. Order is
a critical issue here. Unknown lines should be output in the same
order they were input.
2.6 Feature Table
Feature Status Count
Area [Name] 1
File [FileName] 1
Path [Address] >=1
Created [Text] 0-1
From [Address]
Origin [Address]
SeenBy [Address]
Path [Address]
Unidentified Verbs
2.7 TK123456.Tic (Updated and amended slightly from Barry's Orig)
Area TICKTEST
File TEST.TXT
Desc This is the file description Line!
Origin 1:266/1
From 1:266/13
Created by TICK v1.00 - Copyright (C) 1988 by I. Barry Geller
Release 59000000
Path 1:266/21
Path 1:266/13
Path 1:150/1
Seenby 1:266/21
Seenby 1:266/13
Seenby 1:150/1
Pw TESTPW
2.8 Notes
2.8.1 The primary file should be sent before the associated file
The actual file should be sent before the associated information
file. Consider this was not done in the following scenario:
Associated file sent
Primary file partially sent - session fails
System processes associated files, and fails to find last primary
During next session, primary is sent, with no associated
-30-
-----------------------------------------------------------------
FSC-0030
FIDONEWS 14-05 Page 22 3 Feb 1997
MESSAGE IDENTIFICATION AND REPLY FOR FIDONET
*DRAFT* FIDONET TECHNICAL COMMENT
Author: John Cowan
Fido: 1:107/711 (formerly 1:107/111)
Arpa: cowan@magpie.masa.com
Uucp: {backbones}!rutgers!hombre!magpie!cowan
Vox: +1-212-236-9153
ABSTRACT
The following document proposes a standard for message identification
and message reply identification for Fidonet and Fidonet-based
electronic mail system. It is based on the Usenet standard, RFC 850
and successors. The proposed standard will assist in duplicate-
message detection and will permit the support of true reply threading
across the network. The standard consists of mandatory and suggested
portions; however the term "mandatory" does not mean that any Fidonet
product must implement this standard --it simply means that those that
do claim to implement this standard must do so in the way described.
BACKGROUND
Currently, Fidonet messages are not uniquely identified. A variety of
schemes are in place to determine whether a message received by a
Fidonet node has been previously processed by the node, but all of
them involve a probabilistic component which may allow duplicates to
slip through. This can happen with particular ease where non-Fidonet
gateways are involved which may reformat a message.
In addition, Fidonet provides no clear and definite indication of
whether a message is a reply to some other message, and if so, which
message. This is a consequence of the previous problem -- there is no
way to refer to a message that is valid across all nodes. Programs
like TBBS, therefore, which do support the notion of detailed reply
threading (each reply refers to some definite "parent" message) have
to use a semi-guesswork algorithm which frequently leads to the wrong
answer -- the latest message with a common Subject header is taken to
be the parent, even when examination of the context by a human being
indicates that the message is in reply to some earlier message.
The Usenet network, which shares much of its problem domain with
Fidonet, solves these problems by tagging every outgoing message with
a unique Message ID string. Other messages can then refer to this
Message ID and provide an unambiguous indication of which message, or
messages, they are in reply to.
IFNA KLUDGE LINES "MESSAGE-ID" AND "IN-REPLY-TO"
Fidonet supports a general method for sending additional information
embedded in a message known as the "IFNA kludge line". This is a line
of text beginning with the ASCII SOH character. The characters
following SOH are a word indicating the type of kludge line, and the
remainder of the line contains information specific to that type.
This standard introduces two new types of kludge lines, the MESSAGE-ID
FIDONEWS 14-05 Page 23 3 Feb 1997
line and the IN-REPLY-TO line. These names, and the kludge line
formats, are taken directly from Usenet. MESSAGE-ID is used to tag an
outgoing message with a unique string, different from any other
message on the network. IN-REPLY-TO is used by threading message
processors to specify the Message ID of the "parent" of a reply
message. These kludge lines are generated and interpreted by message
editors; tosser/scanner and mailer products need only leave them
undisturbed. They are applicable to both regular network mail
and Echomail.
FORMAT OF A MESSAGE ID -- MANDATORY
This format is drawn directly from Usenet; it may seem a little
arcane, but is flexible enough to handle a large variety of needs.
Generally, a Message ID looks like this:
<unique-part@domain-name>
The <, @, and > characters are fixed, and are used to help in parsing
the Message ID. The "unique-part" may consist of any characters --
the only requirement is that it be different for every message
generated on a given node or point. Possible implementations of
"unique-part"s include a simple serial number, a date+time, or
something completely different.
The "domain-name" must be a valid Internet domain name. Luckily,
every Fidonet system has a valid domain name now! The format here is
as follows:
The domain name of the node a:bbb/ccc is
Fccc.Nbbb.Za.FIDONET.ORG
and the domain name of the point a:bbb/ccc.ddd is
Pddd.Fccc.Nbbb.Za.FIDONET.ORG
The periods, magic letters, and the magic name "FIDONET.ORG" make the
domain name unique in the world. Of course, Fidonet systems that
already have a different domain name (e.g. circle.UUCP) are free to
use that name instead.
A system which generates Message IDs must guarantee that no Message ID
will be reused for at least two years. This implies that if multiple
message editors exist on a system they must cooperate at least to the
extent of not using the same Message IDs for different messages. In
particular, a message editor that uses a simple serial number should
make provision for the user to set the starting serial number to a
value other than zero, so that different starting values can be used
by different products. Note that the numeric name of a .MSG file is
>not< suitable as a unique-part, because it is neither unique nor
permanent.
FORMAT OF A MESSAGE ID -- SUGGESTED
It is suggested, though not required, that the unique-part of all
Message IDs consist only of decimal digits, and not more than 9 of
these, so that the unique-part can be stored as a 32-bit signed
integer. A serial number scheme meets this standard, as does a Unix-
style timestamp (seconds since midnight Jan 1 1970, Universal Time).
There many other possible schemes.
CREATION OF THE IN-REPLY-TO LINE -- MANDATORY
FIDONEWS 14-05 Page 24 3 Feb 1997
The most important thing about the IN-REPLY-TO line is that the
Message ID specified by it should be the actual Message ID of the
message being replied to, and not a Message ID invented by the sender
of the reply. This implies that message editors which generate IN-
REPLY-TO lines should be able to store the Message IDs of all incoming
and locally generated messages for as long as the messages themselves
remain on-line. It is worth repeating, however, that there is nothing
mandatory about generating the IN-REPLY-TO line at all. A message
editor may generate both MESSAGE-ID and IN-REPLY-TO lines, only
MESSAGE-ID lines, or neither.
Due to problems with existing software, message editors should be
prepared to receive (and either discard or display uninterpreted) IN-
REPLY-TO lines which are >not< in standard format. Standard format
lines will have a < character just after the keyword and a > character
at the end of the line.
DUPLICATE MESSAGE ELIMINATION
Usenet makes use of a "history file" which maintains the Message IDs
of messages received in the last 15 days (this number is configurable
by the sysop). Fidonet has a similar scheme, but this is inherently
less reliable, depending as it does on the exact layout of each
message. With MESSAGE-ID kludge lines, dupe eliminators can take
advantage of them to help kill dupes once and for all, using existing
mechanisms as a backup when needed.
IMPLICATIONS FOR USENET GATEWAYS
Currently, Fidonet<->Usenet gateways generate Message IDs for messages
passing from Fidonet to Usenet, and discard them for messages passing
the other way. With this standard in place, such gateways should be
modified to watch for MESSAGE-ID and IN-REPLY-TO kludge lines and
translate them to Usenet "Message-ID:" and "In-Reply-To:" header
lines, and vice versa. This will improve the behavior of threading
systems like TBBS on the Fidonet side and 'notes' on the Usenet side.
Fidonet messages which don't have a MESSAGE-ID line will, of course,
need to have one generated when passing over to Usenet, as is now the
case.
IMPLEMENTATIONS
The Magpie tree-structured BBS is now being enhanced to provide
Fidonet access to its users. Magpie depends heavily on the notion of
parent messages; every message on a Magpie system (except one) has a
parent. Magpie/Fidonet systems will use the above technique to pass
the parent information they need transparently through the Fidonet, so
that incoming Fidonet messages can be connected at the correct place
in the Magpie tree. (A backup algorithm similar to TBBS's will be
used for Fidonet messages without parent information.)
We are publishing this information as a Fidonet technical comment in
hopes that other Fidonet products will eventually incorporate all or
part of this standard as well, and that it will eventually form part
of a Fidonet Technical Standard.
FIDONEWS 14-05 Page 25 3 Feb 1997
-30-
-----------------------------------------------------------------
FSC-0031 May 1, 1989
EchoMail ^aEID: Dup-Checking with Linked Replies
A Proposal To The FidoNet Technical Standards Committee
Currently, no universal methodology for implementing echomail
duplicate message checking exists. One thing is certain - they
will only increase in number as the shear volume of echomail is
increasing every day!
In order to catch the highest percentage of duplicates possible
it is desirable to utilize a system which actually tags each of
the messages themselves with a distinct messages identifier to
be used to check against an existing database of all previous
messages' identifiers. In practice, this is not possible, but
we can limit the number of previous identifiers kept so that
processing is quick but still almost certain to eliminate any
duplicate messages.
This also provides an easy method of linking replies to their
original message by appending the previous identifier. Using
a linked reply technique allows easy relinking of the messages
to the original message, assuming it still exists.
This proposed ^aEID: kludge line specifications are as follows:
1) A 16-bit CRC followed by a 32-bit DOS file date/time stamp.
2) The 16-bit CRC is calculated by first CRC'ing all but the
first 11 (static) characters of the origin line, followed
by the first two "words" of the from name, the first two
words of the to name, and the first 25 characters of the
subject line after stripping leading occurances of "Re: "
sequences.
Notes: You must always upper-case the to/from/subject fields,
as some current processors will change the case of that text.
Using only the first two words of the from and to names will
eliminate the potential problem when some processors add the
" of xxx/yyy" to the end. Stripping all leading occurances
of the "Re: " in the subject field is also done to eliminate
the possibility of changed subject lines not matching with
the original message, which is also the reason for limiting
the length of that field to the first 25 bytes (after taking
off all the "Re: " sequences), because adding the leading
"Re: " may force characters out (because they are beyond the
72-character field limit).
When you must add an EID line for a message which is not local,
you have to zero the seconds field before creating the 32-bit
FIDONEWS 14-05 Page 26 3 Feb 1997
time stamp - some processors eliminate this information! This
limitation can be overcome if most editors insert them at the
time they are written.
Automatic reply linking
========= ===== =======
When replying to a message with an ^aEID: line, extend the new
^aEID: with the ^aEID: fields of the original message. The new
line would look like this:
^aEID: xxxx yyyyzzzz uuuu vvvvwwww
Where 'uuuu vvvvwwww' is the Eid information of the original
message. Only one previous message's information is retained.
-30-
-----------------------------------------------------------------
FSC-0032 May 1, 1989
Uniform EchoMail Quoting Style
A Proposal To The FidoNet Technical Standards Committee
As more and more new software appears on the network, it has
become evident that we need a universal method for quoting text
of previous messages in replies.
Because of the way quoted text must appear, it is necessary to
format said text with "Hard" <CR> characters, in order to keep
the block from drifting should the new text itself be quoted.
The following method should allow current and future programs
to properly identify and handle previously quoted material.
Newly quoted text should be preceeded by the a single space,
a greater than symbol ('>') and another space.
Optionally a field of initials may appear in front of the
greater than symbol, like this: " MR> ". If you allow the
initials to be inserted, they should only be inserted into
lines which have not been previously quoted. (in other words,
don't add initials to anything already quoted)
Successive quotes of previously quoted material should only add
a single ">" in front of the existing text, which may eliminate
the leading blank space.
Blank lines in quotes should remain blank (no '>' or initials).
Kludge lines, including tear lines and origins lines are not
normally quoted, but when they are - they must never be quoted
exactly - this definitely causes problems with other software!
FIDONEWS 14-05 Page 27 3 Feb 1997
-30-
-----------------------------------------------------------------
FSC-0033
June 11, 1989
FidoNet Message ID Proposal
By Todd Kover
1:261/5016;1:261/1028
Since there are many proposals for Message-IDs, for dupe-checking,
and reply-linking, I figured, I may as well do my best to add
confusion to things, and come up with another one. :-) In my playing
around with different ideas, and such, I came out with the following
format:
^AFMSGID:DDDYYHHMMSSLLNNNNOOOOPPPP[ZZZZ][Domain]
^AFREPLY: < Repeat of what is above >
Here's a brief explanation of what each area is...
DDD: (01-366) The day of the year. (Julian calendar method).
YY: (0x00-0xFF) The year. Now, this only gives 255 year accuracy,
but, if the message has been in circulation that long, then it
deserves to be read again. :-)
HH: (00-23) Hour which the message was written
MM: (00-59) Minute which the message was written
SS: (00-59) Seconds which the message was written
LL: (0x01-0xFF) In reading NET_DEV, and FTSC, and all of the
debating over "What happens when someone enters a message at
the EXACT same time, on my multiline system?) Well, the best
way to avoid that, is to either A) Set the ID while packing
the message up, and only pack all the lines messages in, at
once, or, use this option, that sets the line number, of the
caller (0-0xFF).. I figure that there won't be more than 255
lines to a single node... I would opt for the former, but, I
put this in here, to shut everyone up. :-)
NNNN: (0x00-0xFFFF) The Net Number of the node, that this message
originates from.
OOOO: (0x00-0xFFFF) The Node Number of the node, that this message
originates from.
PPPP: (0x00-0xFFFF) The Point Number of the node, that this message
originates from.
FIDONEWS 14-05 Page 28 3 Feb 1997
------
Now for the Optional ones:
ZZZZ: Since there is a question as to weather or not Zones should be
implemented, and, some packages do not implement them, I
figured that this should be optional. If it is not there,
then a Domain address would be there, or, nothing at all.
Domain: This is for the people that use these (SEADogians, for one).
I am assuming that Domains are alphabetic characters, and no
numbers are there (Which is probobly stupid on my part), so
that software can distingish between Domains, and Zones.
------
The FREPLY: is just teh FMSGID of the message that the message is
replying too. That way, you can just compare.
In order to allow dupe checking, a system has to keep a backlog of all
of the message IDs for some period of time (say 2 weeks?) that pass
through the system, and has to compare a new one to the old ones. If
it matches, then the message is a dupe. This doesn't seem too
efficient, since there are alot of messages that pass through
something such as a backbone, but, I am sure there is some way to make
it fast, I just haven't put enough thought into it, yet).
------
One of the more nicer features about this, is that if the ID is not
there, then it can be calculated by examinining parts of the message,
and the header to get all of the information, and, it can be put in
there. Pretty simple, eh?
------
If you want to get in contact with me, to make contacts on this, you
can reach me at my private node, 1:261/5016, but, since I only poll
the Net-Coordinator once a week, or so, to pick up my NodeDiff, and
FidoNews, I will be a little slow in responding to it. You can reach
me pretty quickly on 1:261/1028, which is the only BBS that I
frequent, just about daily, and, if I don't, the sysop there will tell
me if there is anything waiting for me... Direct flames, and such
things to NIL:, thank you..
-30-
-----------------------------------------------------------------
FIDONEWS 14-05 Page 29 3 Feb 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 031
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-003|Nodelist-010|Nodelist-017|Nodelist-024|Nodelist-031|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 10370|10370 0 |10177 -193 |10063 -114 | 9877 -186 |35|
| 2 | 16056|15979 -77 |15936 -43 |15938 2 |16078 140 |56|
| 3 | 869| 868 -1 | 865 -3 | 863 -2 | 863 0 | 3|
| 4 | 552| 554 2 | 553 -1 | 558 5 | 550 -8 | 2|
| 5 | 93| 93 0 | 93 0 | 93 0 | 87 -6 | 0|
| 6 | 1073| 1073 0 | 1073 0 | 1072 -1 | 1072 0 | 4|
+----+------+------------+------------+------------+------------+--+
| 29013|28937 -76 |28697 -240 |28587 -110 |28527 -60 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-05 Page 30 3 Feb 1997
=================================================================
NET HUMOR
=================================================================
An irreverent look at FidoLand hierarchy. :)
Paul Quinn at 3:640/384
Aha! Here it is... knew I had it somewhere. I found this description
of the network lying around and, as I'd had such a good belly-laugh,
thought that I ought to really pass it around.
FidoNet Co-ordinators
~~~~~~~~~~~~~~~~~~~~~
*IC
leaps tall buildings in a single bound
is more powerful than a locomotive
is faster than a speeding bullet
walks on water
is GOD
*ZC
leaps short buildings in a single bound
is more powerful than a shunting engine
is faster than a speeding bullet
walks on water if the sea is calm
gives policy to God
*RC
leaps short buildings with a running start and favourable winds
is almost as powerful as a shunting engine
is just as fast as a speeding bullet
walks on water in an indoor swimming pool
talks with God
*NC
barely clears a fabricated hut
loses a tug of war with locomotive
can fire a speeding bullet
swims well
talks with God if special request is approved
*HUB
makes high marks on the wall when trying to clear tall buildings
is run over by locomotives
can sometimes handle a gun without hurting themselves
dog paddles
talks to animals
*NODE
FIDONEWS 14-05 Page 31 3 Feb 1997
runs into buildings
recognises locomotives 2 times out of 3
is not issued with ammunition
can stay afloat with a lifejacket
talks to walls
*POINT
falls over doorstep when trying to enter buildings
says look at the choo choo
wets themselves with water pistol
plays in mudpuddles
mumbles to themselves
*USER
lifts buildings and walks under them
kicks locomotives off the tracks
catches speeding bullets in teeth and ears
walks on water if it is frozen
who the hell is GOD?
Many thanks to Stuart Fox (3:635/727.21) for the original.
Cheers,
Paul.
-----------------------------------------------------------------
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)>,
Date: Tue, 28 Jan 97 14:22:29 -0600
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
Subject: Fwd: PC Users
==================BEGIN FORWARDED MESSAGE==================
>Date: Tue, 28 Jan 1997 14:11:26 -0600
>To: Mike Riddle <mriddle@monarch.papillion.ne.us>
>From: "Demitri Baroutsos" <deems@bigfoot.com> (by way of jennifer
rose <jjrose@redoak.heartland.net>)
>Subject: PC Users
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
9 Different types of users
El Explicito:
"I tried the thing, ya know, and it worked, ya know, but now it
doesn't, ya know?"
Advantages : Provides interesting communication challenges.
Disadvantages: So do chimps.
Symptoms : Complete inability to use proper nouns
FIDONEWS 14-05 Page 32 3 Feb 1997
Real Case : One user walked up to a certain Armenian pod manager
and said, "I can't get what I want!" The pod manager
leaned back, put his hands on his belt-buckle, and
said, "Well, ma'am, you've come to the right place."
Mad Bomber:
"Well, I hit Alt-f6, shift-f8, Cntrl-f10, f4, and f9, and now it
looks all weird."
Advantages : Will try to find own solution to problems.
Disadvantages: User might have translated document to Navajo without
meaning to.
Symptoms : More than six stopped jobs in UNIX, a 2:1 code-to-
letter ratio in WordPerfect
Real Case : One user came in complaining that his WordPerfect
document was underlined. When I used reveal codes on
it, I found that he'd set and unset underline more
than fifty times in his document.
Frying Pan/Fire Tactician:
"It didn't work with the data set we had, so I fed in my aunt's
Recipe for key lime pie."
Advantages : Will usually fix error.
Disadvantages: 'Fix' is defined VERY loosely here.
Symptoms : A tendency to delete lines that get errors instead of
fixing them.
Real Case : One user complained that their program executed, but
didn't do anything. The scon looked at it for twenty
minutes before realizing that they'd commented out
EVERY LINE. The user said, "Well, that was the only
way I could get it to compile."
Shaman:
"Last week, when the moon was full, the clouds were thick, and
formahaut was above the horizon, I typed f77, and lo, it did
compile."
Advantages : Gives insight into primitive mythology.
Disadvantages: Few scons are anthropology majors.
Symptoms : Frequent questions about irrelevant objects.
Real Case : One user complained that all information on one of
their disks got erased (as Norton Utilities showed
nothing but empty sectors, I suspect nothing had ever
been on it). Reasoning that the deleted information
went *somewhere*, they wouldn't shut up until the
scon checked four different disks for the missing
information.
X-user:
"Will you look at those...um, that resolution, quite impressive,
really."
FIDONEWS 14-05 Page 33 3 Feb 1997
Advantages : Using the cutting-edge in graphics technology.
Disadvantages: Has little or no idea how to use the cutting-edge in
graphics technology.
Symptoms : Fuzzy hands, blindness
Real Case : When I was off duty, two users sat down in front of
me at DEC station 5000/200s that systems was
reconfiguring. I suppressed my laughter while, for
twenty minutes, they sat down and did their best to
act like they were doing exactly what they wanted to
do, even though they couldn't log in.
Miracle Worker:
"But it read a file from it yesterday!" 'Sir, at a guess, this disk
has been swallowed and regurgitated.' "But I did that a month ago,
and it read a file from it yesterday!"
Advantages : Apparently has remarkable luck when you aren't
around.
Disadvantages: People complain when scons actually use the word
"horse-puckey".
Symptoms : Loses all ability to do impossible when you're
around. Must be the kryptonite in your pocket.
Real Case : At least three users have claimed that they've loaded
IBM WordPerfect from Macintosh disks.
Taskmaster:
"Well, this is a file in MacWrite. Do you know how I can upload it
to MUSIC, transfer it over to UNIX from there, download it onto an
IBM, convert it to WordPerfect, and put it in three-column format?"
Advantages : Bold new challenges.
Disadvantages: Makes one wish to be a garbage collector.
Symptoms : An inability to keep quiet. Strong tendencies to
make machines do things they don't want to do.
Real Case : One user tried to get a scon to find out what another
person's E-mail address was even though the user
didn't know his target's home system, account name,
or real name.
Maestro:
"Well, first I sat down, like this. Then I logged on, like this, and
after that, I typed in my password, like this, and after that I
edited my file, like this, and after that I went to this line here,
like this, and after that I picked my nose, like this..."
Advantages : Willing to show you exactly what they did to get an
error.
Disadvantages: For as long as five or six hours.
Symptoms : Selective deafness to the phrases, "Right, right,
okay, but what was the ERROR?", and a strong fondness
for the phrase, "Well, I'm getting to that."
Real Case : I once had to spend half an hour looking over a
user's shoulder while they continuously retrieved a
FIDONEWS 14-05 Page 34 3 Feb 1997
document into itself and denied that they did it (the
user was complaining that their document was 87
copies of the same thing).
Princess (unfair, perhaps, as these tend, overwhelmingly, to be
males):
"I need a Mac, and someone's got the one I like reserved, would you
please garrote him and put him in the paper recycling bin?"
Advantages : Flatters you with their high standards for your
service.
Disadvantages: Impresses you with their obliviousness to other
people on this planet.
Symptoms : Inability to communicate except by complaining.
Real Case : One asked a scon to remove the message of the day
because he (the user) didn't like it.
Yours Humouresly,
The Humour Man (aka Demitri Baroutsos)
mailto:humour@bigfoot.com
http://www.nis.za/homepgs/dbarout.htm
http://cyber.nis.za/penpal/
Online Pager: http://wwp.mirabilis.com/189775
---------------------------------------------------------
** DISCLAIMER ** None of the jokes posted are in any way
intended to insult or offend any person/place/race/creed or
sex. The jokes posted in no way represent my views or those
of the company I work for. The jokes posted may contain rude
or inappropriate words and/or content - parental guidance
is advised.
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 14-05 Page 35 3 Feb 1997
=================================================================
COMIX IN ASCII
=================================================================
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Mon Jan 27 06:12:42 1997
From: Dave Aronson @ 1:109/120
To: Chris Baker @ 1:18/14
Date: 26 Jan 97 21:38:52
Subj: more ascii comix
I was going to send you more of my ASCII art, but I didn't want to
/\__--~~~--__/\
||\ /||
|/|(O) (O)|\|
\ .---. /
\ ( O O ) /
\ `---' /
`-----'
the space all to myself.
-----------------------------------------------------------------
FIDONEWS 14-05 Page 36 3 Feb 1997
=================================================================
NOTICES
=================================================================
Future History
6 Feb 1997
Waitangi Day, New Zealand.
7 Feb 1997
Chinese New Year, Year of the Ox - 4695.
16 Feb 1997
Eleventh Anniversary of invention of Echomail by Jeff Rush.
29 Feb 1997
Nothing will happen on this day.
17 May 1997
Independence Day, Norway.
25 May 1997
Independence Day, Argentina.
6 Jun 1997
National Commemoration Day, Sweden.
11 Jun 1997
Independence Day, Russia.
1 Jul 1997
Canada Day - Happy Birthday Canada.
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
FIDONEWS 14-05 Page 37 3 Feb 1997
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-05 Page 38 3 Feb 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
My apologies to everyone; I missed last week's deadline. Sigh. And I
was doing so well... ;-)
I thought I'd have phased out the old info by now, but old info still
makes up 47% of the column. I kept a few of the old sections around,
hoping it would encourage folks to write in. It's also been harder to
find contact info than I expected.
Anyone who has contact info for -any- package of interest to Fidonet
sysops is encouraged to submit it. I'm happy to do the leg-work of
tracking down the specifics if I have a name to start with.
Fair warning: The Xenix, Atari, and CoCo sections got a reprieve
because folks wrote in. Since then, I've gotten a few Unix and Atari
submissions, but no CoCo submissions. I plan to phase out the old
Xenix and CoCo sections soon unless I hear something new. The Atari
section will follow once I've followed up on my leads.
Phased out this week: TBBS 2.1, TComm/TCommNet 3.4,
Telegard 2.7, and TPBoard 6.1
Phase-out highlights:
This week: "Xenix/Unix 386 -- Other Utilities" Section
Deadline for info: 14 Feb 1997.
Last week: WildCat! 3.02 and XBBS 1.77
Deadline for info: 7 Feb 1997.
-=- 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
FIDONEWS 14-05 Page 39 3 Feb 1997
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.1 O S Peter Karlsson 2:206/221 ANNOUNCE
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
CheckPnt 1.0 O G Michiel van der Vlist
2:500/9 CHECKPNT
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO
FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S JoHo 2:201/330 FD
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
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 van der Vlist
2:500/9 IMCRYPT
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.20 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
MakePl 1.9 N G Michiel van der Vlist
2:500/9 MAKEPL
Marena 1.1 beta O G Michiel van der 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.00 O G Paul Edwards 3:711/934 MSGED
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT
PcMerge 2.7 N G Michiel van der Vlist
2:500/9 PCMERGE
PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP
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
FIDONEWS 14-05 Page 40 3 Feb 1997
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS
TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG
TriToss 10.0 T S Patrick Driscoll 1:372/19 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.30 T S Craig Dooley 1:376/126 WWIVTOSS
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
XRobot 3.01 O S JoHo 2:201/330 XRDOS
OS/2:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
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.18 O S Michael Hohner 2:2490/2520 FLEET
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
ImCrypt 1.04 O G Michiel van der Vlist
2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
PcMerge 2.3 N G Michiel van der Vlist
2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S JoHo 2:201/330 XROS2
Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
FrontDoor APX 1.10 P S Mats Wallin 2:201/329 FDAPXW
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
Maximus 3.01 B P Tech 1:249/106 MAXN
Msged/NT 4.00 O G Andrew Clarke 3:635/728 MSGNT400.ZIP
FIDONEWS 14-05 Page 41 3 Feb 1997
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.8g M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx ...tx7.8 M G Pablo Saratxaga 2:293/2219 IFMAILTX
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY
Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, F-Fossil, O-Other. Note: Multifunction will
be listed by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
BBS Software MS-DOS Systems
Name Version --------------
--------------------
WildCat! 3.02* Other Utilities Other Utilities
XBBS 1.77 Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
FIDONEWS 14-05 Page 42 3 Feb 1997
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
PKPak 3.61 GMM 1.21 TGroup 1.13
PKZip 1.10 GROUP 2.23 TIRES 3.11
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
SysNL 3.14 MsgLnk 1.0c XST 2.3e
XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00
XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25
MSGTOSS 1.3 ZSX 2.40
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OS/2 Systems
------------
Other Utilities Other Utilities
BBS Software Name Version Name Version
Name Version -------------------- --------------------
-------------------- ARC 7.12 oMMM 1.52
Kitten 1.01 ARC2 6.01 Omail 3.1
SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33
EchoStat 6.0 PKZip 1.02
Network Mailers EZPoint 2.1 PMSnoop 1.30
Name Version FGroup 1.00 PolyXOS2 2.1a
-------------------- GROUP 2.23 QSort 2.1
BinkleyTerm(S) 2.50 LH2 2.11 Raid 1.0
BinkleyTerm/2-MT MSG 4.2 Remapper 1.2
1.40.02 MsgLink 1.0c Tick 2.0
SEAmail 1.01 MsgNum 4.16d VPurge 4.09e
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Xenix/Unix 386 Other Utilities
-------------- Name Version
--------------------
BBS Software Network Mailers ARC 5.21
Name Version Name Version C-LHARC 1.00
-------------------- -------------------- MSGLINK 1.01
oMMM 1.42
Omail 1.00
|Contact: Willy Paine 1:343/15,| ParseLst 1.32
|or Eddy van Loo 2:285/406 | Unzip 3.10
VPurge 4.08
FIDONEWS 14-05 Page 43 3 Feb 1997
Zoo 2.01
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BBS Software Macintosh Other Software
Name Version --------- Name Version
-------------------- --------------------
FBBS 0.91 Network Mailers MacArd 0.04
Hermes 1.6.1 Name Version Mantissa 3.21
Mansion 7.15 -------------------- Mehitable 2.0
Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0
Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2
Telefinder Host StuffIt Classic 1.6
2.12T10 Other Software SunDial 3.2
Name Version TExport 1.92
-------------------- TimeStamp 1.6
Point System ArcMac 1.3 TImport 1.92
Software AreaFix 1.6 Tset 1.3
Name Version Compact Pro 1.30 TSort 1.0
-------------------- EventMeister 1.0 UNZIP 1.02c
Copernicus 1.00 Export 3.21 Zenith 1.5
CounterPoint 1.09 Import 3.2 Zip Extract 0.10
MacWoof 1.1 LHARC 0.41
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Amiga Network Mailers Other Software
----- Name Version Name Version
-------------------- --------------------
BBS Software BinkleyTerm 1.00 Areafix 1.48
Name Version TrapDoor 1.80 AReceipt 1.5
-------------------- WelMat 0.44 ChameleonEdit 0.11
4D-BBS 1.65 ConfMail 1.12
Falcon CBCS 1.00 ElectricHerald 1.66
Starnet 1.0q@ Compression FFRS 1.0@
TransAmiga 1.07 Utilities FileMgr 2.08
XenoLink 1.0 Name Version Fozzle 1.0@
-------------------- Login 0.18
AmigArc 0.23 MessageFilter 1.52
NodeList Utilities booz 1.01 Message View 1.12
Name Version LHARC 1.30 oMMM 1.50
-------------------- LhA 1.10 PolyXAmy 2.02
ParseLst 1.66 LZ 1.92 RMB 1.30
Skyparse 2.30 PkAX 1.00 Roof 46.15
TrapList 1.40 UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BBS Software Atari ST/TT
Name Version -----------
--------------------
FIDOdoor/ST 2.5.1 Network Mailers Other Utilities
FIDONEWS 14-05 Page 44 3 Feb 1997
FiFo 2.1v Name Version Name Version
LED ST 1.00 -------------------- --------------------
QuickBBS/ST 1.06* The Box 1.95* ApplyList 1.00@
Burep 1.1
Compression ComScan 1.04
Utilities NodeList Utilities ConfMail 4.10
Name Version Name Version Echoscan 1.10
-------------------- -------------------- FDrenum 2.5.2
ARC 6.02 ParseList 1.30 FastPack 1.20
LHARC 2.01i EchoFix 1.20 Import 1.14
PackConvert sTICK/Hatch 5.50 oMMM 1.40
STZip 1.1* Pack 1.00
UnJARST 2.00 Trenum 0.10
WhatArc 2.02
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Tandy Color Computer 3 (OS-9 Level II) Other Utilities
-------------------------------------- Name Version
--------------------
BBS Software Compression Utility Ascan 1.2
Name Version Name Version AutoFRL 2.0
-------------------- -------------------- Bundle 2.2
RiBBS 2.02+ Ar 1.3 CKARC 1.1
DeArc 5.12 EchoCheck 1.01
OS9Arc 1.0 FReq 2.5a
UnZip 3.10 LookNode 2.00
UnLZH 3.0 ParseLST
PReq 2.2
RList 1.03
RTick 2.00
UnBundle 1.4
UnSeen 1.1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 14-05 Page 45 3 Feb 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-05 Page 46 3 Feb 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
http://www.dharmanet.org/BDO/net125.html
Region 15:
http://www.smrtsys.com/region15/
Region 17:
http://www.portal.ca/~awalker/region17.htm
Region 18:
http://www.citicom.com/fido.html
Region 19:
http://ccove.n-link.com/
============
Zone 2: http://www.z2.fidonet.org
ZEC2 http://fidoftp.paralex.co.uk/zec.htm
Region 29: http://www.rtfm.be/fidonet/ (in French)
Region 36: http://www.geocities.com/SiliconValley/7207/
============
Zone 3: http://www.z3.fidonet.org
============
Zone 4:
============
FIDONEWS 14-05 Page 47 3 Feb 1997
Zone 5:
============
Zone 6: http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-05 Page 48 3 Feb 1997
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Christopher Baker
Editors Emeritii: Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar,
Tom Jennings, 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
cbak.rights@opus.global.org
(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 1996 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
FIDONEWS 14-05 Page 49 3 Feb 1997
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSDnn.LZH] for a
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in
size from 48K to 1.2M.
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.
=*=*=*=*=*=*=*=*=
FIDONEWS 14-05 Page 50 3 Feb 1997
A PGP generated public-key is available for the FidoNews Editor from
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-
-----------------------------------------------------------------
Download original FidoNews · Volume 14 (1997) · ← Previous · Next →