Volume 7, Number 46 12 November 1990

Volume 7, Number 46 12 November 1990
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| FidoNet (r) | | \ \\ |
| International BBS Network | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief: Vince Perriello
Editors Emeritii: Thom Henderson, Dale Lovell
Chief Procrastinator Emeritus: Tom Jennings

Copyright 1990, Fido Software. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only.
For use in other circumstances, please contact Fido Software.

FidoNews is published weekly by and for the Members of the
FidoNet (r) International Amateur Electronic Mail System. It is
a compilation of individual articles contributed by their authors
or authorized agents of the authors. The contribution of
articles to this compilation does not diminish the rights of the
authors.

You are encouraged to submit articles for publication in
FidoNews. Article submission standards are contained in the file
ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous
Mail system, available for network mail 24 hours a day.

Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, Box 77731, San Francisco CA 94107, USA and are
used with permission.

Opinions expressed in FidoNews articles are those of the authors
and are not necessarily those of the Editor or of Fido Software.
Most articles are unsolicited. Our policy is to publish every
responsible submission received.

Table of Contents
1. ARTICLES ................................................. 1
Ask A Coordinator ........................................ 1
GATEWAY POLICY??? Hunh?? What?? .......................... 3
LDS_PRIVATE Echo Now Available ........................... 5
SGANet - Student Government Global Mail Network .......... 6
NewStyle Packets ......................................... 8
Why Not? (Because it is too simple?) ..................... 15
2. COLUMNS .................................................. 17
A View from the Bridge ................................... 17
3. LATEST VERSIONS .......................................... 18
And more!
FidoNews 7-46 Page 1 12 Nov 1990

=================================================================
ARTICLES
=================================================================

Paul Knupke, Jr.
Fidonet 1:3603/110.9
Eggnet 99:9010/35

Ask A Coordinator

Recently a new participant in the SYSOP echo said "I thought
this echo was for civil discussions between sysops." SYSOP and
CIVIL are oxymoron. Where is a sysop to go when they want to
get real answers and have discussions where they won't be
attacked for their personal opinions? I thought about this for
a while and came to the conclusion that SYSOP is a lost cause
and the only thing to do is start a brand new echo where flames
and personal attacks will not be tolerated.

Ask A Coordinator, ASK_A_C, is an echo devoted to sysops and
users who want to ask questions and carry on friendly
conversation. Topics include: Policy (current and proposed),
echomail, software, how the network operates, and many more
topics.

ASK_A_C is open to everyone who is willing to converse in a
friendly manner. The only people who are not welcome are those
who flame and attack others (there is an echo for those people
already.)

I invite all Coordinators to participate in this open
discussion forum. I am working to move this echo to backbone as
soon as possible. All current and former *C's and *EC's are
invited to join me in this ground breaking of this echo devoted
to open the channel of discussion between the coordinator
structure and the grunt sysops and their users.

It is the coordinators who keep our network together but it is
the grunt sysops and their users who benefit from their
contributions.

Distribution is being worked on but initially it will be
available from 1:3603/110 (MO, HST/V42, N3603/R18 echomail hub)
in Clearwater, Florida and soon after 151/1003 (R18EC).

Contact Neil Lauritsen (1:3603/110) for a link into ASK_A_C.

Paul Knupke, Jr.
Moderator - ASK_A_C

FidoNews 7-46 Page 2 12 Nov 1990

-----------------------------------------------------------------
FidoNews 7-46 Page 3 12 Nov 1990

Jim Deputy
Moderator Kinknet Echoes
Zone Coordinator Adult Links Network
EggNet Supreme Court Chief Justice
1:103/158, 99:99/105, 69:69/0

Gateway Policy...

Well, to be honest, it looks like I probably ought to quit read-
ing FidosNews again, and wait for the announcements in the Node-
list, where they are supposed to be posted. It would probably
result in my blood-pressure staying down much better. Especially
since they aren't being made there anymore. Sorry for the long
lead in at the top, but I am speaking on this subject matter on
much more than one level.

I've just read Matt Whelan's version of the New GATEWAY LAW that
the **C's have decided to inflict us with. It's nice to see that
FidoNet doesn't want to tell the other networks how to operate.
Now would

SOMEONE PLEASE TELL THAT TO FIDONET!!!!!

