FidoNews · Vol 14, No 6 · 10 February 1997
F I D O N E W S -- Volume 14, Number 6 10 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 WERE YOU ON THIS DAY IN HISTORY?
Table of Contents
1. EDITORIAL ................................................ 1
Flacking the hack? WebRing is back! ...................... 1
2. GUEST EDITORIAL .......................................... 2
Almost a New Beginning! .................................. 2
3. ARTICLES ................................................. 6
Zone 2 nodelist flags .................................... 6
A reply to "Fidonews, The "lard ass" of newsletters" ..... 12
A simple rebuttal ........................................ 13
4. GETTING TECHNICAL ........................................ 16
FSC-0034 - Gateways to and from FidoNet .................. 16
FSC-0035 - Transparent Gateways to and from FidoNet ...... 22
FSC-0036 - Group Mail Specifications ..................... 24
5. COORDINATORS CORNER ...................................... 30
Nodelist-statistics as seen from Zone-2 for day 038 ...... 30
6. NET HUMOR ................................................ 31
Why did the chicken cross the road? ...................... 31
7. NOTICES .................................................. 35
Future History ........................................... 35
8. FIDONET SOFTWARE LISTING ................................. 37
Latest Greatest Software Versions ........................ 37
9. FIDONEWS PUBLIC-KEY ...................................... 44
FidoNews PGP public-key listing .......................... 44
10. FIDONET BY INTERNET ..................................... 45
11. FIDONEWS INFORMATION .................................... 47
FIDONEWS 14-06 Page 1 10 Feb 1997
=================================================================
EDITORIAL
=================================================================
Some people believe that disagreement is personal. I've never
understood that but I do acknowledge the trait exists in some folks.
There isn't anything personal in my observations from FidoNews 1405
regarding the substance of Gary Gilmore's 'lard ass' article in that
Issue. His opinion was aired without fail and without editing. If it
were personal, here, would it have been published? His article and my
response are part of the public record. If he finds that unfair,
that's his problem. Isn't it? The readers can decide between the views
and send in their own articles.
While he was railing against the size of FidoNews, I never mentioned
his own contribution to the size of the Nodelist with 5 separate
entries for the same telephone number. Now, that might have been
considered personal, too, but it would just have been a fact like the
other points I made. [grin]
Facts are not personal. FidoNews IS for communicating and he is doing
it again in this Issue. More power to him! He is completely incorrect
about it being personal at this end. Could he be projecting? Nah. We
disagree. No big deal. No insults - thinly or thickly veiled. I do get
the last word in a sense but that, too, is transitory until the next
Issue comes out. Them's the breaks in the real world.
I'd like to remind everyone that there is an official FidoNews Echo
for discussion of FidoNews ops and articles. It is available on the
Zone 1 Backbone as FIDONEWS and also gets around to other Zones last I
heard. There you can get some nearly real-time responses rather than
this 1-2 week lag in the published FidoNews. It has no size
constraints, either.
Meanwhile, the motto in the banner sez it all. [chuckle]
In other news, there is a Guest Editorial in this Issue. It was
received via the U.S. Mail from a former FidoNet Sysop who still
follows the doings of FidoNet but has an ongoing problem with local
Coordinators and does not have a Node number at present. It speaks for
itself. Any responses will be received by the author when he reads the
FidoNews containing them. It's a LONG one by Editorial standards. I
hope that doesn't cause any apoplexy out there. We publish what we
get the way we get it.
The WebRing [www.webring.org] is finally back on the new server and
everyone who has been sending me mail asking about not being able to
get an answer may now proceed to sign up their FidoNet-related web
pages again. There are currently 5 sites connected to the ring and
it's ready for the rest of you. [See 1402 for details.]
C.B.
-----------------------------------------------------------------
FIDONEWS 14-06 Page 2 10 Feb 1997
=================================================================
GUEST EDITORIAL
=================================================================
Almost A New Beginning!
by: V.H.(Clay) Tannacore
On June the 5th, 1989, "A New Beginning" should have begun. It
didn't! Why? What went wrong? Why didn't this "New Beginning"
resolve the dilemma it was designed to? Last, but not least, Why
hasn't there been a New, New Beginning? Some of these answers may
never be resolved. Some are discussed by members of the origination
in question. Some . . . Well, no one wants to address them, leastwise
not in any open forum. Especially, not where the dreaded "C-Monsters"
could overhear them.
What am I babbling about? Come on folks, you know! FidoNet and The
Policy 4 Document. Who are the "C-Monsters?" None other then those
big, bad Regional Coordinators, Network Coordinators, Zone
Coordinators, and assuredly that (now missing) International
Coordinator. Those who inhabit the upper echelons of FidoNet. The
same "C" structure that for reasons only familiar to themselves, keep
this prehistoric epitaph alive, and in force. This opprobrious
document that system operators (SysOps) around the world are told to
operate by. This uncomplicated/complicated instrument with its
"guidance" pertaining to the operation of FidoNet, and all FidoNets
subordinate followers. This same instrument which leaves relatively
everything up for grabs, with one exception. The one exclusion being
how the "C" structure (aka-C-Monsters) is; 1) appointed 2) elected
3) to perform their duties 4) to delegate authority 5) to
(attempt) operate his/her Net, Region, Zone etc. etc. The "guidance"
given in the Policy 4 document to individual Network Coordinators,
Regional Coordinators, and Zone Coordinators, with very few exceptions
is so utterly vague and inadequate it may as well be nonexistent. But
I'm getting a little ahead of myself, here. Allow me to continue with
(my opinion of) what is wrong with the present day FidoNet policies
and operations.
Continuing right along, and in the same otiose manner. Let us examine
the duties of the Regional Coordinator as per the Policy 4 document.
In Section 1.2.4 (Region and Regional Coordinators) of this
superannuated document, there is a total of 102 words. The first 41
words explain *what* a Regional Coordinator is. The next 53 words
(and I'm being generous here) detail (grimace) the duties of the
Regional Coordinator(s). Following this VERY lengthy in depth job
description are another 8 words. These words inform all that the RC
is "appointed" by the Zone Coordinator. Now, according to Policy 4,
Section 1.2.4, The Regional Coordinator has one (and only one) duty to
perform, and that is, and I quote; "maintains the list of independent
nodes in the region and accepts nodelists from the Network
Coordinators in the region. These are compiled to create a regional
nodelist, which is then sent to the Zone Coordinator." Unquote!
WOW!! Doesn't that sound like a grueling job description to you? Of
course we all know that what is described in the Policy 4 document is
but a fraction of what an RC is expected to do, and on a daily basis,
FIDONEWS 14-06 Page 3 10 Feb 1997
at that. Why then does not this (Policy 4) document explain just what
is expected of the RC, and how this is to be accomplished? Sure, give
as much leeway to the person as possible, but by all means "guide"
him/her in accepted procedures so to avoid a multitude of different
methods of operations from network to network. In one word
"STANDARDIZE" FidoNet, so as to insure a harmonious environment.
As I have pointed out above. There are *no* real formal instructions
to assist anyone in comprehending just what is expected of them,
except to inform them that a *nodelist* must be compiled. HELLO!! I
bet you didn't know it, but by far the greatest magnitude of the
SysOps within the FidoNet organization already knew that... Perhaps
back in 1988 and 1989 (when this hideous document was formulated) the
composers of Policy 4 felt that the education level of brother members
were substandard, or something. I don't know, personally. All I can
remember of that time period is the contemptible power struggle that
was prevalent within FidoNet. Not to say that the *power hungry* are
not still a part of this great organization (FidoNet) but to some
degree have been restrained in achievement of their goals. Which I
consider a *PLUS* for this confederation of ours.
Now that you have endured all my maunder, and haven't as yet called
for my lynching. I assume one of two things; 1) you may think I have
something here, or 2) you are in the process of trying to contact
"Doctor Jack" to see if he makes house calls in South Carolina. Rest
easy, what Dr. Jack can't do. The Veterans Administration (VA)
Medical Center (aka-Hospital) will. However, before that time
arrives, or before some technical computer type figures out how to
send a nuclear fission apparatus via NetMail. Let me pass on a few
(of my) suggestions I have that may possibly be plausible ideas for
the betterment of FidoNet, and everyone involved.
First, and foremost, we (meaning you SysOps, and members of FidoNet)
need desperately to assemble a team of members, who can recast
(rewrite) the Policy 4 Document, in order to bring it up to present
day standards, taking into consideration the technology at our
disposal.
Second, and almost as significant, clear cut directions and procedures
*must* be established within the New Policy 4 (or whatever it is
called) document. Guide lines must be set for Regional
Coordinators(Network Coordinators are addressed in a forthcoming
summary) in order for the orderly operation (day to day) of FidoNet in
every area of the globe where FidoNet is active.
Third, (and here a lot of discretion must be employed) Regional
Coordinators must be made aware that the *users* (without who FidoNet
is doomed) must have a way of asserting his/her opinions, as well as
having a way of voicing their grievances directly to the RC, without
fear of retribution from a local Network Coordinator.
Fourth, (again discretion and even sophistication must be stressed)
the Regional Coordinators must *oversee* (without over-overseeing)and
supervise their Network Coordinators (bearing in mind the voluntary
nature of the FidoNet NC) so that a well organized, and smooth flowing
Net is the end result.
FIDONEWS 14-06 Page 4 10 Feb 1997
Fifth suggestion (and a pet peeve of mine) is for the Regional
Coordinator(s) to adopt an intelligent formatting scheme for EchoMail
messages. Presently no such system is in effect, and the EchoMail
message bases are in total tumult, with very few exceptions. Text
lines are *quoted* by the dozens, even *quoted text* is *quoted* by
the (mis)user leaving a message that started out at 2Kb of text, with
the robust size of a Shareware Program (just a tiny bit of
misrepresentation, here) ready for use on a PC. Even the blank lines
of text are being *quoted* adding to the size of the message. Why
individual SysOps haven't taken steps to stop this misuse, I'll never
know. This practice does nothing but cost money, time, and space, not
to mention the offensive looking messages echoed over 300 or 400
different systems throughout the FidoNet areas.
Sixth (getting tired yet?) suggestion is a simple one. As every SysOp
in FidoNet knows, The Internet has lured many, many users from their
local bulletin boards. The Internet with all its modernistic lingo,
with enticing graphics, E-Mail, and Faxing capability etc. etc. Its
world wide (WEB) accessibility, its . . . Hey! . .wait on darn minute.
Isn't this just what FidoNet was supposed to be? Isn't this *just*
what FidoNet *is*??? Oh, maybe not all the goodies like graphics, and
Faxing, etc, but still a great place to communicate, and for free(?).
Seventh, and last suggestion for this conclave, okay? The *free*
assertion above isn't entirely accurate, anymore. There seems to be a
growing fascination with *Pay For Use* bulletin boards. I suppose
this is the SysOp way of entering into competition with The Internet.
But, in reality all that is being accomplished is degradation of
FidoNet along with the principles and ideals it was founded on. How
can anyone expect a user to understand that he/she has to *donate*,
*help support*, or *become a member* of a bulletin board, in order to
read/write mail or upload/download a file. Gee, isn't this just what
he/she has heard about The Internet? He/She was under the impression
that a local bulletin board was there as a *hobby* and was free of
*service charges*. He/She thought *hobby* was "something a person
likes to do in his/her spare time," just like Mr. Webster explains it
in his dictionary. I know administering to a bulletin board (BBS)
isn't cheap, not by a long shot, but it is a *hobby*, and should be
operated that way. I started running my first BBS, on an Atari 800,
in 1978, so trust me when I say *I know about operating costs* first
hand. It wasn't until 1984 that I got into the IBM and FidoNet
business, and even then money was considered a collectors item, to me.
Granted, after your initial costs, the rest was kind of inexpensive,
unless you wanted a *BIG* 40Meg Hard Drive, with a price tag of
$400-500.00. But at no time did I, or anyone else in the Net (with
the exception of the then NC) ever even think about charging a user a
fee. No one except the *software pirates* who kept copyrighted
software available for download on their system, for their *paying*
members. Hmmm! Could that be the reason so many systems operate on a
*Pay Per Use* basis?
As promised, no more *suggestions* or *criticisms*. I'll let a
sleeping (puppy) dog lie, for the time being. However, I hope what I
have written will incite others to do the same. Voices *have* to be
raised if anything is to be done, and rest assured, something has to
be done. FidoNet is in danger of a slow death, unless suitable action
FIDONEWS 14-06 Page 5 10 Feb 1997
is instituted, and extremely soon. The people who are really involved
with FidoNet, and who genuinely care about its existence in the
future will stand up and let their viewpoints be known. This has to
be a combined effort if reconstruction is to take place.
If by chance this article is published in FidoNet and you find it
creditable. I implore you to let the editor (Christopher Baker
1:18/14) know. Voice your own opinions and suggestions pertaining to
the inadequacies of the Policy 4 Document. If you think *making
waves* is frowned upon within the FidoNet structure, you have been
misinformed. On the off chance your reflection is correct, then more
then ever *CHANGE* is a necessity, and PDQ.
-----------------------------------------------------------------
FIDONEWS 14-06 Page 6 10 Feb 1997
=================================================================
ARTICLES
=================================================================
Zone 2 nodelist flags
Frank Ellermann, 2:240/5815.1
This article informs about known differences of FidoNet zone 2
nodelist flags from FTS-0005.003. The ultimate sources for these
informations are the current zone 2 nodelist epilog and the setup
for flag corrections at Z2C, but it may be difficult to get these
sources for readers in other zones.
FTS-0005 flags
--------------
The following flags are used as specified in FTS-0005.003:
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
LO Node accepts calls only from valid listed node
numbers in the current FidoNet nodelist
V21 ITU-T V21 300 bps full duplex
V22 ITU-T V22 1200 bps full duplex
In zone 2 a value of 1200 in the former "baud rate" field implies
V22. Today only two nodes not supporting at least V22bis or ISDN
still exist in the zone 2 segment, therefore the flags V21 and V22
are obsolescent. Both flags should be dropped from FTS-0005.
V29 ITU-T V29 9600 bps half duplex
V33 ITU-T V33
V33 cannot be used in connecting Fido nodes over public dial-up
lines and is most probably a historical error in FTS-0005. This
flag should be removed from FTS-0005 a.s.a.p. A similar argument
is applicable on V29, and few nodes flagging V29 today all support
at least V32. The next version of FTS-0005 should drop V29.
V32 ITU-T V32 9600 bps full duplex
-> V32B ITU-T V32bis 14400 bps full duplex (implies V32)
V34 ITU-T V34 28800 bps full duplex
FTS-0005 specifies V32b and V42b (capital V and small b), current
nodelist practice in FidoNet shows all combinations of small and
capital letters for flags. This was no problem before FSC-0062
introduced case-sensitive flags. In zone 2 all old flags except
from FSC-0062 flags are upper case, and a NODEDIFF changing this
convention would be annoying. The best solution is to stick to
the current practice and treat all old flags as case-insensitive.
H96 Hayes V9600
HST USR Courier HST up to 9600 (implies MNP)
FIDONEWS 14-06 Page 7 10 Feb 1997
H14 USR Courier HST up to 14400 (implies HST)
-> H16 USR Courier HST up to 16800 (implies H14 and V42B)
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
-> ZYX Zyxel series 16800 bps (implies V32B and V42B)
-> V32T V.32 Terbo 19200 bps (implies V32B)
VFC V.Fast Class 28800 bps
If a flag directly or indirectly implies other flags, then these
other flags are not shown in a nodelist entry, because this would
be redundant. Unfortunately the rules for redundancies in zone 2
and FTS-0005 are different. Zone 2 continued to avoid redundancy
with most "new" flags, but FTS-0005.003 specified no redundancies
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
context are flags approved by FidoNet International Coordinators
since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
was published.
For details see the chapter "implications" below, for now only
note, that in zone 2 H16 implies V42B, ZYX implies V32B and V42B,
and V32T implies V32B.
Zone 1 and zone 2 have introduced a user flag Z19 approved by the
corresponding Zone Coordinator. User flags are discussed later,
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
for all Zyxel protocol speeds.
Today there is only one node in FidoNet still flagging MAX, this
flag is obsolete and should be dropped from FTS-0005. The flags
HST, H14, and CSP should be marked as obsolescent.
MNP Microcom Networking Protocol error correction
V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
-> V42B ITU-T LAP-M error correction w/fallback to MNP 1-5
As mentioned above FTS-0005 specifies V42b (capital V, small b).
In zone 2 all case-insensitive flags are listed in upper case.
The next version of FTS-0005 will probably adopt the better V42B
and MNP definitions of the zone 3 nodelist epilog. FTS-0005.003
specifies an implication of V42 by V42B, but the exact meaning of
the flag MNP is unclear. Most probably this flag was meant to
indicate support of MNP 1-4, and in this sense V42B implies MNP.
In zone 2 MNP is considered as redundant, if V42B is flagged or
implied by other flags like H16, ZYX, or Z19.
MN No compression supported
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
XC Bark file requests, WaZOO file/update requests
XP Bark file/update requests
XR Bark and WaZOO file requests
FIDONEWS 14-06 Page 8 10 Feb 1997
XW WaZOO file requests
XX WaZOO file/update requests
These flags are equivalent in FTS-0005 and in the zone 2 segment.
Gx..x Gateway to domain 'x..x'
Valid values for this flag are assigned by the Fido International
Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
only GUUCP gateways are flagged.
#01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
#02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
-> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
#18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
#20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
The variants !01, !02, !08, !09, !18, and !20 indicate missing
Bell 212A support. In zone 2 #02 or !02 would be obviously
redundant.
Today less than five 1200 modems (V22 or Bell 212A) are listed.
A future version of FTS-0005 should drop !mn variants together
with V21 and V22 flags.
Further most non-CM systems flagging #mn or !mn today probably
want to show additional online times instead of additional mail
hours. As soon as FSC-0062 flags have been approved by the IC
or adopted as FTS by the FTSC, the following version of FTS-0005
should mark #mn as obsolescent and recommend the more flexible
FSC-0062 flags (see below).
User flags
----------
An example for one of several problems in zone 2 with user flags:
...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
These flags indicate a modern Zyxel ISDN-modem and two additional
user flags ENC and NEC. This possible user flags string contains
34 characters, but at most 32 characters are allowed in FTS-0005.
...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
During the period for the replacement of old by new ISDN flags
(several months !) many nodes listed both old and new flags for
maximal compatibility, and no problems with nodelist compilers
or mailers caused by too long user flags strings were reported.
Therefore the length limit in FTS-0005 is probably unnecessary
and at least inconsequent: Other nodelist fields like the system
name are unlimited, so why only restrict the user flags string ?
To help developpers an upper limit of e.g. 255 characters for a
nodelist line and 63 characters for fields 3 to 6 would be more
FIDONEWS 14-06 Page 9 10 Feb 1997
useful.
The next problem with user flag strings as specified in FTS-0005
is their introduction by the letter U with no comma following:
Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
and USR. But USR cannot be approved as "real" flag, because the
combination ...,USR,UISDN would then be parsed in SR and UISDN.
Other side effects of the FTS-0005 specification are additional
difficulties in finding flags. Almost all flags are separated
by a comma, only the first user flag can be an exception to this
simple rule. If the order of user flags has no meaning, then...
...,UV120L,V120H
...,UV120H,V120L
... are equivalent. A "simple" solution of this problem could be
to treat UV120L as synonym for V120L, and UV120H as synonym for
V120H. Similar problems show up, if user flags are counted, etc.
Obviously a nodelist compiler looking for user flags has always
to consider the case "user flag separated by comma". In zone 2
this idea was simply extended to the first user flag:
All flags are separated by commas. Flags not yet approved by the
International Coordinator or the FTSC (i.e. user flags only used
experimentally or locally) are separated by a new pseudo flag U.
-> U pseudo flag to the left of at least one user flag
All flags following this pseudo flag U are user flags, all flags
before this pseudo flag are "real" flags specified in FTS-0005 or
approved by the International Coordinator.
Because this definition should be compatible with any reasonable
software implementation based on FTS-0005.003, and simplifies the
handling of user flags significantly, a future FTS-0005 version
will hopefully adopt it.
Approved zone 2 user flags
--------------------------
In zone 2 user flags have to be approved by the Zone Coordinator.
Currently the following zone 2 user flags exist:
-> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
-> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
-> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
-> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
-> X75 ITU-T X.75 SLP (single link procedure),
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
window size W = 2, frame numbering modulo 8;
layer 3 transparent (no packet layer)
-> ISDN Other configuration, used only if none of above fits
FIDONEWS 14-06 Page 10 10 Feb 1997
These ISDN flags follow the specification in FSC-0091.
-> Tyz Online time flags as specified in FSC-0062
The flag Tyz is used by non-CM nodes online not only during ZMH,
y is a letter indicating the start and z a letter indicating the
end of the online period as defined below (times in UTC):
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.
For example TuB shows an online period from 20:30 until 1:00 UTC.
-> Z19 Zyxel series 19200 bps (implies ZYX)
-> K12 Systems offering all educational K12-conferences
-> ENC The node accepts inbound encrypted mail
-> NC Network Coordinator (only if the NC is not the host)
-> NEC Net Echomail Coordinator (at most one per net)
-> REC Region Echomail Coordinator (at most one per region)
-> ZEC Zone Echomail Coordinator (at most one per zone)
Redundant AKAs used to indicate echomail coordination in zone 2
are no longer permitted. One *EC flag is valid for all AKAs of
a given sysop.
Flag implications
-----------------
Flag implications directly or indirectly specified in FTS-0005:
HST => MNP
H14 => MNP HST
H16 => MNP HST H14
V42b => V42 (MNP ?)
V32b => V32
Flag implications specified in the zone 2 nodelist epilog:
HST => MNP
H14 => HST MNP
-> H16 => V42 MNP V42B H14 HST
-> V42B => V42 MNP
-> ZYX => V42 MNP V42B V32B
-> Z19 => V42 MNP V42B V32B ZYX
V32B => V32
-> V32T => V32 V32B
-> V110L => ISDN
FIDONEWS 14-06 Page 11 10 Feb 1997
-> V110H => ISDN
-> V120L => ISDN
-> V120H => ISDN
-> X75 => ISDN
The latter ISDN flag redundancies are a consequence of FSC-0091.
Maybe one of the following implications could be added in zone 2:
VFC => V32 V32B
VFC => V32 V32B MNP V42 V42B
Flag implications (i.e. not listing redundant flags) have several
advantages: Some old nodelist tools are unable to handle too long
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
if they are implied by H16, V42B, V32B, or better. Redundancies
defined globally for the whole nodelist help to avoid flag errors.
"Baud rate" field
-----------------
The former "baud rate" field 7 in the nodelist as specified in
FTS-0005 is nearly useless today: Except from a few remaining
1200 and 2400 nodes almost all nodelist entries show either 9600
for all modem protocols better than V22bis or 300 for ISDN only
nodes. No more V21 or Bell 103 modems are listed today.
Obscure "baud rate" values 19200 and 38400 specified in FTS-0005
have not been used in the FidoNet nodelist. So all a reasonable
nodelist compiler can do today, is treat 300 as indicator for
ISDN only, and treat unknown or missing values in field 7 like
9600.
A new meaning for field 7 as speed field could be really useful.
An example is ZYX, if we would have 16800, 19200, 28800, and 33600
as speed values, then their combination with ZYX is all we need
technically, Z19 would be unnecessary. Another example is HST,
flags H14 and H16 are unnecessary, if HST is combined with 9600,
14400, 16800, 28800, or 33600. Variants of PEP could be shown in
the speed field without new flags. "Enhanced V32.terbo" could be
shown by 21600.
Most important: V34 may have the famous bug not allowing connects
from new "V34+", unless the caller disabled symbol rate 3429. If
"V34+" is indicated by speed 33600, then an appropriate setup for
all kinds of V34 connects is possible.
A future version of FTS-0005 hopefully allows the following speed
values in field 7:
300 reserved for ISDN only (for historical reasons)
1200 V22 or Bell 212A (obsolete)
2400 implies V22bis
9600 default, used with V32, HST, H96, PEP, CSP
12000 rare variant of V32
14400 used with V32b or HST (obsoleting H14)
16800 used with ZYX or HST (obsoleting H16)
FIDONEWS 14-06 Page 12 10 Feb 1997
19200 used with V32T or ZYX (obsoleting Z19)
21600 rare variant of V32T (no "H21" needed)
28800 used with VFC or V34
33600 used with V34 (no V34+ or V34b needed)
57600 used with "X2" clients
The following values should be specified in FTS-0005, because they
are already used in nodelists of other FTNs:
empty no value, useful for Pvt nodes or in point lists
19200 used with V110L, V32T, or ZYX (obsoleting Z19)
38400 used with V110H
57600 used with V120L or "X2"
64000 used with V120H, X75, or other ISDN equipment
Allowing more than 12 speed values or allowing ISDN speeds could
break old software. Therefore the transition could be done in two
steps, first add all non-ISDN speeds (ISDN only shown as 300).
Later remove 300 (ISDN only) and 1200 (obsolete) replacing 300 by
19200, 38400, 57600, or 64000.
Thanks to...
------------
Ben Baker St. Louis nodelist format
Rick Moore FTS-0005.TXT
David Nugent FTS-0005.003 and NLTOOLS
Jonny Bergdahl ERRFLAGS 2.6
Ward Dossche Zone 2 nodelist epilog
Arjen Lentz FSC-0091.001
David J. Thomas FSC-0062.003
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
Jim Barchuk LNDL 2.7
Marius Ellen FASTV7 2.03j (but I still prefer 1.45b ;-)
Jan Vermeulen, Jan Ceuleers, Ian Smith, and many others...
-----------------------------------------------------------------
A reply to "Fidonews, The "lard ass" of newsletters"
By Tony Dunlap, 1:2220/30
I was reading the paper the other day and noticed in the want ads a
Maytag wringer washer for sale for $35.00. There was also an article
with "Your Twelve Favorite Recipes Using Yogurt" (Not that I'd ever
eat anything with a name that sounds like something that had already
been eaten (then disposed of)). Then of course there were the funnies
(most of which weren't), and the bridge column. I am not interested
in any of these things, but I at least glance at them (mainly in hope
of gaining a glimmer of understanding of the deranged minds of people
who would be interested in such things <g>).
The point I am trying to make is that Fidonews is for all members of
FIDONEWS 14-06 Page 13 10 Feb 1997
Fidonet, not just the majority, and if a article is found useful by
just one member, it belongs there.
As for it's size, come on! All of last year's Fnews in their
distrubuted format (LZH and ZIP) will fit on one high density floppy
(Try to store a year's worth of newspapers in that space!)
By the way, just for fun I called about the wringer washer...
It's gone.
---
-----------------------------------------------------------------
Ooh, ow! You wound me!
by Gary Gilmore, 1:2410/400
Well, it seems that it's ok to write something -for- Fidonews, just
as long as you don't -talk- about Fidonews. <sigh> I thought the
"editorial" about my article was a little out of line, but thought
"what the hell, I'll respond". The Fidonews editor's comments are
quoted...
cb> He doesn't say how long he's been around but only refers to
cb> the output of Tees, the previous Editor as example of FidoNews
cb> size past.
Gee, I didn't know that mattered. I guess it's part of a Fido
"elite-ism" of "my board is older than yours, so you're not as good
as me", which I've always found silly. Heck, I've seen BBS systems
that have been up for a month that have floored me, and I've seen
very old BBS systems that were total garbage, so what's the
difference? For what it's worth, my BBS has been in constant
operation since January 9th, 1988. I've been in Fidonet since 1990.
(Somewhere around the summer of that year, if I recall right. My
system was even a Computer Shopper Magazine "BBS Of The Month" for
May of 1991.. not that it means a whole lot in the big picture.
Now, does any of that make my comments more or less valid? <shrug>
I don't think so. We're Fidonet sysops, this is Fidonews, and that
means this is the place where we can comment. ...and our comments
shouldn't be cast aside with editorials trying to make them seem less
valid than the next persons.
cb> Since Tees didn't bother to actively edit FidoNews many times,
cb> it's hardly surprising many of his Issues were miniscule or
cb> Editorial only phosphor padding.
Oh geez... now it's "slag the old editor" time. I find it humorous
that the term "phosphor padding" is used here, when this past issue
contains yet more FTSC bulletins to puff up the S'nooze. Ah well...
cb> FidoNews has been all sizes the past 13 years from 5K to 157K.
FIDONEWS 14-06 Page 14 10 Feb 1997
But I do think the content has varied wildly. Sometimes great stuff,
sometimes nothing but dreck. I know the contributors have the burden
of making Fidonews what it is, but I still don't think intentionally
puffing it up makes it better.
cb> Nobody has to read it; part or all of it.
Very true, and perhaps the more dry it gets, the less it's read.
I can't count the times I've said "Did you read <article name> in
Fidonews?" to some fellow sysops, and they almost always say "Ah, I
never read that thing". Too bad. I do. All the time.
cb> The History and Standards series is part of what FidoNet is and
Sure is! I don't think it needs to be completely reprinted though,
since it's already available elsewhere. Those that really care to
read it will go get it. Those that don't are (to quote myself)
"furiously hitting the page down key" to avoid it, so what's the use?
Got me.
cb> going to keep going this way. There are FIVE FSCs in this Issue.
cb> There are only sixty or so more to go. [grin]
Thanks for the warning! I guess it'll be safe to read Fidonews again
sometime after the next 13 issues if one wants to avoid them. <laugh>
cb> The software list is also an important part of the FidoNews
cb> mission and we all are indebted to Peter Popovich for the
cb> Herculean labors he
Umm, I do believe that I gave credit -and- thanks to Peter. What I
-did- say is that Peter should be given a little break, and only have
to have a listing ready monthly. That's all is really needed, since
software isn't going to change that fast, and if "Brand X" drops
support this week, waiting for a notice 3 weeks from now won't kill
anyone. (And it'll give Peter more time to get good follow up
information on these packages.)
cb> the Echomail weenies flee FidoNet
Echomail weenies? Hmmm.. I don't know what's wrong with echomail,
but you seem to not like those that use it, judging by how many times
you use this phrase in your editorial.
cb> for the apparently greener pastures of Internet mailing lists,
Funny this is here, since you're promoting a mailing list version of
Fidonews. Imagine! <laugh> Indeed, there's more -Internet- promoting
of Fidonews (in the Fidonews) than there is of promoting how to get
it via Fidonet.
cb> Those who can't, get jobs as critics. I'm doing and teaching.
Those that can't take criticism shouldn't be editors, I guess.
Sorry to see you take it so personally, and feel the need to turn to
thinly veiled insults in order to rebut what I've said, Chris.
FIDONEWS 14-06 Page 15 10 Feb 1997
Oh well. C'est la vie.
-----------------------------------------------------------------
FIDONEWS 14-06 Page 16 10 Feb 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing series of FidoNet Standards and
Proposals being published as part of the FidoNet History project. The
individual docs have been reformatted to 70 columns as required.] Ed.
Document: FSC-0034
Version: 002
Date: 30-Aug-90
Gateways to and from FidoNet <tm>
Technical, Administrative, and Policy Considerations
FSC-0034
Randy Bush 30 August 1990
Status of this document:
This FSC contains information of value to the general FidoNet(r)
community. Distribution of this document is subject to the
restrictions listed in the copyright paragraph below.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Copyright 1989-90, Randy Bush. All rights reserved. A right to
distribute only without modification and only at no charge is granted.
Under no circumstance is this document to be reproduced or distributed
as part of or packaged with any product or other sales transaction for
which any fee is charged. Any and all other reproduction or
excerpting requires the explicit written consent of the author.
What is a Gateway to/from FidoNet?
---- -- - ------- ------- --------
A gateway is a collection of software and procedures whereby net mail
and/or echomail may be transferred between FidoNet and another
computer communications network. Gateways are bi-directional, as folk
always want to reply to others' mail.
Gateways exist now.
o There are a number of software packages for gating between uucp-
based systems and FidoNet, the most well-known beingthe UFGATE
shareware package. These packages gate both netmail and echomail,
and are often used to provide FidoNet access to/from Internet via
the uucp network. These tend to go through much effort to make
FidoNet look as much like Internet as possible. As of this
writing, about 25 uucp gateways are scattered around FidoNet.
o Rhodes University has developed a complete system between a Cyber-
based NOS network and FidoNet. This system handles both net mail
FIDONEWS 14-06 Page 17 10 Feb 1997
and echomail, and is also strongly based on the Internet
standards, and almost views FidoNet as a transport mechanism to
get to/from Internet. It is used to gate a fairly localized
cluster of mainframes to FidoNet at a single point, and has made
special arrangements for further routing and forwarding of mail.
o WWIVnet has developed gating software based on the ForDog package
for the MS-DOS-based WWIV systems, and some other package for the
Mac-based Tabby systems. The MS-DOS system uses Binkley or
another FidoNet mailer handles the protocol transfers to make the
WWIV system look like a FidoNet system to other FidoNet nodes.
WWIVnet gates are said to be scattered around the US and Canada.
o A number of FidoNet-based systems have been developed for various
flavors of UN*X. These vary from encapsulated Fido-worlds within
UN*X (i.e not true gates at all), to FidoNet front ends for UN*X
mail systems.
o RBBS-net seems to have developed gateway software for the MS-DOS-
based BBS network, but I do not know enough to characterize it.
All of these gateway systems can and are being run in a safe and
cooperative fashion, and are providing a nice cross-cultural exchange
with benefits for both sides of the gates.
At this time, there are also other nets which, because they are based
on technology similar to FidoNet, are dumping mail onto and taking
mail off of FidoNet willy nilly, with little thought to the technical,
administrative, or social consequences. Often, this is done with good
intentions, not realizing they are providing a disservice to both
nets.
What are the Characteristics of a Good Gateway?
---- --- --- --------------- -- - ---- --------
Like good contracts, good gateways should be fair to both sides.
There is the need to preserve both the technical and sociopolitical
integrity of all parties to the transaction.
Technically, both networks will have specifications and requirements
for transfer protocols, message and echomail formats, control data
files, etc. Beyond the borders of the gateway software, each universe
should be completely and safely maintained.
o Messages and echomail should completely conform in format and
content to the technical specifications of each side of the
gateway.
o Addressing of messages and echomail should completely conform to
that of the network in or through which the messages are traveling
or resident at all times.
o A normal user should be able to enter new messages destined for
the other side of the gate and to reply to gated mail with
relative ease.
FIDONEWS 14-06 Page 18 10 Feb 1997
o If FidoNet uses a network A as an intermediate to get to/from a
network B, or if network C uses FidoNet to get to/from network D,
then the inter-net transitions should be auditable, but local
customs and technalia of the intermediate network may not need
always be enforced. Socially, the customs and fashions of each
network should be maintained in that network.
o There must be administrative liaison and control between the two
networks so agreements may be made and enforced and disputes may
be adjudicated.
o If the networks being gated overlap geographically, then systems
should not have to pay significant costs to move mail between the
two networks when it is between two nodes that are in the same
general locale.
o Gating is not simple, technically or administratively. Unless
each net anticipates significant use of the gateways, and the
anticipated gain is seen as greater than the anticipated pain,
then one side or the other may reasonably decline to do the
necessary work.
What Technical Standards Exist?
---- --------- --------- ------
Before we develop new specifications, social protocols, and standards,
we should see what exists already.
o FidoNet Technical Standards exist already for the data formats and
the communication protocols for net mail and echomail. All
conforming gateway systems mentioned above conform to these
standards. These are named FSC-nnnn, or more recently FTS-nnnn.
o The SRI-NIC has published standards for message formats and
communication protocols that are used between a significant number
of networks that already gate to each other. These are often
referred to as the Internet standards and named RFCnnnn or
IDEAnnnn.
o The ISO and CCITT have standards for message formats and
communication protocols which are used between a significant
number of systems. These
are based on X.nnn specifications, eg. X.400.
Other standards undoubtedly exist and should be investigated by anyone
desiring to build a gateway system.
The game of 'my standard is better than yours' has been played for
decades with no conclusion other then demonstrating the stupidity of
war. What matters is that each net's standards are maintained within
that net.
What Administrative Standards Exist?
---- -------------- --------- ------
Most networks have formed administrative procedures and guidelines
FIDONEWS 14-06 Page 19 10 Feb 1997
which regulate if and how other networks may gate to/from them.
The most notable exception is the uucp/Usenet which, having no
formalized administrative rules for anything else, imposes none on
gateways. Before we recoil in horror, note that uucp/Usenet is three
to four times the size of FidoNet, is over twice FidoNet's age, and
has a significantly better signal-to-noise ratio.
The SRI-NIC provides a procedure for registering Internet domains. A
domain is somewhat like what we are considering a network. This
Internet registration procedure ensures that the network has
o administrative responsibility and control, and
o at least two registered sites which provide address mapping for
the netowrk being gated.
FidoNet is a registered domain of Internet. Our domain is called
fidonet.org. The administrative responsibility is the FidoNet IC's.
The registered 'nameservers' are at lynx.cs.orst.edu and
k9.cs.orst.edu, both at Oregon State University, though this is
bending the two nameserver policy a bit.
DECNET, ARPANET, ... all have applicable standards, but, as they are
strictly limited to formal commercial relationships, they are of
little interest here.
What Administrative Policies are Needed by FidoNet?
---- -------------- -------- --- ------ -- --------
What does FidoNet really need to state in terms of administrative
requirements on a network wishing to gate to/from FidoNet?
FidoNet needs a means of ensuring that a formal relationship exists
which may be used to negotiate technical standards between the two
nets, internet adjudication of disagreements both technical and
social, and enforcement of decisions. Similarly, the other network
will likely want such assurances as well. Therefore an agreement
should be reached stating:
o who is administratively responsible,
o who is technically responsible,
o what technical and administrative documentation exists, and
o both parties will abide by eachother's rules when in the other's
house, and
o how grievances are to be stated and adjudicated.
In addition, it will be advisable for FidoNet to place some
requirements on a network wishing to form official gateways. Some of
these requirements and their motivations are:
o If the other network geographically overlaps a significant portion
of FidoNet, then the other net should be of sufficient size that
FIDONEWS 14-06 Page 20 10 Feb 1997
gateways can likely be recruited in most areas where the nets
overlap. Thus, systems should not have to pay significant costs
to move mail between two nets that happen to be in the same
locale.
o If the other network geographically overlaps a significant portion
of FidoNet, then there should, at a minimum, be gateways in each
FidoNet zone where they overlap.
o If the other network geographically overlaps more than one zone of
FidoNet, then that net should have its own gateways between the
zones, and not use FidoNet to move the burden of interzone PTT
costs.
o If the other network geographically overlaps a significant number
of the regions in a FidoNet zone, then there should, at a minimum,
be gateways in each FidoNet region where they overlap.
o If the other network is geographically localized, then special
arrangements may be made whereby there traffic is gated to/from
FidoNet at one or more places by special arrangement as if the
other network were a FidoNet node or local network (in the intra-
FidoNet sense) itself.
o Gating of net mail, i.e. user-to-user messages, must be
implemented and easily used. Gating of Echomail is optional.
o Mail must be bi-directional. If someone in the other net can send
mail to a node/user on FidoNet, then that FidoNet node/user must
be able to reply.
o If echomail is gated, then, unless special circumstances are
recognized by the responsible administrators, it must be gated bi-
directionally.
o If a conference is moderated (in the Usenet sense, similar to
Dutchie's Conference Mail's moderation or GroupMail) on one
network, then it should be moderated on all other networks, or at
least the gateway into the network where it is moderated should
ensure that correct moderation is done by forwarding or whatever
is appropriate.
For inter-net gateway systems in the process of formation, it is
assumed that some of the above requirements may be waived during a
startup period at the discretion of the administrative bodies.
Observe that if FidoNet were to try to take a shortcut which has been
suggested and simply require Intetnet registration of gating networks,
then, of the current networks gating to FidoNet correctly (see above),
only the Rhodes system could conform technically. Eg. the uucp gating
packages gate to uucp which has no administrative center and is not
registered with Internet. To require Internet registration would
further neither the goals of Internet, nets wishing to gate to
FidoNet, nor FidoNet itself.
What Technical Requirements should FidoNet Place on Gating Systems?
FIDONEWS 14-06 Page 21 10 Feb 1997
---- --------- ------------ ------ ------- ----- -- ------ --------
Each network will have its own specifications for communication
protocols, data formats, message conventions, addressing, etc. Though
more generally used standards are to be preferred, what really matters
is that each net be self-consistent and integritous and that gateway
systems maintain that integrity.
From the FidoNet perspective, the following attributes of a gateway
system seem to be mandatory.
o Conformance to FidoNet message format as specified in current
FidoNet technical standards (eg. currently FSC-0001) must be
maintained while messages are within FidoNet.
o Information to assist message comprehension and processing by
gateway systems and/or other networks may be contained within the
message body, either hidden behind ^A lines or not. If such
information is needed, then conformance to current Internet
standards (eg. currently RFC822) is recommended.
o The FidoNet message header must contain valid FidoNet addresses at
all times the message is on FidoNet. Valid FidoNet addresses are
addresses of specific FidoNet nodes in the current FidoNet
nodelist.
o The source and/or destination address in the other net should be
embedded in the text body of the FidoNet message, either hidden
behind ^A lines or not. Conformance to current Internet standards
is recommended where appropriate, but addressing conventions in
the other net may preclude this.
o A message must contain sufficient information that the originating
system and user may be easily determined.
o A FidoNet sysop and/or normal FidoNet BBS user should be able to
enter messages destined for users in the other network and reply
to gated mail using current FidoNet software.
o If echomail is gated, then the echo messages should conform to all
current FidoNet standards for echomail. For example, currently an
echomail message should:
- have a correct tear line
- have an origin line of the proper format with a FidoNet origin
of the gating FidoNet node
- have seenbys of only FidoNet nodes
- have a path line that goes back at least to the gating node
o If echomail is gated, then an echomail message must contain
sufficient information that the system and user of origin may be
trivially determined, whatever net may have originated it.
o The origin of gated echomail should be determinable in a regular
way sufficient that the gating software can provide easy
construction of private net mail replies to echomail messages
FIDONEWS 14-06 Page 22 10 Feb 1997
which would return to the echo messages's originator through the
appropriate gateway, which may or may not be different than the
gateway through which the echo message came. It is acknowledged
that this may require hand editing on the part of the user
composing the reply.
o If echomail is gated, and the other net has no equivalent, it may
use net mail and/or net mail mailing lists. Messages coming into
FidoNet from this type of net mail or mailing list should properly
gate into the appropriate echomail conference, and replies should
work correctly as well.
Conclusion
----------
It is hoped that, given a philosophy and guidelines such as those
outlined in this paper, FidoNet will continue to expand its links to
other networks to the benefit of FidoNet and networking in general.
It is hoped that this paper will be of some help to those constructing
gateways to/from FidoNet, and to the administrators of FidoNet and
other nets who are considering gating to/from FidoNet.
This paper, the purported facts contained, and the philosophy espoused
are the sole responsibility of the author, and are quite likely
technically incorrect and are undoubtedly morally bankrupt. Should
you have constructive correction or criticism, please contact:
Randy Bush
FidoNet: 1:105/6 1:105/42
Internet: randy@psg.com randy@m2xenix.uucp
uucp: { uunet, qiclab, bucket }!m2xenix!randy
----------
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we
all owe much thanks for the origin and spirit of FidoNet.
DECNET is a trademark of Digital Equipment Corporation.
MS-DOS is a trademark of Microsoft Corporation.
-30-
-----------------------------------------------------------------
FSC-0035
Transparent Gateways to and from FidoNet <tm>
Technical Considerations
FSC-0035
Michael Shiels 22 June 89
Copyright 1989, Michael Shiels. All rights reserved. The right to
distribute for non-commercial use is granted to the FidoNet Technical
Standards Committee, provided that no fee is charged. This may be
posted on FidoNet electronic BBSs which charge no fee for accessing
FIDONEWS 14-06 Page 23 10 Feb 1997
this document. Any and all other reproduction or excerpting requires
the explicit written consent of the author.
Gateways
--------
Gatewaying between Fidonet and other networks seems to be the latest
feature which hopefully brings more benefits to the users of each
network. But there are some real problems with gatewaying and doing
"transparent" replies. This proposal should allow for almost totally
transparent gateways but requires the co-operation of BBS software
writers to support this following protocol.
Incoming Messages
-----------------
When a message is entered into fidonet from another network it will be
entering through one machine (say 1/2). The userid on the other
network may not match very will with the 2 word 36 character userid on
Fidonet. So the following is done to store away the proper userid of
the sender.
Two (2) lines are added to the message (usually at the top of the text
portion hidden by the infamous ^A KLUDGE).
^AREPLYADDR .....\r
which signifies the FULL userid of the person on the other network.
The first 36 characters or the full userid if less than 36 characters
long, are stored in the FROM field of the message header. When
replies are done they use a second line of the following form.
^REPLYTO zone:net/node firstname lastname
which is used to signify the "userid" which mail destined to this
other network must be sent to and on which machine that userids
resides. Replies are sent to this zone:net/node and userid with the
first line of the message being changed into 'TO: ....' where .... is
the FULL userid from the ^AREPLYADDR line.
Should you have constructive correction or criticism, please contact:
Michael Shiels
FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org
uucp: ?!tmsoft!masnet!michael.shiels
Internet: michael.shiels@masnet.uucp
----------
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we
all owe much thanks for the origin and spirit of FidoNet.
-30-
FIDONEWS 14-06 Page 24 10 Feb 1997
-----------------------------------------------------------------
FSC-0036
GROUP MAIL SPECIFICATIONS
by Dale W. Lovell
7:41/34@alternet
1:157/504@fidonet
Group Message Files
A Group Message File is a file which contains messages for a
particular group conference. The file is named as follows:
<id>.xxx
Where:
<id> is the GroupMail ID name
xxx is the minute of the month that the last packet was added
to the file in base 36 (0..9,A..Z). The following
extensions are NOT used ARC, BAT, COM, DOC, EXE, PKT,
TXT. If a packet is created would normally have this name,
the minute is "bumped up" one to avoid using these names.
(This is also the extension used by ARCmail).
Each file can contain several packets of messages. Packets should be
in the Fido type 2 packet. The packets start off with a packet
header. Messages follow the packet header. Each message starts
off with an abbreviated packetized message header. Following the
header are several variable length fields. The structures is as
follows:
struct pkthdrs { /* packet header structure */
int ph_onode; /* Originating node number */
int ph_dnode; /* Destination node number */
int ph_yr,ph_mo,ph_dy; /* Date packet was assembled */
int ph_hr,ph_mn,ph_sec; /* Time packet was assembled */
int ph_rate; /* packet baud rate */
int ph_ver; /* packet version */
int ph_onet; /* Originating net */
int ph_dnet; /* destination net */
int ph_rsvd[17]; /* Reserved for possible future use
*/ };
struct pktmsgs { /* packetized message headers */
int pm_ver; /* message version */
int pm_onode; /* Originating node */
int pm_dnode; /* Destination node */
int pm_onet; /* Originating net */
int pm_dnet; /* Destination net */
int pm_attr; /* Message attributes */
int pm_cost; /* message cost in cents */
};
The variable length data that follows is:
FIDONEWS 14-06 Page 25 10 Feb 1997
Field Description Maximum length (in characters)
Date 20
To whom 36
Who From 36
Subject 72
Message text 8192
The packet is finished when in place of the packetized message header
there are two null characters.
Message Attributes
Message headers contain an integer field holding "message
attributes." These are bit values that select various properties of
the message. They are defined as follows:
#define MSGPRIVATE 0x0001 /* Private message */
#define MSGCRASH 0x0002 /* Crash priority message */
#define MSGREAD 0x0004 /* Read by addressee */
#define MSGSENT 0x0008 /* Sent okay */
#define MSGFILE 0x0010 /* file attached */
#define MSGFWD 0x0020 /* being forwarded */
#define MSGORPHAN 0x0040 /* Unknown destination */
#define MSGKILL 0x0080 /* Kill after mailing */
#define MSGLOCAL 0x0100 /* True if message entered here */
#define MSGHOLD 0x0200 /* true if hold for pickup */
#define MSGX2 0x0400 /* reserved -- sent */
#define MSGFREQ 0x0800 /* Requesting a file */
#define MSGRREQ 0x1000 /* Return Receipt requested */
#define MSGRRCT 0x2000 /* Return Receipt */
#define MSGAREQ 0x4000 /* Request audit trail */
#define MSGUREQ 0x8000 /* Requesting a file update */
The following attribute bits are included in the packetized message
header.
MSGPRIVATE MSGFILE MSGCRASH MSGX2 MSGRREQ
MSGRRCT MSGAREQ
All other attributes are masked off and are not sent to other systems.
Packet files names are as follows:
ddhhmmss.PKT
Where:
dd is the day of the month the packet was created
hh is the hour (24 hour clock) the packet was created
mm is the minute the packet was created
ss is the second the packet was created
For example if a GroupMail file in the conference SAMPLE is created
on the 22nd of a month at 08:15 the Groupmail name would be
SAMPLE.NPR.
21 full days 8.25 hours
FIDONEWS 14-06 Page 26 10 Feb 1997
x 1440 minutes per day x 60 minutes per hour
------- ---------
30240 minutes 495 minutes
+ 495 minutes in today
-------
30735 minutes into the month Convert to base 36: NPR
Note that at most there are 44640 minutes in a month and this naming
scheme has the capability to handle up to 46656 file names. The
remaining names (2015 files or an average of 65 files per day) may be
used for distributing other files in a conference (anything over YG0,
hint if it starts with Z it makes it easy to identify, still leaves
1296 different files or average of 41 files per day).
Disk Directories
GroupMail uses two special directories for distributing it's
files. The first of these directories contains what I will be
calling a group date file and any unprocessed, inbound group files.
The Group Date File is a zero length file in the format:
<id>.!
Where:
<id> is the Group conference name
When new files are update requested, the mailer should only obtain
those files whose time/date stamps are later than this file's
time/date stamp (or any unprocessed group files with a later time/date
stamp).
This directory will be referred to as the Group Inbound Directory.
If a system is holding any conferences for others to update
request, it will need another directory. This directory holds all
processed Group Mail Files. These files can be held for up to 31
days. After a file whose conference is being held for others is
processed, it should be moved to this directory. This move MUST
leave the time/date stamp as it was. If a system deviates this for
ANY reason WOE unto they who wrote the Group Mail processor. This
directory will be referred to as the Group Holding Directory.
Message files
In theory (and almost always in practice) you can store the
processed messages in any format you desire. New messages must be
put into your network mail area as a message your mailer can handle
and send properly to other Fido compatible bulletin board
systems/mailers. The structure of a Fido message is as follows:
struct msghdrs { /* Message header structure */
char m_from[36]; /* Who from */
char m_to[36]; /* to whom */
char m_subj[72]; /* subject of message */
char m_date[20]; /* Date of message */
int m_times; /* Number of times read */
FIDONEWS 14-06 Page 27 10 Feb 1997
int m_dnode; /* Destination node */
int m_onode; /* Originating node */
int m_cost; /* Cost of message in cents */
int m_onet; /* Originating net */
int m_dnet; /* Destination net */
int m_caca; /* extra space */
int unsigned m_rep; /* Thread to previous */
int m_attr; /* Message attributes */
int m_up; /* Thread to next */
};
The header is followed by the text of the message. This text is stored
as a string of characters ending with a null. The text may or may
not contain carriage returns, each of which may or may not be
followed by a linefeed. Any of these carriage returns may be "soft."
If the high order bit (0x80) of the carriage return is set, then it
is a soft return. Line feeds and soft returns should be ignored.
More on the actual messages later on.
Processing inbound messages
For conferences where you are NOT the top star
Unprocessed Group Message Files are in the Group Inbound
Directory. A processor should go through all Group Message Files
which are conferences that the system actually caries (as opposed
to just passing through for other systems). The file's name
should be used to determine for which conference these messages
are destined. While most processors have the first line of text
read as ^AAREA:<id> (no spaces), this is meant for compatibility
to those systems which do not yet have GROUP capabilities. In short,
YOU CAN NOT DEPEND ON IT BEING THERE, so USE THE FILENAME. The
packets should be extracted from the archived message file, put into
your message base. The packet files should then be deleted.
Messages put into your message base from these Group Message Files
should be marked in some way so that they are not processed as
newly entered messages. SEA's GROUP utility uses the message sent
flag for this purpose and we recommend the use of the same flag
wherever possible.
After all Group Message Files have been processed, the Group Date
Files should have their time/date stamp changed to that of the most
recent file processed. Any Group Message Files for conferences
being held for other systems should be moved to the Group Holding
Directory so other systems can request these files. When the Group
Message File is moved, the time/date stamp on the file MUST NOT be
changed. Group Message Files for conferences not being held for
others should be deleted.
It is also desirable at this time to delete any Group Message Files
which are over one month old, or whatever period of time less than
one month the system operator of that board desires.
For conferences where you ARE the top star
FIDONEWS 14-06 Page 28 10 Feb 1997
You should check for any new netmail messages whose ^AAREA:<id>
line is "your" conference ID. These messages should be imported into
your message base with the message sent flag (or your own
equivalent) turned OFF. At such a time as you "PACK" new Group
Message Files you should turn the sent flag ON.
Processing new outbound messages
For conferences where you ARE NOT the top star
Your group processor should scan through all group conferences
on the system and locate any messages which have been entered.
These messages should be prepared to be sent out via network mail.
The first line of the network mail message should read:
^AAREA:<id>
Where:
<id> is the Group conference name
There should be no spaces in this area, although your processor
should be tolerant of any spaces if they are present.
The message should be "from" your address and addressed to your upward
link in the conference. In addition the message should be
marked to be deleted/killed after being sent.
You should also check to see if any messages in your netmail area
from other systems are for a GroupMail conference (either one you
carry, or pass on to other systems). Any of these messages should be
readdressed to your upward link in the conference. Under no
circumstances should you change the from fields, they should contain
the address of the person who entered the message into the
conference.
For conferences where you ARE the top star
Messages should be "copied" from your message base into a properly
named Group Message File. This Group Message File must have a
correct time/date stamp and be in your Group Holding Directory.
Once a message has been copied into a Group Message File, it is
necessary to mark it so the same message is not placed into another
Group Message File. SEA's GROUP uses the message sent flag for this
purpose and we recommend the use of the same flag whenever
possible.
I think that's it. Everything else is handled by your mailer. In
order to get new Group Mail messages, you do a file update request
of the GROUP conference name (<id>.*) with the update pointing to
your Group Inbound Directory. Your mailer will then get any new
Group Message Files from your upward link in the conference. As new
Group Message Files are processed, those who are obtaining their
conferences from you will perform file update requests from your Group
Holding Directory.
-30-
FIDONEWS 14-06 Page 29 10 Feb 1997
-----------------------------------------------------------------
FIDONEWS 14-06 Page 30 10 Feb 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 038
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-010|Nodelist-017|Nodelist-024|Nodelist-031|Nodelist-038|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 10370|10177 -193 |10063 -114 | 9877 -186 | 9729 -148 |34|
| 2 | 15979|15936 -43 |15938 2 |16078 140 |16067 -11 |57|
| 3 | 868| 865 -3 | 863 -2 | 863 0 | 863 0 | 3|
| 4 | 554| 553 -1 | 558 5 | 550 -8 | 549 -1 | 2|
| 5 | 93| 93 0 | 93 0 | 87 -6 | 87 0 | 0|
| 6 | 1073| 1073 0 | 1072 -1 | 1072 0 | 1072 0 | 4|
+----+------+------------+------------+------------+------------+--+
| 28937|28697 -240 |28587 -110 |28527 -60 |28367 -160 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-06 Page 31 10 Feb 1997
=================================================================
NET HUMOR
=================================================================
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)>,
Date: Thu, 30 Jan 97 17:10:22 -0600
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
Subject: From another list....
Famous answers to : "Why did the chicken cross the road?"
-----------------------------------------------------
Plato:
For the greater good.
Karl Marx:
It was a historical inevitability.
Thomas de Torquemada:
Give me ten minutes with the chicken and I'll find out.
Timothy Leary:
Because that's the only kind of trip the Establishment would
let it take.
Douglas Adams:
Forty-two.
Nietzsche:
Because if you gaze too long across the Road, the Road gazes
also across you.
Oliver North:
National Security was at stake.
Carl Jung:
The confluence of events in the cultural gestalt necessitated
that individual chickens cross roads at this historical
juncture, and therefore synchronicitously brought such
occurrences into being.
Jean-Paul Sartre:
In order to act in good faith and be true to itself, the
chicken found it necessary to cross the road.
Ludwig Wittgenstein:
The possibility of "crossing" was encoded into the objects
"chicken" and "road," and circumstances came into being which
caused the actualization of this potential occurrence.
Albert Einstein:
Whether the chicken crossed the road or the road crossed the
chicken depends upon your frame of reference.
FIDONEWS 14-06 Page 32 10 Feb 1997
Aristotle:
To actualize its potential.
Buddha:
If you ask this question, you deny your own chicken-nature.
Salvador Dali:
The Fish.
Darwin:
It was the logical next step after coming down from the trees.
Emily Dickinson:
Because it could not stop for death.
Epicurus:
For fun.
Ralph Waldo Emerson:
It didn't cross the road; it transcended it.
Johann Friedrich von Goethe:
The eternal hen-principle made it do it.
Ernest Hemingway:
To die. In the rain.
Werner Heisenberg:
We are not sure which side of the road the chicken was on, but
it was moving very fast.
David Hume:
Out of custom and habit.
Saddam Hussein:
This was an unprovoked act of rebellion and we were quite
justified in dropping 50 tons of nerve gas on it.
Jack Nicholson:
'cause it (censored) wanted to. That's the (censored) reason.
Pyrrho the Skeptic:
What road?
Ronald Reagan:
I forget.
John Sununu:
The Air Force was only too happy to provide the transportation,
so quite understandably the chicken availed himself of the
opportunity.
The Sphinx:
You tell me.
Sappho:
FIDONEWS 14-06 Page 33 10 Feb 1997
Due to the loveliness of the hen on the other side, more fair
than all of Hellas' fine armies.
Henry David Thoreau:
To live deliberately ... and suck all the marrow out of life.
Mark Twain:
The news of its crossing has been greatly exaggerated.
Stephen Jay Gould:
It is possible that there is a sociobiological explanation for
it, but we have been deluged in recent years with
sociobiological stories despite the fact that we have little
direct evidence about the genetics of behavior, and we do not
know how to obtain it for the specific behaviors that figure
most prominently in sociobiological speculation.
Joseph Stalin:
I don't care. Catch it. Crack its eggs to make my omelette.
Captain James T. Kirk:
To boldly go where no chicken has gone before.
Machiavelli:
So that its subjects will view it with admiration, as a chicken
which has the daring and courage to boldly cross the road, but
also with fear, for whom among them has the strength to contend
with such a paragon of avian virtue? In such a manner is the
princely chicken's dominion maintained.
Hippocrates:
Because of an excess of pleghm in its pancreas.
Peter Hutton:
Because it was cheaper for the company on the other side of
the road.
Patrick Beauvillard:
Sheeken? What Sheeken?
Sacha Mateescu:
A chicken resource of that particular skillset was needed on
the other side of the road.
Andersen Consultant:
Deregulation of the chicken's side of the road was threatening
its dominant market position. The chicken was faced with
significant challenges to create and develop the competencies
required for the newly competitive market. Andersen
Consulting, in a partnering relationship with the client,
helped the chicken by rethinking its physical distribution
strategy and implementation processes. Using the Poultry
Integration Model (PIM) Andersen helped the chicken use its
skills, methodologies, knowledge capital and experiences to
align the chicken's people, processes and technology in support
of its overall strategy within a Program Management framework.
FIDONEWS 14-06 Page 34 10 Feb 1997
Andersen Consulting convened a diverse cross-spectrum of road
analysts and best chickens along with Andersen consultants with
deep skills in the transportation industry to engage in a
two-day itinerary of meetings in order to leverage their
personal knowledge capital, both tacit and explicit, and to
enable them to synergize with each other in order to achieve
the implicit goals of delivering and successfully architecting
and implementing an enterprise-wide value framework across the
continuum of poultry cross-median processes. The meeting was
held in a park like setting enabling and creating an impactful
environment which was strategically based, industry-focused,
and built upon a consistent, clear, and unified market message
and aligned with the chicken's mission, vision, and core
values. This was conducive towards the creation of a total
business integration solution. Andersen Consulting helped the
chicken change to become more successful.
-----------------------------------------------------------------
FIDONEWS 14-06 Page 35 10 Feb 1997
=================================================================
NOTICES
=================================================================
Future History
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
The 20th Century, C.E., is still taking place thru 31 Dec.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
1 Jan 2001
FIDONEWS 14-06 Page 36 10 Feb 1997
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-06 Page 37 10 Feb 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Things over here have been chaotic, so I haven't been able to
reply to my e-mails. I'll be catching up this coming week.
Phased out this week: WildCat! 3.02 and XBBS 1.77
Phase-out highlights:
This week: "Tandy Color Computer 3 (OS-9 Level II)" Section
Deadline for info: 21 Feb 1997.
Last week: "Xenix/Unix 386 -- Other Utilities" Section
Deadline for info: 14 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
----------------------------------------------------------------------
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
FIDONEWS 14-06 Page 38 10 Feb 1997
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
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
FIDONEWS 14-06 Page 39 10 Feb 1997
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
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
----------------------------------------------------------------------
FIDONEWS 14-06 Page 40 10 Feb 1997
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
---------------------------------------------------------------------
MS-DOS Systems Other Utilities Other Utilities
-------------- Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
PKPak 3.61 GMM 1.21 TGroup 1.13
PKZip 1.10 GROUP 2.23 TIRES 3.11
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
FIDONEWS 14-06 Page 41 10 Feb 1997
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
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
FIDONEWS 14-06 Page 42 10 Feb 1997
-------------------- 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
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
FIDONEWS 14-06 Page 43 10 Feb 1997
--------------------
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-06 Page 44 10 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-06 Page 45 10 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-06 Page 46 10 Feb 1997
Zone 5:
============
Zone 6: http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-06 Page 47 10 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-06 Page 48 10 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-06 Page 49 10 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 →