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

1170 lines
54 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
Volume 7, Number 4 29 January 1990
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| International | | \ \\ |
| FidoNet Association | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief: Vince Perriello
Editors Emeritii: Dale Lovell
Thom Henderson
Chief Procrastinator Emeritus: Tom Jennings
FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1. 1:1/1 is a Continuous Mail system, available for
network mail 24 hours a day.
Copyright 1989 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
We don't necessarily agree with the contents of every article
published here. Most of these materials are unsolicited. No
article submitted by a FidoNet SysOp will be rejected if it is
properly attributed and legally acceptable. We will publish
every responsible submission received.
Table of Contents
1. EDITORIAL ................................................ 1
Sorry about that! ........................................ 1
2. ARTICLES ................................................. 2
A moderated echomail conference processor (pt.1) ......... 2
Third Annual PMFCLP Announced! ........................... 11
3. FOR SALE ................................................. 15
BBS Fax Server for Sysops and Users ...................... 15
CIMN Update .............................................. 18
4. LATEST VERSIONS .......................................... 20
Latest Software Versions ................................. 20
5. NOTICES .................................................. 23
And more!
FidoNews 7-04 Page 1 29 Jan 1990
=================================================================
EDITORIAL
=================================================================
It appears that sometime this weekend my system in Connecticut
decided to take a break from its busy schedules and, well,
"crash" might be the right word.
Now this may not seem like too big a deal, except that I
currently spend most of my time (and in fact reside) in New
Hampshire, where I am now employed. And I was unable to get my
sister on the phone to go see what my little toy computer system
was up to until today.
That's not good. I was really proud of the fact that I got the
FidoNews out by midnight every Sunday. I guess that's the way
things go. But I apologize to anyone who is inconvenienced in
any way by this delay.
I'm also setting up a backup strategy. I have arranged to have a
system which is regularly maintained (meaning its SysOp actually
can and usually does reach out and physically touch it every day)
set up as a routing point for FidoNews submissions and F.Req's.
So there will be a change in the 1:1/1 listing, specifically for
the purpose of assuring that I get stuff for FidoNews on time to
produce it every week --- and also to assure that you will be
able to get that file when you call.
I don't expect this situation to repeat itself. I'm truly sorry
it even happened once.
-----------------------------------------------------------------
FidoNews 7-04 Page 2 29 Jan 1990
=================================================================
ARTICLES
=================================================================
Jack Decker
1:154/9, 11:154/8
A MODERATED ECHOMAIL CONFERENCE PROCESSOR
-or-
MY TWO BITS' WORTH
This article describes a proposed improvement to echomail that
would require only minor modifications to existing software
(but if you want a greater programming challenge, I will make
some additional suggestions later).
HISTORICAL BACKGROUND
A little over a year ago, an alternative to echomail was
introduced called "GroupMail". The original GroupMail program
was designed and released by System Enhancements Associates
(SEA), Inc.
GroupMail offered some advantages over echomail, but also had
some drawbacks. Some of the advantages included fact that
SEEN-BY's did not need to be included in the messages
(considerably reducing the size of messages as transmitted),
that the possibility of generating duplicate messages was
reduced to nil (as long as the conference wasn't ported to or
from echomail!), and that conferences could be fully moderated.
Some of the disadvantages were that conferences could be fully
moderated (some saw this as "censorship"), a separate GroupMail
processor was needed (meaning you had to run two separate
conference mail processors if you wanted to run both GroupMail
and Echomail), conferences were sent via a "File Update
Request" mechanism that some software didn't support, one or
more small packets were sent for each conference (rather than
one large packet containing all conferences - this increased
connect time required to obtain conferences), and GroupMail
packets could only be sent in ARCed format (a more efficient
archiving method, such as ZIP or LHARC could not be used).
Because of these and other factors, GroupMail gained wide
acceptance only in Alternet, and then only in Alternet within
the United States.
One of the reasons that GroupMail may not have gained
acceptance was that it was created by System Enhancement
Associates. At the time of GroupMail's introduction (right
after the conclusion of the infamous SEA vs. PKWare lawsuit),
several sysops in Fidonet expressed a low opinion of SEA... and
a number of sysops felt so strongly anti-SEA that they refused
to use any SEA products, or even carry SEA products on their
boards for downloading. This anti-SEA sentiment probably
caused some sysops to refuse to even consider using GroupMail.
FidoNews 7-04 Page 3 29 Jan 1990
A larger problem, however, was that GroupMail processors were
not available for all the various types of hardware
configurations that are now participating in Fidonet-technology
networks. Thus, in some cases, GroupMail had to be converted
to standard echomail in order to provide feeds to those
systems. For some reason, this conversion process didn't
always work perfectly, with the result that many duplicate
messages were generated at the points where these conversions
took place. Since GroupMail processors were created with the
assumption that duplicate messages could not occur, no dupe
checking was performed by GroupMail processors. Some sysops
abandoned the use of GroupMail due to the number of dupes
created in the GroupMail-Echomail conversion.
Now, suppose that you could have all the advantages of
GroupMail with none of the disadvantages? Would you like to
get conferences without nine or ten lines of SEEN-BY's in each
message? Would you like to get these as part of your regular
echomail delivery, and not have to run additional software
(beyond what you use with normal echomail) to handle these
conferences?
Would you like to participate in moderated conferences, where
the moderator actually has the power to keep the "twits" from
posting messages? (I'll have more to say about conference
moderation vs. "censorship" later).
My proposal (which I'll call "moderated echomail"), in its most
basic form, makes two very minor changes to the way echomail
is currently handled:
1) TWO BITS are reserved in each message header to indicate
whether a message is true echomail, upbound to the moderator's
system, downbound from the moderator's system, or local only.
2) Echomail processors are modified slightly as shown below.
THE ADDED TWO BITS
The first question is, where do we put these two bits, and what
are they used for? Consider a typical message header, which
includes the following information:
MsgHType = Record
fromUser : array[1..36] of Char;
toUser : array[1..36] of Char;
Subject : array[1..72] of Char;
datetime : array[1..20] of Char;
timesRead : Word;
DestNode : integer;
OrigNode : integer;
FidoNews 7-04 Page 4 29 Jan 1990
Cost : Word;
origNet : integer;
Destnet : integer;
DestZone : integer;
Origzone : integer;
filler : Array[1..4] of char;
Backlink : Word;
Attribute : Word;
FwrdLink : Word;
end;
Note that the above header record structure is as used by Henk
Weavers in Dutchie, and includes integers (2 bytes each) for
originating and destination Zone information followed by four
bytes of "filler". Originally, these eight bytes were supposed
to be used for two 32-bit timestamps showing when the user
originally wrote the message, and when the message arrived
on-line (?) but it appears that hardly anyone ever actually
used them in that manner. Unfortunately, we can't count on the
four "filler" bytes being set in any particular manner and
there's always the possibility that someone may actually be
putting a timestamp there.
However, note the "Cost" field above. Virtually no one uses it
in any case, but it's totally meaningless in an echomail
message. Therefore, I propose that top two bits of the second
byte of this cost field be reassigned for use in echomail
messages only (this would NOT change the specification for
netmail at all):
Instead of: Cost : Word;
We'd use: Filler : Char;
EchoMsgType : Char;
Where the echo message type would be defined as follows:
Bits 5-0 Reserved for future use
Bits 7-6 Used as follows:
Bit 6 Bit 7
----- -----
Regular Echomail 0 0
Moderated echomail upbound to moderator 1 0
Moderated echomail downbound from moderator 0 1
Local message 1 1
Note that the above scheme gives us compatibility with existing
echomail, because most echomail processors now simply stuff a
zero byte into this field. So if we are connecting with a
board that doesn't know about this new scheme, we'll still be
able to do regular echomail with them.
FidoNews 7-04 Page 5 29 Jan 1990
A bit of explanation about the four possible message types that
can be indicated by this scheme:
Regular echomail is what we're all getting now. It's totally
unchanged from the present system of echomail distribution.
Moderated echomail upbound travels only in an upbound direction
to the moderator's system. When a message is entered locally,
Bit 6 is set and from there on the message travels upstream
only, and only to one system (your feed for the conference).
Moderated echomail downbound travels only in a downbound
direction to systems that you feed. It is never sent back
upstream to the moderator's system (that would cause dupes).
Local messages never leave the board on which they're posted.
They are simply ignored by the echomail processor. This would
allow the Sysop of a board to post a message to users of a
particular echo (a notice that the echo feed will be
interrupted, or perhaps a permanent post of the conference
rules) without that message being exported to any other board.
MODIFICATIONS TO THE CONFERENCE MAIL PROCESSOR
In the following discussion, I'm going to use a sample fragment
of an AREAS.BBS file, as currently used by ConfMail and several
other programs. All node numbers used as examples are picked
at random for example purposes only.
Lets say that you're getting the FOR-SALE conference from 123/4
and feeding it to 398/2, 321/7, and 234/999. Your entry in the
AREAS.BBS file would look something like this:
D:\MSG\FOR-SALE FOR-SALE 123/4 398/2 321/7 234/999
Now, if the FOR-SALE conference remained as regular echomail,
the above line could remain exactly as shown above with a
moderated echomail processor. It would be treated exactly as
it is today.
But, suppose that it became a moderated conference. In that
case you might use something like the following:
D:\MSG\FOR-SALE FOR-SALE -u123/4 -d398/2 321/7 -e234/999
As you see, switches have been added to indicate that various
nodes are to be treated differently. While each author of an
echomail processor might use a different method to achieve the
same result, I would suggest that a typical echomail processor
might allow the following switches (note that the use of ANY of
these switches [with the possible exception of -a or -p]
indicates that the conference is moderated echomail as opposed
to regular echomail):
FidoNews 7-04 Page 6 29 Jan 1990
-a My address - if used, overrides the defaults in CONFIG.DOG
or MAIL.SYS (or whatever). Use this address when adding an
ORIGIN line or adding to a PATH line in messages in this
conference (if more than one address follows this switch, use
the first in the ORIGIN line but insert all into the PATH line.
Normally there should never need to be more than one address
following this line, but multiple addresses should be allowed
for coping with unusual circumstances).
-d Addresses following are "downlinks" (nodes you feed the
conference to). You may or may not have one or more of these
(unless you're a moderator, then you must have at least one of
these).
-e Feed the conference to these systems as regular echomail.
This switch should not be used unless absolutely necessary, in
order to feed a conference to nodes incapable of running any
moderated echomail processors.
-m This switch is NOT followed by a net/node, but is used to
indicate that YOU are the moderator for this conference. This
is mutually exclusive with -u. You must have at least one node
listed under a -d switch (if you're a moderator, then you've
got to have "downlinks" to feed the conference to!).
-p This switch is NOT followed by a net/node, but is used to
indicate that this conference is "passthru" (not carried on
your system, but passed through to other systems).
-u Only ONE address is allowed to follow this switch, and that
is the address of your "uplink" (your feed) for this
conference.
-x This switch is NOT followed by a net/node, and is only
valid when the -m switch is also used. It indicates that
messages in this conference should be exported any time the
"export" function of the moderated echomail processor is
invoked (normally, messages in conference areas where you are
the moderator would NOT be exported unless a special command
line switch is used, in order to give you time to review the
messages first. This switch overrides that, and indicates that
the messages should be exported any time messages are exported
from the areas that you do not moderate).
The moderated echomail processor should consider any of the
following an error (to aid in dupe message elimination and
detecting improper setup):
* A -d or -e switch is used but a -m or -u is not
* A -m switch is used but no -d switch is used
* A -x switch is used but no -m switch is used
* More than one node is listed after a -u switch
* The same net/node number appears twice in the line
FidoNews 7-04 Page 7 29 Jan 1990
Please note that the above listing of switches is just an
example of one possible implementation. Various software
authors may (and probably will) choose to do things in a
slightly different manner.
Now lets consider how the moderated echomail processor should
handle various situations that may occur.
The first caveat is that any duplicate message checking built
into the echomail processor should be used with moderated
echomail, but keep in mind that moderated echomail WILL pass
through some systems twice (once in the upbound direction and
again in the downbound direction... but note that only a very
small percentage of the total echo traffic will be passed
upbound in most cases). So if you are checksumming parts of
the message header when checking for dupes, be sure to include
the Echo Message Type byte in your calculations (or keep the
data for previously seen upbound messages separate from the
data for previously seen downbound messages). Please note that
the participants of the NET_DEV (Network Software Developers')
echo conference have been trying to forge an agreement on some
type of standardized message ID kludge line that would be used
for duplicate message checking, so you may want to check in
that echo conference (or with the Fidonet Technical Standards
Committee) to determine if any agreement has been reached in
this regard.
Also, a moderated echomail processor should never attach
SEEN-BY lines to a moderated echomail message EXCEPT when
echoing that message to an "echomail only" node as specified by
the "-e" switch. In that case, it should attach a SEEN-BY line
containing its own address (including any AKA's specified in
the CONFIG.DOG or MAIL.SYS file, and/or specified by the "-a"
switch).
A moderated echomail processor should ALWAYS use a Zone number
in PATH line statements (in fact, full four-dimensional
Zone:Net/Node.Point addressing should be permitted in the
PATH). It should not be necessary, however, to repeat
redundant information. For example, a message originating on
1:123/4, going to 1:444/2, then to 1:444/4 and finally to
1:448/7 might have a PATH line that looks like this:
^aPATH: 1:234/4 444/2 4 448/7
The above rule (that the Zone MUST be used) becomes important
when you consider the next duplicate message elimination
feature:
A moderated echomail processor should NEVER send a message to a
node that already appears in the PATH line, under any
circumstances! In order for this to be effective, two
assumptions are made in regard to the PATH line:
FidoNews 7-04 Page 8 29 Jan 1990
1) It contains full Zone:Net/Node[.Point] addressing
information
2) The moderator's system strips the path line (and starts a
new one) before releasing messages to the downbound stream
(note that if this is objectionable, the old PATH line could be
preserved but the kludge line token changed to ^aUPTH to keep
the upbound path line separated from the downbound one).
Let's consider what happens when upbound messages arrive at the
moderator's system. First, the normal dupe checking is
performed. Second, messages are verified as being "good" (okay
to toss into the downbound stream) by the following tests:
1) Does the message have the "upbound" bit set? A message
should never arrive on the moderator's system with only the
"downbound" bit set (if one does, it's probably a dupe and
should not be sent back out!).
2) Is the message flagged as regular echomail? If so, then are
any nodes in the AREAS.BBS file flagged with the /e switch? If
not, it's a bad message, otherwise one of the nodes in the PATH
line should match one of the nodes flagged with the /e switch
(see below).
If the incoming messages meet the above tests, the moderated
echomail processor should change the EchoMsgType flag to
"Moderated echomail downbound" and strip the existing PATH line
from the message (or rename it to ^aUPTH as mentioned above).
A new PATH Line should be started containing the Moderator's
address. The message should then be tossed to the appropriate
message area. Depending on how the system is set up, these
messages could be tossed to the downlinks immediately, or could
be held until the moderator has a chance to review the messages
and cull out any inappropriate ones (this would probably be
controlled by a command line or control file option of the
conference mail processor). In any event, these messages would
be tossed in the same manner as a downbound message sent by any
other node (see below).
At systems OTHER THAN the moderator's system, the following
tests would be performed on incoming messages: First, normal
dupe checking would be performed. Then, the EchoMsgType flag
would be tested, and action would be taken according to the
results of that test:
1) If the message is upbound, any SEEN-BY lines would be
stripped, the system's address would be added to the PATH line,
and the message would be sent ONLY to the uplink (feed) for
that conference. After it has been packed to the uplink, the
message should then be removed from the message area (it will
come back as a downbound message from the moderator's system).
FidoNews 7-04 Page 9 29 Jan 1990
2) If the message is downbound, any SEEN-BY lines would be
stripped, the system's address would be added to the PATH line,
and the message would be sent ONLY to the downlinks (nodes you
feed) for that conference. Note that there are two types of
nodes you might be feeding: Those that take the conference as
moderated conference mail (specified by the -d switch) and
those that take the conference as regular echomail (specified
by the -e switch). In the case of nodes that receive the
conference as regular echomail, a SEEN-BY line will have to be
added containing the system's own address (including any AKA's
specified in the CONFIG.DOG or MAIL.SYS file, and/or specified
by the "-a" switch).
3) If the message is flagged as regular echomail, but is going
into a moderated conference area, then one of the nodes listed
in the PATH line (not necessarily the last one) should be the
same as one of the nodes specified with the "-e" switch in the
AREAS.BBS file. The search should begin with the LAST node in
the PATH line and compared to ALL of the nodes specified with
the "-e" switch. If the LAST node in the PATH line doesn't
match, then the NEXT TO LAST node should be compared, and so on
until the entire PATH line has been searched (in a reverse
direction). If a match is found, then the message is assumed
to be "good" and the EchoMsgType flag should be changed to
indicate that the message is upbound, the SEEN-BY line(s)
should be stripped, and it should be further handled as any
other upbound message (as indicated in #1 above).
The only other consideration is what happens when someone
leaves a message locally, via the BBS or a message editor.
These messages should be flagged as upbound, and have an ORIGIN
line and a PATH line appended (if necessary) and then handled
as in #1 above. Keep in mind that some BBS programs may append
their own ORIGIN, PATH, or SEEN-BY lines which may have to be
stripped or checked for validity.
Please note that there are a couple of peculiarities of this
scheme:
First, you can convert a conference from moderated echomail to
regular echomail, in order to provide a feed to those nodes
incapable of handling moderated echomail. But you simply can't
convert a non-moderated (regular Echomail) conference to a
moderated one at any downstream point. If you receive the
conference as non-moderated, you have to pass it along that
way. This makes sense if you stop and think about it.
Second, if you convert a moderated conference to regular
echomail, the nodes receiving a feed from you will eventually
get back a second copy of any message originating on their
system (or on the system of anyone else that they in turn echo
the conference to). Therefore, they should be prepared to
accept the occasional dupe of their own messages when it comes
back downstream through your system (normally, their dupe
killer will automatically kill it for them). It would be
possible to watch for these messages to come back downstream
FidoNews 7-04 Page 10 29 Jan 1990
and kill them automatically, but that would require a lot of
code and a lot of effort (translation: I can't think of a good
way to do it).
For this reason, it's a good idea to convert moderated
conferences to echomail only for "leaf nodes" (nodes that run
conferences on their own systems but don't feed them to anyone
else) under your system. If "least cost routing"
considerations make it necessary for nodes that you feed as
echomail to in turn feed the conference to someone else, you
should keep a close eye on the topology to make sure that they
aren't feeding the conference back into the network at some
other point (the dupe checking and security measures built into
this scheme make it very unlikely that they could cause a
serious dupe problem, but they could still be running up
someone's phone bill or increasing the amount of time someone
is spending processing echomail).
The above is the basic proposal. Next week I'll discuss an
optional addition (an improvement, I hope!) to the above
scheme.
-----------------------------------------------------------------
FidoNews 7-04 Page 11 29 Jan 1990
* * * A N N O U N C E M E N T * * *
Third Annual Poor Man's FidoCon and Lake Party (in TEXAS)
---------------------------------------------------------
All SYSOPS and their family, pets, and assorted
accoutrements are cordially invited to attend this fine
three-day weekend.
SPONSOR: Net 106 of Houston, Texas and other friends of our
Net.
DATES: April 20, 21, 22. [ The Friday, Saturday, and
Sunday following EASTER. ]
PLACE: Big Creek Park Pavillion (and campsites) on Lake
Sommerville in Burleson County, Texas.
EVENTS: Volleyball; swimming; boating; fishing; other water
sports; chattin'; and eatin'.
SATURDAY PICNIC: pot-luck, do-it-your-way communal feast.
There may be a special treat in-addition to the regular
fare. Come and try it!
BIKE RIDE: Saturday morning Early Bird Tour and Ride through
the Deer Meadow.
CAMPING: Six campsites are with the Pavillion.
There are a good number adjacent to the
Pavillion Point. Well-lit,clean,
maintained restrooms are nearby. Water
is also available; but no electricity at
the Pavillion.
Here are DIRECTIONS to the Region 19 Picnic:
From OKC: Take IH35 thru Dallas or Ft. Worth to
WACO. In Waco,take Hwy 77 to CAMERON.
Go left on TX 36 to CALDWELL. About 10
miles south of Caldwell on TX36 is
LYONS. On the north edge of Lyons turn
right onto FM 60. You should see a sign
for Big Creek Park. Its about 6 - 8
miles from Lyons. Turn left onto the
road to the park.
From Austin: Take US 290 East approx. 89
miles to BRENHAM. At the west
FidoNews 7-04 Page 12 29 Jan 1990
edge of Brenham, turn left
onto TX36 and go north approx.
20 miles thru the town of
SOMMERVILLE to LYONS. Turn
left at the second road which
should be FM 60.
From Dallas: Follow same directions as for OKC.
From Ft. Worth: Follow same directions as for OKC.
From Arkansas: Take IH30 west to DALLAS and
then take IH35 (east) south
and follow the OKC directions.
From Louisiana:
Take IH10 to HOUSTON. Take 'Loop 610 North'
around the edge of the inner city. You'll cross
US 59 and then IH45. Keep going. Take US 290
towards Austin. It's 73 miles to BRENHAM. Follow
the bypass around town. It becomes TX36. Do not
turn to follow US 290 to Austin. Stay headed
North. Approx. 18 miles northeast, you'll pass
thru the town of SOMMERVILLE. There is one motel
here. Continue thru town and over the rise to the
little crossroads berg of LYONS. There are two
places you can turn left. Take the second one.
This should be FM 60. Approx. 8 miles to Big
Creek Park.
From San Antonio:
Take IH35 north all the way to AUSTIN. At the
north edge of Austin, turn right onto US 290.
Follow the Austin directons.
You can cut across on TX 21 at PAIGE. Go to
CALDWELL. Turn south on TX 36. About 10 miles
you'll reach LYONS. At the very edge of Lyons you
should turn right on FM 60. Approx. 8 miles to the
Park which will be on your right.
From El Paso:
Take IH 10 to JUNCTION. About 22 miles east of
Junction take US 290. Follow US 290 north thru
AUSTIN. You'll turn right to the east toward
HOUSTON. Follow the Austin directions.
From All Directions - At Big Creek Park
=======================================
FidoNews 7-04 Page 13 29 Jan 1990
After you enter Big Creek Park, turn right at the
sign directing you to the campground. Tell the
gate attendant that you are with the Houston
Bird/\Dog Society. Follow the campground road
staying to the left at every fork until you reach
the Pavillion.
DETAILS:
LYONS to Big Creek Park turnoff is 3.8 miles. Gate
is 3.3 miles further. Campground is 0.1 mile from
Gate. Restrooms to left just beyond gate. 0.3 mile
from Gate is first fork. Stay LEFT. 0.1 mile to
next fork. Stay LEFT. To right are electric
campsites. Big Rest Rooms at this fork. Also
dumpster. 0.2 mile to Pavillion Point. Open area.
MARINA (one (1) mile from Gate. Deer Meadow.
Brand new building with groceries and ice and
fishing pier.
ACCOMODATIONS:
==============
AT BIG CREEK PARK:
Ample campsites. $8 with water. $10 with
electricity and water.
In nearby locations for those not camping :
AT MARINAS:
Big Creek Marina: 6 cabins with icebox and stove.
No tv. high wood steps. Telephone across road. 3
cabins with _two_ bedrooms and 3 cabins with _one_
bedroom. Reservations must be for TWO nights
whether you stay or not! No credit cards. $5.00
key deposit. Advance deposit of $25.00.
TELEPHONE: 1-409-596-1616
2 - bedroom unit $40.00 per night.
1 - bedroom unit $35.00 per night.
OverLook Park Marina: 6 blue and white cabins.
Single rooms. No steps. Same owners, same
conditions.
TELEPHONE: 1-409-289-2651
FidoNews 7-04 Page 14 29 Jan 1990
1 - room unit $45.00 per night.
SCREEN SHELTERS: $15.00 per night.
CALDWELL:
13.7 miles from LYONS. Surry Inn; Varsity Motel,
and Texan motel (low dive). Two resturants next
door to Surry Inn. Wal-Mart next to Varsity.
Nice grocery stores here! STOCK UP!!!
Interesting METAL SCULPTURE STUDIO on BASTROP hwy.
Check it out. Neat!
BRENHAM:
19.5 miles from LYONS. Preference Inn and (?)
Motel - across from McDonalds on Hwy. 290. Coach
Lite Motel (2 sites) is 1.2 west of Brenham on hwy
290 toward AUSTIN (the Austin folk may want to
stay here!). Judge's resturant, sunday buffet,
bowling alley, etc..
SOMMERVILLE:
3.5 miles from LYONS. One motel on southside of
town. No grocery stores! Several drive-in
markets. FOUR places to eat. 1) D's Diner - 24
hrs. just relocated into larger, newer, formerly
vacant resturant. 2) Schopp's (?) local greasy
spoon in center of town. 3) COUNTRY INN -* best
food* !!! Steaks, club sandwiches, and baked
potatos very popular. Own meat.. hudge pieces!
4) Dairy Queen. Heritage Museum. Nature Museum at
Corp of Engineers Headquarters. Primarily Railroad
with Loading Pens for _cattle_.
Sommerville Motel - 1-409-596-1000
BRYNA/COLLEGE STATION:
Approx. 30 miles east on Tx 60. Many places here,
including a Motel Six.
( Submitted by Net 106, via Justin Marquez, 1:106/100 )
-----------------------------------------------------------------
FidoNews 7-04 Page 15 29 Jan 1990
=================================================================
FOR SALE
=================================================================
Richard Shockey
Fido 1:100/617.6
BULLETFAX <tm> from NUNTIUS
Attention Bulletin Board Operators!
BulletFax - A NEW service for your users!
BulletFax turns your BBS into a FAX server!
BulletFax is a "demand publishing" tool for Bulletin Board
Systems. Callers now have the ability to retrieve documentation
from a BBS that can include extensive graphics. That
documentation is then printed out at the callers fax machine.
There is no need to download a document, load into a word
processor or graphics editor and then print out. The Fax
machine in essence becomes a "remote graphics printer".
With BulletFax, a caller can access an unlimited document
base of information limited only by the size of your hard drive.
BulletFax is particularly well suited for the maintainance and
delivery of large technical document bases or large catalogs of
product or price information in the commercial environment.
Complete text string search facilities are avaiable in
BulletFax. Searches can be made against either file names or
abstracts created when the documents are loaded into the system.
APPLICATIONS ? Well, for starters, how about -
Price Sheets ... Brochures ...
Catalogs ... Stock Info ...
Technical Drawings ... Advertisements ...
Coupons ... Graphics ...
BulletFax is designed with the BBS system operator in mind.
It is easy to install, and documents may be located anywhere on
the system. If you run a BBS, you will find BulletFax easy to
configure.
Extensive security is built into BulletFax, including password
protection and document security protection. Complete call
transactions are maintained, as well as user record logs.
BulletFax may be configured as simply as to allow anyone to fax
documents back to their fax, to as complex as running a fully
secured system where users must be verified before document access
is given.
FidoNews 7-04 Page 16 29 Jan 1990
Documents may be grouped together in different security levels.
There is also a hidden SysOp document function available.
BulletFax can be configured in two ways. With two lines..one for
the bbs and one for the fax card, faxes are transmitted as soon as
the request is made WHILE THE CALLER IS STILL ON LINE.
With a single line the fax transmission begins as soon as the
caller logs off the BBS.
BulletFax uses the Intel Connection Co-Processor. With the
additional use of the Intel 2400b option card, your BBS can be
configured to receive fax transmissions as well.
The use of the 2400b option card also saves on valuable slot space
inside your PC if you use internal modems. Faxable files are stored
on the system in simple ASCII format or in .PCX .DCX file formats.
BulletFax will work with any BBS system that has "Doorway"
capability (drop to dos). It will work with single line versions
of programs like TBBS, FIDO, OPUS, RBBS, Wildcat!, and WWIV.
BulletFax also comes bundled with a registered copy of Marshall
Dudley's DOORWAY program, which you will find useful for your other
Drop To Dos functions.
Nuntius Corporation
Nuntius is a software development firm and complete value added
reseller of computer related fax systems. Nuntius has acted as
consultants to many Fortune 500 companies on the strategic use of
fax throughout the entire enterprise. Nuntius is developing a number
of fax related products for the OS/2 operating system.
Nuntius BulletFax<tm>
Nuntius is currently developing a stand alone version of BulletFax
that will not require the use of a BBS. In addition Nuntius is
developing techniques for the use of Bullet-Fax in Multi-Line BBS
systems. Call for further information and details.
Available now. For more information dial into the Nuntius BBS and
BulletFax demonstration system at (314) 947-7689 12/2400 - N,8,1
FidoNet 1:100/617 or call Nuntius Voice at (314) 768-0109.
PRICE:
BulletFax Program without Intel Connection Co-Processor. $249.00
BulletFax with Intel Connection Co-Processor and all
Connection Co-Processor software. $949.00
Nuntius has other Fax related software products available. We also
offer FaxBack <tm>. This system allows any anyone with a touch tone
telephone and access to a fax machine the ability to retrieve
documents automatically using voice processing technology. For a
demonstration call (314) 947-1710.
FidoNews 7-04 Page 17 29 Jan 1990
Nuntius Corporation
1904 Merrill Drive
St. Charles, MO 63301
FidoNet 1:100/617
BulletFax is a trademark of Nuntius Corporation
FaxBack is a trademark of Intel Corporation
-----------------------------------------------------------------
FidoNews 7-04 Page 18 29 Jan 1990
Computer Information Monthly News!
CIMN(sm)
Copyright 1989, 1990
Beyond my wildest expectations, that is the only way I can
describe the interest in the DISKazine I have created. At
present there are approximately 50 different places around the
United States and Canada who are/have file requested the file.
In addition to this I forwarded a diskette with both Black and
White and the Color program to the Software Distribution Network
coordinator.
I have also received numerous request on how to get a copy
without going through the file request route or from places where
FReq is not practical. In reply to those who are interested
because in some cases you have not left a return address I
provide the following.
Computer Information Monthly News may be obtained by sending
$1.00 US, for one months issue to:
High Mesa Publishing
13 Osage Drive
Los Lunas, NM 87031
I must inform you the CIMN program itself is strictly
FREEWARE, you are not being required to pay for the program. The
$1.00 will be used to purchase:
a. Diskette 1 ea. .50
b. Stamps 1 ea. Some cases 2. .25
c. Labels 2 ea. .10
d. Envelope 1 ea. .10
I realize the above does not come to exaclty one dollar, but
I feel that sending change through the mail is a waste of your
time and mine. An since you may want to receive the next 12
issues of the magazine you may send the amount necessary to cover
the number of issues you would like to receive.
Again I would like to Thank those of you who have FReq'ed
the file and remind everyone it can be file requested 23 hours
per day. The file names to request are:
CIMN.ARC OR ZIP..........COLOR VERSION
CIMNBW.ARC OR ZIP........BLACK & WHITE VERSION
=================================================================
HIGH MESA RANGER'S BBS (301/1) JAKE HARGROVE
HIGH MESA PUBLISHING, 13 OSAGE DR, LOS LUNAS, NM 87031 USA
FidoNews 7-04 Page 19 29 Jan 1990
-----------------------------------------------------------------
FidoNews 7-04 Page 20 29 Jan 1990
=================================================================
LATEST VERSIONS
=================================================================
Latest Software Versions
MS-DOS Systems
--------------
Bulletin Board Software
Name Version Name Version Name Version
Fido 12q+ Phoenix 1.3 TBBS 2.1
Lynx 1.30 QuickBBS 2.61* TComm/TCommNet 3.4
Kitten 2.16 RBBS 17.2B TPBoard 6.0
Opus 1.03b+ RBBSmail 17.2 Wildcat! 2.10*
Network Node List Other
Mailers Version Utilities Version Utilities Version
BinkleyTerm 2.30 EditNL 4.00 ARC 6.02
D'Bridge 1.30* MakeNL 2.20 ARCA06 2.20*
Dutchie 2.90C ParseList 1.30 ARCmail 2.0
FrontDoor 1.99b* Prune 1.40 ConfMail 4.00
PRENM 1.47 SysNL 3.01* EMM 2.02
SEAdog 4.51b XlatList 2.90 Gmail 2.01
XlaxDiff 2.32 GROUP 2.16
XlaxNode 2.32 GUS 1.30*
LHARC 1.13
MSG 4.0
MSGED 1.99
PK[UN]ZIP 1.02*
QM 1.0
QSORT 4.03
StarLink 1.01
TCOMMail 2.2
TMail 1.12
TPBNetEd 3.2
TossScan 1.00*
UFGATE 1.03
XRS 3.10
ZmailQ 1.10*
Macintosh
---------
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
FidoNews 7-04 Page 21 29 Jan 1990
Red Ryder Host v2.1b3 Macpoint 0.91* MacArc 0.04
Mansion 7.12 Tabby 2.1 ArcMac 1.3
WWIV (Mac) 3.0 StuffIt 1.51
TImport 1.331
TExport 1.32
Timestamp 1.6
Tset 1.3
Timestart 1.1
Tally 1.1
Mehitabel 1.2
Archie 1.60
Jennifer 0.25b2g
Numberizer 1.5c
MessageEdit 1.0
Mantissa 1.0
PreStamp 2.01
R.PreStamp 2.01
Saphire 2.1t
Epistle II 1.01
Import 2.52
Export 2.54
Sundial 2.1
AreaFix 1.1
Probe 0.052
Terminator 1.1
TMM 4.0b
UNZIP 1.01*
Amiga
-----
Bulletin Board Software Network Mailers Other Utilities
Name Version Name Version Name Version
Paragon 2.00+* BinkleyTerm 1.00 AmigArc 0.23
TrapDoor 1.11 booz 1.01
WelMat 0.35* ConfMail 1.10
ChameleonEdit 0.10
Lharc 1.00*
ParseLst 1.30
PkAX 1.00
RMB 1.30
UNzip 0.86
Zoo 2.00
Atari ST
--------
Bulletin Board Software Network Mailer Other Utilities
FidoNews 7-04 Page 22 29 Jan 1990
Name Version Name Version Name Version
FIDOdoor/ST 1.5c* BinkleyTerm 1.03g3 ConfMail 1.00
Pandora BBS 2.41c The BOX 1.20 ParseList 1.30
QuickBBS/ST 0.40 ARC 6.02*
GS Point 0.61 LHARC 0.51
PKUNZIP 1.10
MSGED 1.96S
SRENUM 6.2
Trenum 0.10
OMMM 1.40
+ Netmail capable (does not require additional mailer software)
* Recently changed
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 7-04 Page 23 29 Jan 1990
=================================================================
NOTICES
=================================================================
The Interrupt Stack
1 Feb 1990
Deadline for IFNA Policy and Bylaws election
5 Jun 1990
David Dodell's 33rd Birthday
5 Oct 1990
21st Anniversary of "Monty Python's Flying Circus"
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
-----------------------------------------------------------------
FidoNews 7-04 Page 24 29 Jan 1990
OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION
Thom Henderson 1:107/528 Chairman of the Board
Les Kooyman 1:204/501 President
Fabian Gordon 1:107/323 Vice President
Bill Bolton 3:3/0 Vice President-Technical Coordinator
Kris Veitch 1:147/30 Secretary
Kris Veitch 1:147/30 Treasurer
IFNA COMMITTEE AND BOARD CHAIRS
Administration and Finance *
By-laws and Rules John Roberts 1:385/49
Executive Committee (Pres) Les Kooyman 1:204/501
International Affairs *
Membership Services Jim Vaughan 1:226/300
Nominations and Elections Steve Bonine 1:1/0
Public Affairs David Drexler 1:147/30.20
Publications Irene Henderson 1:107/9
Technical Standards Rick Moore 1:115/333
Ethics *
Security and Privacy *
Grievances *
* Position in abeyance pending reorganization
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Courtney Harris 1:102/732 Don Daniels 1:107/210
11 John Rafuse 1:12/900 Phil Buonomo 1:107/583
12 Bill Bolton 3:711/403 Mark Hawthorne 1:107/238
13 Fabian Gordon 1:107/323 Tom Jennings 1:125/111
14 Ken Kaplan 1:100/22 Irene Henderson 1:107/509
15 Kevin McNeil 1:128/45 Steve Jordan 1:206/2871
16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628
17 Kathi Crockett 1:134/30 Dave Melnik 1:107/233
18 Andrew Adler 1:135/47 Jim Hruby 1:107/536
19 Kris Veitch 1:147/30 Burt Juda 1:107/528
2 Henk Wevers 2:500/1 Karl Schinke 1:107/516
3 Matt Whelan 3:54/99 John Roberts 1:147/14
-----------------------------------------------------------------
Reference in New Issue Copy Permalink