I'm beginning to think that maybe folks like Jack Decker, Jason
Steck, The ROUSTER, and a few of the other so-called rabble
rousers aren't all that far off base. I am beginning to feel that
the SS-Elite are moving in on us along with BIG BROTHER!

First off, what's this contract crap at the end of the Gateway
policy? Come on! If you aren't telling other networks how to
operate, what the heck do you call it? This is supposed to be a
hobby not a business.

Second, the article immediately following Matt's GATEWAY POLICY,
by Tony Davis quite calmly announces that "1:1/100@FIDONET will
accept and deliver domain addressed network netmail to the do-
mains of:

Fidonet
Alternet
Eggnet
Rbbsnet
Network
Kinknet"

I find this very interesting. Who died and elected either Tony
Davis or Matt Whelan GOD? I believe I have to claim that I am
KinkNet. Or at least I have the right to that claim. After all, I
started the KinkNet echoes over two years ago, and am the modera-
tor of the echo conferences tied together under that banner.

FidoNews 7-46 Page 4 12 Nov 1990

KinkNet is not a DOMAIN! KinkNet is nothing more than a group of
Echoes. KinkNet operates in the DOMAIN of Adult Links (Zone 69) of
which I am also the Zone Coordinator.
IT DOES NOT OPERATE WITHIN THE DOMAIN OF FIDONET!!!

As the moderator of the KinkNet echoes, I have entered into no
agreement authorizing such a gateway. As the Zone Coordinator of
Adult Links, likewise I have authorized no such gateway, nor has
it even been discussed with me. I have further not discussed or
agreed to Adult Links or KinkNet DOMAIN titles with anyone. I am
glad to see that FidoNet has not made any decisions for KINKNET
or Adult Links!

Hence, EFFECTIVE IMMEDIATELY 1:1/100@FIDONET is not authorized to
gate any traffic into either KINKNET or Adult Links, until such
time as an agreement is reached.

Be it further known, KINKNET is not a DOMAIN! And the word KINK-
NET may not be used as a DOMAIN tag.

Speaking as the EggNet Supreme Court Chief Justice, I am not
aware of any such agreement existing in EggNet either. Should one
have been reached there would be an applicable 99/1 address.
There is no such address in the current Egglist. Nor has an
announcement been made by the EggNet Inter Network Liaison of
such an agreement. Further, in EggNet in particular, after look-
ing over the contents of the Gateway Policy, EggNet as a whole
would have to vote as to whether or not such an agreement could
be put in place for inter-network operation. No such election is
currently scheduled.

