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

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