Mr. Davis doesn't have either an Adult Links (required by A_LINKS
policy) or EggNet Address. And Mr. Davis in the past has ex-
hibited strong ANTI-Other Network ideals. (Circa FidoCon '89).

Now, someone PLEASE say something to convince me that FIDONET
isn't out to run the other networks! I wonder, did the rest of
the networks find out about this scheme the same way I did?

-----------------------------------------------------------------
FidoNews 7-46 Page 5 12 Nov 1990

Jeff Murphy
1:344/10
Ephrata, WA, USA

LDS_PRIVATE Echo Now Available

On behalf of it's participants, I wish to announce the existence
of a private echo for Latter-day Saints (Mormons). Currently
all connections are being managed by Charles Simpkinson, 1:347/3
in Boise, ID.

Those of you interested in such things will know that the MORMON
echo already exists on the backbone, and is fairly well used by
its limited audience. However, for some time now the echo has
permitted considerable discussion of religious views - which is
to say that anti-Mormons are having a field day.

Some of us had the erroneous idea that MORMON meant just that: a
forum for members of The Church of Jesus Christ of Latter-day
Saints to discuss issues of interest to themselves. We were
apparently mistaken; most of the "burning questions" raised in
there deal with issues that are fundamental to our religion, in
that they question the basic premises upon which the Church is
built, arguing for example that Joseph Smith was no prophet at
all, the Book of Mormon a total fraud, etc. In other echos, we
call this flaming. In that one, it was called intellectual
curiosity or righteous indignation. <grin>

The echo has not been placed on the backbone in order to avoid
the conflicts which come from non-members and apostates. We
would probably do so if we could figure out a way to prune the
tree when one of these worms wanders in ['scuse my French].
However, the echo is available currently throughout the west
from various boards. We invite Latter-day Saints to might wish
to participate to contact Charles at 1:347/3.

-----------------------------------------------------------------
FidoNews 7-46 Page 6 12 Nov 1990

SGANet - Student Government Global Mail Network
Now linking student leaders in 32 countries

SGANet, started in May 1990, is a global electronic mail
discussion group for student governments and student leaders to
use to discuss campus issues, education, and governance. SGANet
is a group of seven free and open e-mail discussions in which
student leaders can discuss ideas, share information, or request
information with student leaders worldwide. The practical effect
of the system is to place the participating student leaders in
one room.

SGANet supports the following: free and open discussion areas, an
automated directory of users, archives of discussions, and an
automated group of file libraries with information about student
governance, SGAnet, and future plans.

SGANet, although relatively new, now reaches student associations
in 32 countries on six continents. Until recently, our only
publicity was word of mouth.

It is our hope that SGANet, in the future, will provide a
reliable, interactive media which will serve as a foundation for
meaningful student union on the regional, national and even
global level. Simone Botti, of Italy, recently initiated a debate
on drafting a universal Charter on Student Rights which would be
drafted later this year when we have reached a sizeable fraction
of the universities in the 70 countries served by the Internet.

SGANet is collectively maintained by an international team of
moderators and network liasions. Moderators help us keep the
network running and work primarily on technical issues. Network
liasions help us reach universities in a given region and help
prospective users with difficulties ranging from e-mail problems
to langauge barriers.

SGANet can be reached through the following networks:
BITNET/EARN, the Internet (serves over 70 countries), CompuServe,
Usenet, and Fidonet.

SGANet provides the following discussion areas, and related file
libraries:

[email protected] (Global discussion)
[email protected] (North American universities)
[email protected] (South American universities)
[email protected] (European Universities)
[email protected] (Asian/Australian Universities)
[email protected] (Student Association of Virginia, USA)
[email protected] (Illinois Universities, USA)
[email protected] (Technical discussion group)

FidoNews 7-46 Page 7 12 Nov 1990

Automatic subscriptions can be taken by sending the following
message to [email protected]

SUBscribe (Network name) (Your name, affiliation, country)

We are interested in making SGANet, and its five
regional networks, available through Fidonet. Our ultimate
goal is to provide a forum in which student leaders can share
information, and plan strategy worldwide; and also to make
the discussions available to as wide an audience as possible.
If you would be interested in joining SGANet and/or making
SGANet available to your users contact one of the following:

Brian McConnell
SGANet System Moderator
FidoNet= 1:114/15
Internet= [email protected]
UNITED STATES

Abhik Biswas,
SGANet System Co-Moderator
UNITED STATES
Bitnet= [email protected]

Daniel Kalchev
SGANet-E (Europe) Moderator
BULGARIA
Daniel Kalchev
Fidonet= 2:359/1

-----------------------------------------------------------------
FidoNews 7-46 Page 8 12 Nov 1990

NewStyle Packets
A Proposal for the
Next Generation of
of FidoNet Mail Packers

Third Draft
10 November 1990

jim nutt
1:114/30@fidonet

Introduction

FidoNet has been using the Type II style packet for some
five years or more now with good results. However, at this
point, the Type II format has been extended an amazing number of
ways using the "Kludge" hidden line facility provided by a
leading ^A (ASCII SOH) on a line of text. It is my belief that
the time has come to move to a newer technology for handling
packets, one that is inherently extensible and easily handled by
a number of systems. Such a system should be able to handle
such varied things as integrated text/graphics and other special
attributes of messages. Such a system has been proposed by
Garth Kidd and is expanded upon here.

Basic Format

Essentially, this format would break a message into a
number of "chunks". Each chunk would be a maximum of
4,294,967,306(!) bytes long including its header and may contain
any type of data. A chunk header would be 21 bytes long and
would consist of a 4 byte chunk type tag followed by an 8 byte
length field. The length field does *not* include the 12 bytes
of the chunk header. Chunks would be unterminated. In C, a
chunk structure would look like this:

struct chunk {
char type[4];
char len[8]; /* 32 bit length of data field, 8 hex
digits */
unsigned char data[len]; /* not really, this isn't
legal c, but it gets the
idea across */
};

Certain chunk types require that a FidoNet address be
represented in a 24 byte hex format. This address would be
comprised of the domain, zone, net, node, and point expressed as
the following C structure:

struct address {
FidoNews 7-46 Page 9 12 Nov 1990

char domain[8];
char zone[4];
char net[4];
char node[4];
char point[4];
};

The domain name is *not* null terminated, it is however, null
padded to eight characters. If the first character of the
domain name is null, then the remainder of the domain field is
to be considered absent. This offers a space savings of 7 bytes
per address when operating in a non-domain aware Network.

All other fields are 4 hex digits, again, with NO
terminating nul character. It was chosen to use an ASCII
representation of numbers (in hex) to avoid byte ordering
problems and to enhance portability across 7 bit transport
layers.

Chunk Types

Chunk type names are exactly four characters long, padded
with spaces if necessary. Chunk types not recognized by a
program would be passed along and ignored. Chunk types that are
marked with an asterisk (*) must be recognized by a conforming
installation. Chunk types marked with a C are considered
control chunks, while those marked with D are data chunks.
Unmarked chunks are delimiters or informational. I would
propose the following base chunk types:

* BEGB A chunk indicating the beginning of a bundle.
This chunk may contain optional information
identifying the bundle.

CRTR Indicates the software and revision level used
to create this bundle. Applies only to entire
bundles.

* PSWD Password for the entire bundle, or if within
"BEGM"/"ENDM" a single message. If the password
in this chunk does not match a predefined
password on the receiving system one of two
actions occurs. If the receiving system is the
final destination of the bundle or message, the
bundle or message is discarded, optionally with
a message being sent back to the sender saying so.
If the bundle or message is only passing through,
it will not be made visible to the sysop of the
routing system, regardless of any options that
may be set to the contrary. Obviously, this is
lightweight security, but it is better than
FidoNews 7-46 Page 10 12 Nov 1990

nothing!

* BEGM A chunk indicating the beginning of a message,
this chunk may contain optional information
identifying the message.

* ROUT C Binary address of next destination for this
message or bundle. In other words, if a message
from 123/456 is going to 456/789 but is routed
through an intermediary system (say 321/654) this
address would be that of the intermediary system.
This address would be a two dimensional address in
the sender's current zone and domain. This
address would be represented in C as:

struct route_address {
char net[4];
char node[4];
};

This chunk may be applied to either a single
message or an entire bundle. If the chunk length
is 24, then the route address is a full five
dimensional address comprising domain, zone and
point information as described above in "Basic
Formats", otherwise the chunk length is 4 and the
address is in the format described above.

* TO C Name and address of receiver in ascii. The
address in this field may be anything, so long
as the system at the "ROUT" address can make
sense of it.

* FROM C Name and address of sender in ascii. This
may be anything so long as it is possible for
the receiver to reply via the address in this
field.

* ATTR C Attributes of the message. See Appendix 2 for
a complete list of message attributes. Length is
8.

* NUMB Serial number of this message on originating
system. This chunk is fixed as an 8 byte hex
word. Length is 8.

* RPLY Address and serial number of the message this
message is a reply to. This chunk is a 24 byte
hex address followed by a 8 byte hex word. Length
is 32.

FidoNews 7-46 Page 11 12 Nov 1990

* ATCH C Name of a file attached to this message

* FREQ C Name of a file requested from receiving system.
This would incorporate the same type of update
request logic as is currently used by WaZoo
mailers. A separate "FREQ" chunk is required
for each file requested.

* AREA C Echomail only, signifies the echomail area this
message belongs to.

* DOMN C Echomail only, list of domains, as 8 byte ASCII
strings (null-padded, but not necessarily null-
terminated), that have seen this message.

* ZONE C Echomail only, list, as four byte hex words,
of zones that have seen this message. This
chunk is cleared each time the message enters a
different domain and the name of the domain the
message is exiting is added to the "DOMN" chunk.

* NET C Echomail only, list, as four byte hex words,
of all nets that have seen this message. This
chunk is cleared upon export to another zone and
the exporting node's zone number is added to the
"ZONE" chunk.

* NODE C Echomail only, list, as four byte hex words,
of all nodes in the current net that have seen
this message. This chunk is cleared each time
the message enters a new net and the number of
the net the message is exiting is added to the
"NET " chunk.

* PONT C Echomail only, list, as four byte hex words,
of all point systems that have seen this message.
This chunk is cleared upon export to another node
and the node number of the exporting system is
added to the "NODE" chunk.

* PATH List of the systems this message has passed
through to reach this system, in order. This
includes all systems in all zones and domains.
All addresses would be 24 byte hex as defined
in the section "Basic Formats"

* TEXT D The text of the message

TXAT D Text attribute change. Allows for font changes,
underlining, etc. See Appendix 4 for the basic
set of text attributes.

FidoNews 7-46 Page 12 12 Nov 1990

BITS D A bitmap. To be defined (MacPaint? Windows? PCX?
TIFF?)

BITC D Bitmap continuation.

GRPH D A vector drawing. To be defined (PostScript?
HPGL?)

* ENDM A chunk indicating the end of a message. This
chunk may optionally contain information
identifying the message it terminates.

* ENDB A chunk indicating the end of the bundle,
anything after this can be safely ignored.
This chunk may optionally contain information
identifying the bundle it terminates.

Other Considerations

Chunk style packets could not be sent as *.PKT files as
they are not backward compatible with type II packets. I
propose that chunk style packets be called bundles and sent as
*.BUN files, with compressed bundles sent as *.B?? where ?? is
the compression method used (see Appendix 1 for extensions).
Bundle file names should be unique for at least a one week
cycle, a 32 bit serial number expressed in hexadecimal should
prove adequate for most applications.

Experimental chunk types are provided for by the provision
that unrecognized chunk types be passed through and ignored.
Systems that know how to use a particular chunk type (say, BITS)
can, while systems that don't understand it may ignore it.

Chunks should appear in a bundle in roughly the same order
as they appear above, with control and informational chunks
(PATH, ROUT, etc) appearing before data chunks (TEXT, BITS,
GRPH).

Control

Chunk tag name assignments are controlled by Appendix 3 of
this document. New chunk tags may be added and old ones revised
by revision of this document. Message attribute assignments are
controlled by Appendix 2 of this document. New attributes may
be assigned by revision of this document. Bundle file
extensions are controlled by Appendix 1 of this document. New
extensions may be defined and old ones revised by revision of
this document. Finally, text attributes are controlled by
Appendix 4 of this document.

Conclusion

FidoNews 7-46 Page 13 12 Nov 1990

I doubt I have covered all possible or desirable chunk
types in this document. I do believe however, that enough have
been defined to get started with. Chunks offer a highly
flexible, extensible system of bundling mail. New types of
chunks may defined as needed to accomodate advances in
technology and FidoNet. Additionally, this would further
separate the application and transport layers of FidoNet,
yielding less confusion as to their respective roles.

It may be noticed that this structure is extremely similar
to the IFF format as used on Amiga computers and introduced by
Electronic Arts Software. While inspired by IFF, this system has
been simplified somewhat and changed to be more easily
transportable between computers using different byte orders and
processors. All fields defined in this document are 7 bit ascii
and should be easily parsed by any system.

Appendix 1 - Compression Extensions

Compressed bundles would indicate the type of compression
used by the following file extensions:

Extension Creator
--------- -------
.BUN Uncompressed
.BPK PKZip
.BLH LHarc
.BAR ARC
.BDW DWC
.BPA PAK
.BZO ZOO
.BPX PKXarc

Appendix 2 - Message Attributes

Message attributes are expressed as an 8 byte hex word.
(32 bit binary) Multiple attributes may be ORed together. The
following attributes have been assigned.

0000000000000001 Privileged (sysop or
addressee access only)
0000000000000010 Encrypted
0000000000000100 Crash (high priority)
0000000000001000 Direct (send directly to
recipient system, no routing)
0000000000010000 Hold for pickup

Appendix 3 - Defined Chunk Tags

The following chunk tags are defined in this document:

FidoNews 7-46 Page 14 12 Nov 1990

BEGB NET FROM TEXT AREA
NODE ATTR TXAT ENDB PSWD
CRTR PONT NUMB BITS
BEGM ZONE RPLY BITC
ROUT DOMN ATCH GRPH
TO PATH FREQ ENDM

Appendix 4 - Text Attributes

The text attribute is a four byte hex word (16 bit binary).
Multiple attributes may be ORed together. Attributes are
toggles. The following attributes have been assigned:

00000000 Reset all text attributes
00000001 Underline
00000010 Bold
00000100 Italic
00001000 Font Change
00010000 Size Change
00100000 Color Change

The font, size and color change attributes are followed by a
one byte binary word selecting the font, size and color to
change to. In the case of changing two or all three of these
attributes at the same time, the selectors will follow the
attribute word in the order; font, size, color, with
unnecessary fields being omitted.

-----------------------------------------------------------------
FidoNews 7-46 Page 15 12 Nov 1990

Paul Knupke, Jr.
Pointless Perception
FidoNet 1:3603/110.9
Eggnet 99:9010/35

Why Not? (Because it is too simple?)

Has anyone considered the simplist method of holding elections in
Fidonet lately? How about one vote for each sysop of Fidonet and
the outcome is decided by who has the most votes or whether
there are more yes or no votes for implementation of policy. The
policy of "no vote = no" has got to stop!

In the United States of America officials are elected for the
most part by a minority of the people who are eligible to vote
because not everyone is interested in politics. Why can't Fidonet
employ such a simple method to elect the *C and *EC structure and
to decide if a new policy document will become the law. Those
who are interested will vote and those who aren't won't. Those
who don't vote have no right to complain about the results of
their non participation in an election.

I propose the following election procedure. Once a year all *C
positions are put up for reelection by those under the position.
Before any nominations and elections occur a vote counter would
be needed. The vote counter should be outside the net or region
that the election is taking place. In the ZC case the current IC
would ask a non *C sysop within their zone to serve as vote
counter.

Nominations would be sent to the vote counter via net mail. All
names received before a set date would appear on the ballot. The
ballot would be sent to the *C for distibution.

The nomination and election time frame will be one week (7
days) each. If a candidate gets a majority on the first ballot
they are declared the winner. If no single candidate gets a
majority of votes the two highest vote getters will run against
each other for a runoff election. The highest vote getter is
then declared the winner.

The individual sysops would vote for their Net Coordinator, their
Regional Coordinator and their Zone coordinator. No matter how
many times a sysop's name appears in the nodelist they get one
vote.

The time frame I am describing is 4 weeks long. The first week
of the month (first through the seventh day) is the nomination
period. The second week (eighth day through fourteenth day) is
the election period. The third week (fifteenth day through the
twenty-first day) is to tally votes. The fourth week (twenty-
second day through the twenty-eighth day) is the runoff week (if
necessary.) The results will be published with in 5 days of the
ending of the election and runoff.

FidoNews 7-46 Page 16 12 Nov 1990

Elections for the NCs, RCs and ZCs will not occur at the same
time but about 4 months apart so that the new coordinators will
be settled into their positions.

There is one problem with the above procedure that I need to
address. What happens if the newly elected coordinator wants to
run for a higher office. I propose that if the coordinator wins
the election for the higher office the runner-up in the previous
election takes over the lower position.

The runner up in any *C election would be called the Alternate
*C. In the event the current *C decides to not continue as a *C
or drops out of the network for any reason the A*C would assume
the position until the next election.

All *Cs can run for re-election. A good *C will be re-elected in
most cases and a unpopular *C will not be.

In a few weeks I'll be discussing the *EC structure and election
procedure. It differs from the *C election method because the
*EC jobs are a technical job and the *C jobs are mostly
administrative jobs.

-----------------------------------------------------------------
FidoNews 7-46 Page 17 12 Nov 1990

=================================================================
COLUMNS
=================================================================

A View from the Bridge

"Captain's Log, Stardate 9011.11..."
by The Captain, 1:107/583@FidoNet 520/583@AlterNet 9:807/1@PNet

You know, it seems a lot of idiots who don't have anything better
to do have been jumping up and down about what's being published
in FidoNews. "IT'S NOT FIDONET RELATED!" they scream in long,
tedious articles (as opposed to short, tedious columns like
mine). Let's ask ourselves a question: What does "Fidonet
related" MEAN, and just who the u&rz are YOU to judge what should
get published or not?

There's a long standing tradition with FidoNews, going back
almost SEVEN YEARS that if it's sent in, it gets printed. With
some folks, its a selling point of joining the network! Yet
certain people with narrow minds object to their being "forced"
to distribute a file which on average is smaller than the usual
DAILY echomail bundle once a week, simply because it has
something in it THEY don't care to read. SO, they make a verbal
stink about it without doing anything constructive. Sound
familiar? Can YOU say "echomail"? I thought you could...

Needless to say I continue to support the policy of "All the News
that Fits We Print" with FidoNews. I happen to be directly
responsible for that being the motto of AlterNet's AlterNews. If
someone has something to say that they feel is important enough
that they'll write up an article and send it on their dime to
FidoNews, we oughta publish it. If you don't like that, don't
read it. If you're a *C and don't like distributing it, don't be
a *C. Nobody's FORCING you.

The only time I can remember disliking something in FidoNews was
Tom Jennings's (remember him? He invented the network...)
article on gay rights. I didn't object to his subject matter,
but felt that his profanity should have been editted before
publishing. Other people felt differently, that it should never
have been published at all. To those people I remind: "This Is A
Hobby." And some day THEY might be the ones who want to have
something published.

Good day.

-----------------------------------------------------------------
FidoNews 7-46 Page 18 12 Nov 1990

=================================================================
LATEST VERSIONS
=================================================================

Latest Software Versions

MS-DOS Systems
--------------

Bulletin Board Software
Name Version Name Version Name Version

DMG 2.93 Phoenix 1.3 TAG 2.5g
Fido 12s+ QuickBBS 2.64 TBBS 2.1
Lynx 1.30 RBBS 17.3A TComm/TCommNet 3.4
Kitten 2.16 RBBSmail 17.3B Telegard 2.5
Maximus 1.02 RemoteAccess 0.04a TPBoard 6.1
Opus 1.13+ SLBBS 1.77 Wildcat! 2.50
PCBoard 14.5 Socrates 1.10 XBBS 1.15

Network Node List Other
Mailers Version Utilities Version Utilities Version

BinkleyTerm 2.40 EditNL 4.00 ARC 7.0
D'Bridge 1.30 MakeNL 2.31 ARCAsim 2.30
Dutchie 2.90C ParseList 1.30 ARCmail 2.07
FrontDoor 1.99c Prune 1.40 ConfMail 4.00
PRENM 1.47 SysNL 3.14 Crossnet v1.5
SEAdog 4.51b XlatList 2.90 EMM 2.02
TIMS 1.0(Mod8) XlaxDiff 2.35 Gmail 2.05
XlaxNode 2.35 GROUP 2.16
GUS 1.30
HeadEdit 1.15
InterPCB 1.31
LHARC 1.13
MSG 4.1
MSGED 2.00
MSGTOSS 1.3
PK[UN]ZIP 1.10
QM 1.0
QSORT 4.03
Sirius 1.0x
SLMAIL 1.36
StarLink 1.01
TagMail 2.40
TCOMMail 2.2
Telemail 1.27
TMail 1.15
TPBNetEd 3.2
TosScan 1.00
UFGATE 1.03
FidoNews 7-46 Page 19 12 Nov 1990

XRS 3.40
XST 2.2
ZmailQ 1.12

OS/2 Systems
------------

Bulletin Board Software Network Mailers Other Utilities

Name Version Name Version Name Version

Maximus-CBCS 1.02 BinkleyTerm 2.40 Parselst 1.32
ConfMail 4.00
EchoStat 6.0
oMMM 1.52
Omail 3.1
MsgEd 2.00
MsgLink 1.0C
MsgNum 4.14
LH2 0.50
PK[UN]ZIP 1.02
ARC2 6.00
PolyXARC 2.00
Qsort 2.1
Raid 1.0
Remapper 1.2
Tick 2.0
VPurge 2.07

Xenix/Unix
----------

BBS Software Mailers Other Utilities
Name Version Name Version Name Version

MaximusCBCS 1.02.Unix.B0 BinkleyTerm 2.30b Unzip 3.10
ARC 5.21
ParseLst 1.30b
ConfMail 3.31b
Ommm 1.40b
Msged 1.99b
Zoo 2.01
C-Lharc 1.00
Omail 1.00b

Apple CP/M
----------

FidoNews 7-46 Page 20 12 Nov 1990

Bulletin Board Software Network Mailers Other Utilities

Name Version Name Version Name Version

Daisy v2j Daisy Mailer 0.38 Nodecomp 0.37
MsgUtil 2.5
PackUser v4
Filer v2-D
UNARC.COM 1.20

Macintosh
---------

Bulletin Board Software Network Mailers Other Utilities

Name Version Name Version Name Version

Red Ryder Host 2.1 Tabby 2.2 MacArc 0.04
Mansion 7.15 Copernicus 1.0 ArcMac 1.3
WWIV (Mac) 3.0 LHArc 0.33
Hermes 1.01 StuffIt Classic 1.6
FBBS 0.91 Compactor 1.21
TImport 1.92
TExport 1.92
Timestamp 1.6
Tset 1.3
Import 3.2
Export 3.21
Sundial 3.2
PreStamp 3.2
OriginatorII 2.0
AreaFix 1.6
Mantissa 3.21
Zenith 1.5
Eventmeister 1.0
TSort 1.0
Mehitable 2.0
UNZIP 1.02c

Amiga
-----

Bulletin Board Software Network Mailers Other Utilities

Name Version Name Version Name Version

Paragon 2.07+ BinkleyTerm 1.00 AmigArc 0.23
TrapDoor 1.50 AReceipt 1.5
WelMat 0.42 booz 1.01
ConfMail 1.10
FidoNews 7-46 Page 21 12 Nov 1990

ChameleonEdit 0.10
ElectricHerald1.66
Lharc 1.21
MessageFilter 1.52
oMMM 1.49b
ParseLst 1.30
PkAX 1.00
PK[UN]ZIP 1.01
PolyxAmy 2.02
RMB 1.30
TrapList 1.12
UNzip 0.86
Yuck! 1.61
Zoo 2.01

Atari ST
--------

Bulletin Board Software Network Mailer Other Utilities

Name Version Name Version Name Version

FIDOdoor/ST 1.94 BinkleyTerm 2.40 ConfMail 4.02
Pandora BBS 2.41c The BOX 1.20 ParseList 1.30
QuickBBS/ST 0.60 ARC 6.02
GS Point 0.61 FiFo 2.0b
LHARC 0.60
LED ST 0.10
BYE 0.25
PKUNZIP 1.10
MSGED 1.96S
SRENUM 6.2
Trenum 0.10
OMMM 1.40

Archimedes
----------

BBS Software Mailers Utilities
Name Version Name Version Name Version

ARCbbs 1.44 BinkleyTerm 2.03 Unzip 2.1TH
ARC 1.03
!Spark 2.00d

ParseLst 1.30
BatchPacker 1.00

FidoNews 7-46 Page 22 12 Nov 1990

+ Netmail capable (does not require additional mailer software)
* Recently changed

Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.

-----------------------------------------------------------------
FidoNews 7-46 Page 23 12 Nov 1990

=================================================================
NOTICES
=================================================================

The Interrupt Stack

13 Nov 1990
Third anniversary of Fidonet in Austria (zone 2, region 31).

14 Nov 1990
Marco Maccaferri's 21rd Birthday. Send greetings to him at
2:332/16.0

16 Nov 1990
100% Democratically elected administration takes over the
coordination structure in Zone-4 Latin America

1 Jan 1991
Implementation of 7% Goods and Services Tax in Canada. Contact
Joe Lindstrom at 1:134/55 for a more colorful description.

16 Feb 1991
Fifth anniversary of the introduction of Echomail, by Jeff Rush.

31 Mar 1991
Jim Grubs (W8GRT) was issued his first ham radio license forty
years ago today. His first station was made from an ARC-5
"Command Set" removed from a B-17 bomber.

12 May 1991
Fourth anniversary of FidoNet operations in Latin America and
second anniversary of the creation of Zone-4.

8 Sep 1991
25th anniversary of first airing of Star Trek on NBC!

7 Oct 1991
Area code 415 fragments. Alameda and Contra Costa Counties
will begin using area code 510. This includes Oakland,
Concord, Berkeley and Hayward. San Francisco, San Mateo,
Marin, parts of Santa Clara County, and the San Francisco Bay
Islands will retain area code 415.

1 Feb 1992
Area code 213 fragments. Western, coastal, southern and
eastern portions of Los Angeles County will begin using area
code 310. This includes Los Angeles International Airport,
West Los Angeles, San Pedro and Whittier. Downtown Los
Angeles and surrounding communities (such as Hollywood and
Montebello) will retain area code 213.

FidoNews 7-46 Page 24 12 Nov 1990

1 Dec 1993
Tenth anniversary of Fido Version 1 release.

5 Jun 1997
David Dodell's 40th Birthday

If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.

-----------------------------------------------------------------