     Volume 6, Number 52                              25 December 1989
     +---------------------------------------------------------------+
     |                                                  _            |
     |                                                 /  \          |
     |                                                /|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. ARTICLES  .................................................  1
        News about the ANEWS echo  ................................  1
        SEAlink and Wazoo -- Benchmark Results  ...................  2
        Save money the EASY way!  ................................. 11
        Internetwork Gateway Policy Revisited  .................... 13
        InterNet Relations - A Rebuttal  .......................... 15
        IBM Offers free system Board to 50Z Owners  ............... 16
        Notes on proposed Internetwork Policy  .................... 18
     2. LATEST VERSIONS  .......................................... 25
        Latest Software Versions  ................................. 25
     3. NOTICES  .................................................. 28
     And more!
     FidoNews 6-52                Page 1                   25 Dec 1989


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


        This is just a short note to inform you about the ANEWS echo.
     ANEWS, or News of the US and World, has been in existence for
     about 2 months.  In that time it has grown considerably.

        What is ANEWS?  ANEWS, an acronym for alternative news, is a
     current events/news related echo.  It contains general news
     stories and interesting news items that are either skimmed over
     by the normal media or which are not covered at all.  ANEWS
     contains both national and international stories with emphasis
     on social, labor and environmental issues.  ANEWS stories range
     from single-screen news briefs to articles that are several
     screens long.

        So if you would like some fresh news online, and don't want
     the cost or the blandness of the mass-produced USA Today online
     newspaper, look into ANEWS.  ANEWS averages 40-60 messages per
     week and is available in many parts of the country.  For more
     info contact the ANEWS moderator, Karl Frederick at 1:141/552.

        Area Tag :  ANEWS
        Area Name:  News of the US and World
        Moderator:  Karl Frederick @ 1:141/552

     -----------------------------------------------------------------
     FidoNews 6-52                Page 2                   25 Dec 1989


     Thom Henderson, 520/1015@AlterNet
     System Enhancement Associates, Inc.


                             SEAlink and Wazoo
                             Benchmark Results


     We've  done  many  benchmark  tests  over  the  years.  Obtaining
     accurate  benchmark  data  was  often  an  important  part of our
     consulting practice.  In recent years  we've  done  a  number  of
     benchmark tests of FidoNet-related technology,  and we've usually
     reported the results of those tests  in  FidoNews.  Our  previous
     reported  benchmark compared the SEAlink and Zmodem file transfer
     protocols,  and were reported in FidoNews volume 5,  issue number
     19 (9 May 1988).

     The  purpose  of  that benchmark was to compare the efficiency of
     the actual file transfer protocols  themselves.  The  purpose  of
     our  latest  benchmark  was for the somewhat different purpose of
     comparing two different network mail session protocols:  FTS-0007
     using adaptive SEAlink Overdrive, and Wazoo using Zmodem.

     Since  the  point  of  this  benchmark was to measure the session
     protocols themselves in real-world,  high speed  file  transfers,
     our  tests  all  involved  shipping files over normal voice-grade
     lines using the most recent available  models  of  U.S.  Robotics
     Courier  HST  modems ("14.4" models),  which were loaned to us by
     U.S.  Robotics for this test.  The software employed consisted of
     the latest versions of the two programs most widely considered as
     representative  of the different techniques (SEAdog 4.51b for FTS
     with SEAlink/Overdrive, and Binkley 2.30 for Wazoo).

     It was observed that on all trials the software was  always  able
     to  quickly  saturate  the data channel (which can be observed by
     noting that the transmitting  system  is  being  "paced"  by  its
     modem,  while the receiving system is NOT pacing its modem),  and
     hence  limitations  of  either  particular   implementation   are
     minimal.   Furthermore,   the   data  transmitted  in  all  tests
     consisted of compressed data, which reduced any effects resulting
     from data compression performed by the modems,  while also  more-
     actual data transferred was identical between the  two  different
     programs.


     The first run consisted of having each program send one file,  of
     graduating size,  and  timing  the  total  connect  time  of  the
     telephone  call.  For example,  each program was told to transfer
     one file of 100 blocks (12,800 bytes),  then  each  was  told  to
     transfer  one  file  of  200 blocks (25,600 bytes),  and so on in
     increments of 100 blocks up to a maximum  size  of  2,000  blocks
     (256,000 bytes).  The following data was collected:

     FidoNews 6-52                Page 3                   25 Dec 1989


              Table 1:  One file, increasing size

              Blocks         Wazoo      SEAlink

                 100            30           20
                 200            35           26
                 300            42           36
                 400            50           42
                 500            60           54
                 600            67           58
                 700            75           68
                 800            82           85
                 900           104           81
                1000           100           93
                1100           108           99
                1200           115          110
                1300           126          118
                1400           141          124
                1500           139          133
                1600           149          138
                1700           159          151
                1800           171          156
                1900           179          165
                2000           184          177

         Slope             0.08328      0.08129
         Intercept        18.35789     11.34211
         Correlation       0.99743      0.99847


     The times are given are the total connect time in seconds between
     the sending and receiving system.  These numbers are then treated
     to linear regression analysis (least-squares method) to produce a
     slope  and  intercept.  This  treatment  assumes that the data is
     basically linear, and can hence be expressed with the formula:

              y = Ax + B

     where  "x"  is  the  number  of blocks,  "y" is the time taken in
     seconds,  "A"  is the slope,  and "B" is the intercept.  In other
     words, "A" is the time in seconds to transmit one block,  and "B"
     is the overall session overhead in seconds.  If the data is truly
     linear, then A and B will be constants.

     The degree of fit can be measured by the correlation coefficient.
     The higher this  number  is,  the  better  the  fit  is,  with  a
     coefficient of 1.0 indicating  a  perfect  fit.  The  correlation
     coefficient  for  this data set is better than 99% in both cases,
     so we can be confident that our data truly is linear and that  it
     matches our calculated formulae quite well.  The slightly greater
     deviation  of the Wazoo numbers can probably be attributed to the
     greater complexity of Zmodem causing more variable results.

     FidoNews 6-52                Page 4                   25 Dec 1989


     As can be seen,  a SEAlink-based session is slightly faster  when
     transmitting  data  (0.002  seconds per block,  or 16 seconds per
     megabyte) and has considerably less fixed overhead (7 seconds per
     session).



     For our next run we wished to compare the  per-file  overhead  of
     the  two  protocols.  This test consisted of sending files of 100
     blocks (12,800 bytes).  We told each program to  send  one  file,
     then  two files,  and so on up to twenty files,  and obtained the
     following data:


              Table 2:  Multiple files of 100 blocks each

              Files          Wazoo      SEAlink

                  1             25           15
                  2             39           30
                  3             52           38
                  4             57           49
                  5             68           59
                  6             79           68
                  7             92           81
                  8            100           89
                  9            123           95
                 10            122          108
                 11            132          117
                 12            143          129
                 13            154          138
                 14            170          148
                 15            187          159
                 16            186          167
                 17            196          181
                 18            207          188
                 19            217          201
                 20            231          204

         Slope            10.69774      9.99699
         Intercept        16.67368      8.23158
         Correlation       0.99812      0.99946


     As you can see,  we again have a reasonable  fit  of  formula  to
     reality.  In this situation the slope is of interest, as it gives
     the  time  in  seconds  to transfer one file of 100 blocks.  From
     table 1 we calculate  the  time  required  by  each  protocol  to
     transfer  100  blocks  of data (multiplying the time per block by
     100).  Subtracting that number from the time required to send one
     file of 100 blocks gives us the per-file overhead, as follows:

     FidoNews 6-52                Page 5                   25 Dec 1989


                                            Wazoo   SEAlink

         Time per 100 block file:          10.698     9.997

         Minus time per 100 blocks:         8.328     8.129

         Equals overhead per file:          2.370     1.868


     Thus we can see that a SEAlink-based session takes roughly half a
     second less to  negotiate  each  file  than  does  a  Wazoo-based
     session.


     For  our next benchmark run we tried something a bit unusual that
     had not originally been planned for this  test.  We  included  it
     partly out of curiosity, and partly because we knew that it would
     not  take long to collect the data.  This run was essentially the
     same as the previous run,  except that the file being transmitted
     always  existed on the target system in advance.  Hence,  on each
     and every transfer the receiving system  immediately  "synced  to
     the end" and refused the file.  The following data was collected:


            Table 3:  Multiple files of 100 blocks each, pre-existing

              Files          Wazoo      SEAlink

                  1             13           11
                  2             15           10
                  3             17           13
                  4             19           14
                  5             23           17
                  6             21           17
                  7             26           21
                  8             26           22
                  9             27           28
                 10             29           27
                 11             31           26
                 12             33           28
                 13             34           30
                 14             36           34
                 15             37           33
                 16             42           34
                 17             43           36
                 18             43           40
                 19             45           42
                 20             46           48

         Slope             1.74586      1.80376
         Intercept        11.96842      7.61053
     FidoNews 6-52                Page 6                   25 Dec 1989


         Correlation       0.99480      0.98523
         Crossover        75.3


     In this series Wazoo  showed  slightly  better  performance  than
     SEAlink,  though  with  a  slightly greater deviation in the data
     than we have had thus far.  According to this  series,  it  takes
     about  0.06  seconds  less  to not transmit a redundant file when
     using Wazoo instead of SEAlink.

     We've introduced a new number in this table,  dubbed "crossover".
     This is the value at which  both  methods  will  yield  the  same
     result.  In other words,  if the formulae are correct, then at 76
     such file transfers the  greater  per-file  rate  of  Wazoo  will
     overcome its greater session overhead,  and it will become faster
     overall than a SEAlink-based session.

     We have not reported the crossover  for  earlier  benchmark  runs
     because the data was divergent.  That is, the data indicated that
     under  those  conditions  Wazoo  would never overcome its greater
     per-session overhead.


     This brings us to our final benchmark series, which tests the one
     great strength of Wazoo,  and its only practical difference on  a
     day-to-day basis.  That is, Wazoo uses a much more time-efficient
     file  request  mechanism  than  the file-by-file negotiation of a
     SEAlink-based session.

     This run was similar to our  second  run  in  that  each  session
     involved  the  transmission  of  one  or more files of 100 blocks
     (12,800 bytes) each,  except that during this run the files  were
     requested rather than sent.  In other words, we told each program
     to  request  one  file,  then  two files,  and so on up to twenty
     files.  The following data was collected:


              Table 4:  Requesting multiple files of 100 blocks each

              Files          Wazoo      SEAlink

                  1             27           26
                  2             37           36
                  3             54           50
                  4             66           65
                  5             74           74
                  6             86           94
                  7             95          103
                  8            107          116
                  9            117          129
                 10            132          143
     FidoNews 6-52                Page 7                   25 Dec 1989


                 11            139          155
                 12            153          167
                 13            163          182
                 14            178          197
                 15            183          208
                 16            195          223
                 17            205          243
                 18            220          247
                 19            230          329
                 20            240          274

         Slope            11.13158     14.09098
         Intercept        18.16842      5.09474
         Correlation       0.99952      0.98572
         Crossover         4.4


     From table 2 we can obtain the time required for the transfer  of
     one  file  of  100  blocks,  which then by subtraction yields the
     following:


                                            Wazoo   SEAlink

         Time per file request:            11.132    14.091

         Minus time per 100 block file:    10.698     9.997

         Equals overhead per request:       0.434     4.094


     This  resulted in our only surprise during this benchmark series.
     We knew that Wazoo would have a lower per-request  overhead,  but
     we  had  not  anticipated that the difference would be as much as
     3.7 seconds per request.

     Even so,  one must do five or more requests in a  session  before
     the  difference  can  overcome the greater inherent overhead of a
     Wazoo  session.   We  conclude  that  the  difference  would   be
     significant  primarily in large GroupMail sessions where StarLink
     was not being employed.


     Summation
     =========

     The results of all of this can be tabulated as follows:


                                            Wazoo   SEAlink

     FidoNews 6-52                Page 8                   25 Dec 1989


         Session overhead:                 18.358    11.342

         Time per 100 blocks:               0.083     0.081

         Overhead per file:                 2.370     1.868

         Overhead per file request:         0.434     4.094


     Conclusion
     ==========

     Overall, we find a SEAlink-based session to be far more efficient
     than a Wazoo-based session,  with  the  sole  exception  of  file
     requests.  We would further conclude from this data that the most
     efficient  session  of  all  would  be  a  SEAlink-based  session
     employing the Wazoo file request mechanism  (which  is  certainly
     possible),  since  it  would take advantage of the more efficient
     request mechanism while also enjoying  the  more  efficient  file
     transfer  protocols and lower overall overhead of a SEAlink-based
     session.

     Such a change would not be without cost,  as it  would  sacrifice
     the targeted-request capability of the SEAlink-based file request
     mechanism  (and  in  addition,  for  us  at least,  would involve
     difficulties relating to backwards  compatibility  with  existing
     customers).  However,  it would be quite possible for a mailer to
     honor BOTH sorts of requests -- one for  targeted  requests,  and
     one  for  non-targeted  requests  -- and thus acheive the best of
     both worlds.  Hence,  we intend to move in that direction in  the
     future.  We  can  but  hope that other developers will see fit to
     follow suit.

     -----------------------------------------------------------------
     FidoNews 6-52                Page 9                   25 Dec 1989


                     COMPUTER INFORMATION MONTHLY NEWS
                     =================================

          This  is the Official Announcement of what may very well  be
     the  first  of  it's kind of magazine.   I  have  searched  every
     possible avenue for a like product and have so far been unable to
     find  one.   For several years now I have accomplished a  monthly
     news letter,  well several months ago, I started looking at a new
     approach to the conventional news letter.   I was tired of having
     to  type  them  out or print them out to  a  printer.   An  after
     several  months  of experimentation I developed a  program  which
     is executable on IBM MS-DOS machines.

          This  computer  program offers all the features of a  normal
     magazine in paper form.  Feature articles, special announcements,
     product reviews,  editors corner,  business and BBS advertisement
     screens.   At present there are approximately 200 (79x23) screens
     available  in this magazine.   Another feature is it is  in  full
     color,  from the front page, to the opening index.  A lot of time
     has  gone  into the development of this program and  the  Premier
     Issue Date is currently scheduled for 15 Jan 1990.

          This  program will be offered to Computer Users as FreeWare,
     at  this time there is NO plans to charge a  subscription  price,
     but  this option may very well be exercised in 1991.   Since this
     program is being offered as FreeWare, it is an absolute necessity
     to have a distribution system.  I would like to make this program
     available to as many SysOps and Users as possible.   In doing  so
     it  will cost Me a little extra to dissiminate the program in  an
     ARCED  version  to  BBS's systems.   Since there  are  over  6000
     available  systems I would like to see your help in passing  this
     program around.

          If  you as a SysOp would like to make this program available
     to  your  users,  you may File Request the  Magazine  each  month
     effective  10 Jan 1990 using the file name CIMN-V##.ARC,  with ##
     being the monthly issue (01-Jan,  12-Dec).  If you are a user and
     would like to have access to this Magazine please ask your  Local
     Fido Net Sysop to obtain it.  In some cases I will deliver a copy
     to the Net Coordinator or the Regional Coordinator where the file
     will  be  available  for file requesting.   If you would  like  a
     personal  copy  of this file,  you may also send a  5.25"  floppy
     formatted disk to the address provided below, along with a (SASE)
     for  return,  or  you may call Voice 1-505-865-8386  for  further
     details.

          Remember  this  Program  currently  runs  only  on  IBM   or
     compatable systems, and is Free to anyone interested in obtaining
     a copy.

     JAKE HARGROVE                           HIGH MESA PUBLISHING
     13 OSAGE DR                             LOS LUNAS, NM  87031

     FidoNews 6-52                Page 10                  25 Dec 1989


                     COMPUTER INFORMATION MONTHLY NEWS

                        THE MAGAZINE OF THE FUTURE!

     -----------------------------------------------------------------
     FidoNews 6-52                Page 11                  25 Dec 1989


     I'm going to save YOU money!

     It's very simple, really.  You see, the new Front Door and
     D'bridge versions no longer support SEAlink or BARK requests,
     they supposedly support FTS-0001.

     What does this mean to you?  Well, it means one of two things.
     If you're lucky, your transfer efficiency will ONLY go down to
     about 35% at 9600 baud when one mailer calls another.  *I* was
     one of the UNlucky ones.

     You see, I've been distributing nodelists all over the United
     States and Canada for the past two months, but when the Front
     Door people I called switched to the new Front Door, I found that
     I was unable to send them files.  You know what?  They couldn't
     send me files, EITHER.  The lovely thing is that all these file
     transfers were going on after everyone had gone to bed, so like
     good little mailers, our systems would just keep calling, trying
     desperately to carry out the commands we'd given them, i.e., to
     send the files.

     The way I figure it, the Front Door and D'bridge authors owe me
     some bucks on my phone bill.

     The really wierd thing about all this is that the old versions
     run SEAlink and supported BARK requests really well.  I've got a
     half dozen Front Door people alone calling me long distance every
     night for GroupMail, and THEY have no problems.  So why take the
     support out for a feature that was working?

     Dare we call the reason (Shhh! Say it quietly!)...

     "political"?

     Nah, it couldn't be that, could it?

     Now, here's where I back up my promise.  The way you save money
     if you're running Front Door is to NOT upgrade.  That way you
     won't be calling systems all night and either getting 3500 baud
     thruput on your 9600 baud line or simply calling over and over
     all night long.  The new version will have the SEAlink and BARK
     stuff back in (after all, they promised, didn't they?  They've
     had the spec for a MONTH now...), and you'll have all your other
     bells and whistles, too.

     If you're running SEAdog 4.5 or higher, you can save money this
     way:

     In your XLATLIST control file (or other equivalent software),
     define a class for nodelist flag XX (WazOO update requests only),
     thus:

     FidoNews 6-52                Page 12                  25 Dec 1989


     Class Z XX

     In your ROUTE-DOG file, put the following statements at the end:

     Schedule ALL
              HOLD Class-Z

     That will insure that your mailer NEVER, EVER, calls a Front Door
     or D'bridge system that's going to run up your phone bill.  If
     you're doing echomail with such a system, let HIM call YOU.  If
     he complains about the connections, or multiple calls just say,

     "Hey, I didn't change MY software!  Did YOU?"

     * Submitted by Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet

     -----------------------------------------------------------------
     FidoNews 6-52                Page 13                  25 Dec 1989


     Thom Henderson, c/o 1:107/528
     Chairman, International FidoNet Association


                   Internetwork Gateway Policy Revisited

     I notice in FidoNews volume 6,  issue 51 that a small  group  has
     announced  the creation of a new (and lengthy) Policy Document on
     how internetwork gateways may or may  not  be  done.  Fortunately
     the  proposed  (newly  established?)  policy  meets Tom Jennings'
     criteria of a "good policy".  It is emminently ignorable.

     In essence,  some unspecified group appoints one person to be  in
     charge  of all internetwork gateways.  Said person then regulates
     all gateways  to  ensure  that  they  meet  various  criteria  as
     established  by  the policy document and by the unspecified small
     group.  I suppose this means that the various people now  running
     Usenet  gateways must ask approval and seek certification if they
     wish to continue in their activities.

     Fortunately,  as I said,  it is a very ignorable policy.  If  you
     are  running  a Usenet or othernet gateway,  or if you wish to do
     so,  you can go right ahead  with  no  worries.  The  reality  of
     FidoNet  that  this group seems to be overlooking is that as long
     as  you  have  the  support  of  your NC (or your RC if you're an
     independant), you can do pretty much anything you like and nobody
     can really stop you.

     But the real problem with this policy is  not  so  much  what  it
     says,  as  what  it  implies.  It  implies  that  there  is  some
     unspecified group with no apparent mandate or means of  selection
     who are somehow empowered to make decisions on behalf of FidoNet.

     It  should  be  obvious  by  now  that  I don't really think that
     unspecified groups like that are a good idea.  I got  roped  into
     one  once  (the  original "interim board" of IFNA),  but our very
     first acts were directed at converting  our  "unspecified  group"
     into  a  VERY specified group with a democratically elected Board
     of Directors with a known mandate to operate  on  behalf  of  the
     FidoNet sysops (and somehow I've wound up STILL working on that!)


     The  test  has been set.  With much discussion and some disagree-
     ment here and there,  but with general consent overall as near as
     I  can  tell.  Any group or organization that wishes to represent
     itself as "speaking for FidoNet" must  first  obtain  a  positive
     mandate from the majority of FidoNet sysops.  Passive "no voters"
     count as a "no",  because if the majority does not see a need for
     a central organization,  then there should not be  one.  IFNA  is
     undergoing  this  test.  As I write this,  the referendum is over
     and the votes are being tallied.  By the time you read  this  the
     totals should be published.

     FidoNews 6-52                Page 14                  25 Dec 1989


     One of two things will happen:

      1) IFNA  will  receive  a mandate,  in which case this "proposed
         policy" will be subject to review by all FidoNet  sysops  and
         must  meet  with  their (your) approval before it can go into
         effect.

      2) Or IFNA will not  receive  a  mandate,  in  which  case  this
         "unspecified  group"  must seek its own mandate before it can
         presume to speak on behalf of FidoNet.

     This goes below the level of voting on policy.  Before anyone can
     set ground rules for how a policy  can  be  approved,  they  must
     first have the authority to establish policy approval procedures.

     -----------------------------------------------------------------
     FidoNews 6-52                Page 15                  25 Dec 1989


     Date: 20 Dec 89 21:17:20
     From: Walter Tietjen on 151/114
     To:   Tim Pearson on 286/703
     Subj: FidoNews Article

     Original  in  netmail  - Copy to Vincent P. (1:1/1) for inclusion
     in FidoNews

     Isolation of the various  political  networks  _WON'T_WORK_!!  It
     can make an accidental echomail `circular feed' _WORSE_

     _ANY_  `circular  feed'  in  echomail  causes duplicate messages.
     With full FidoNet/AnyOtherNet combined seen-bys  and  path-lines,
     the  duplicates  caused  by the `circular feed' are restricted to
     the nodes in the closed loop of the `circular feed'.

     With pure seen-by stripping at  "approved  inter-net  echo-gates"
     the  duplicates originally caused by a `circular feed' are spread
     to nodes _OUTSIDE_ the closed loop of the  `circular  feed'.  The
     path-lines  if  left intact still provide some limited ability to
     manually trace & eliminate a circular feed.

     If _BOTH_ the seen-bys and path-lines are stripped-out, there  is
     _NO_  method  left  available  to  track  down  a  circular  feed
     involving dual-ID nodes which through accident  receive  an  echo
     from both sides of an internet echogate.

     ALTERNATIVE PROPOSAL:

     _ALL_ FTSC-compatible networks shall draw their "Net" numbers (of
     <Net>/<Node>)  from  a _COMMON_ number pool thus insuring that an
     AnyOtherNet address will _NOT_ interfere with  echomail  delivery
     within FidoNet.

     Future  agreements  between  different  FTSC-compatible  networks
     should  address  the  fair  &  equitable  sharing   of   echomail
     distribution  cost  between  multiple networks participating in a
     shared echo.

     Re: Private netmail replies to echomail messages:

     By the use of "private" nodelists an  artificial  `zonegate'  can
     easily  be  set-up between the pure-FidoNet nodes in a local area
     and a dual-ID system in the same  local  area  who  maintains  an
     address in the target AnyOtherNet.

     -----------------------------------------------------------------
     FidoNews 6-52                Page 16                  25 Dec 1989


     IBM Offers free system Board to 50Z Owners

     Recently, certain users of the IBM Model 50Z PS/2 computer have
     encountered problems using software which bypass the computer's
     BIOS and attempt to send data to a serial port, according to
     Cheryl Butcher, an IBM systems engineer in West Lafayette, Ind.
     IBM has acknowleged the existance of a bug in the system board
     which will halt the output process and leave users with a
     useless machine.

     The bug causes problems in use with such programs as Microsoft
     Corp.'s Windows and Lotus Development Corp.'s Symphony by
     keeping the software from properly accessing the PC's serial
     port.  IBM is offering a free replacement system board to users
     who encounter this problem.

     IBM has issued an engineering change for its IBM Model 50Z BIOS
     to correct the problem in new machines, and has offered to
     replace defective system boards thru December 31st, 1989.

     Users of Microsoft's WORD 5.0 will also notice the problem,
     which is how IBM originally became aware of the bug.  "Microsoft
     WORD 5.0 worked fine on all of our other machines except the
     Model 50Z," said Bruce Fuller, and electrical engineer at Purdue
     Universeity.  "The only work around was to use WORD 4.0, which
     is really not a solution."

     IBM will replace system boards that qualify according to the
     following chart:

     The machine must have the following:

      o Module ZM41 (located in the center of the system board) is
     marked with part number 05fox3628.

      o The serial number is one of the following:

      Model 50Z 31:                   Model 50Z 61:
      23-7134521                      23-7634866
      72-7072052                      55-6667427
      78-4223666                      72-7617500
      90-5011650                      78-4704505
                                      90-5602521

     Users whose machines do not qualify for the system board
     replacement should contact the software developers for patches,
     Butcher said.

     IBM officials recommend that users get in touch with their local
     IBM representative for further information and assistance.

     FidoNews 6-52                Page 17                  25 Dec 1989


     * Submitted by Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet

     -----------------------------------------------------------------
     FidoNews 6-52                Page 18                  25 Dec 1989


     Jack Decker
     1:154/9, 11:154/8

     NOTES ON THE PROPOSED INTERNETWORK GATEWAY POLICY DOCUMENT

     In Fidonews 651 an article by Tim Pearson of 1:286/703
     appeared, which described and presented a draft of an
     Internetwork Gateway Policy document.

     I would just like to point out a few observations on this
     document.  If past experience holds, most of this will fall on
     deaf ears.  It seems most sysops tend to ignore net politics
     until it's their node number going down the tubes, at which
     point they are pretty powerless to do anything about it.  Well,
     if that's what you want, fine.  Just don't act so surprised
     when you are on the outside looking in.

     Now the question we should be asking ourselves is whether this
     proposed policy will enhance communications, or inhibit them?
     Most of us joined Fidonet because we wanted to be able to
     communicate with a maximum number of people.  A policy that
     inhibits communications may stroke the egos of a few who wish
     to be "in control", but it doesn't benefit most sysops within
     the net.

     The first thing to notice is the proposed method for adoption
     of this document: "It is our intention to allow 30 days for the
     receipt of input from the network at large.  After that, the
     final draft will be presented to the International Coordinator
     for adoption."

     Now you'd think that folks would by now realize that many
     Fidonet sysops are totally opposed to the "control from on
     high" operation of Fidonet.  You have the opportunity to
     comment, but do you have the right to say "I don't think there
     is any need for this policy at all?"  Probably not.  If you
     suggest changes, the Gateway Policy Development Committee may
     decide to incorporate your suggested changes, or they may not.
     But if you tell them "I sincerely fail to see any need for such
     a policy, and would prefer that it not be adopted", I wonder if
     they would listen?

     Keep in mind that the "members of the Gateway Policy
     Development Committee include: Bill Bolton, Steve Bonine, Randy
     Bush, David Dodell, Rick Moore, Tim Pearson, Vince Perriello,
     Tim Pozar, and Matt Whelan."  Now I'm not saying that any of
     these folks are bad people.  In fact, I think most of them have
     a vision of what Fidonet should be, and they think it's a good
     vision.  The problem is that in my experience, the vision of
     some of these folks as to what Fidonet should be is almost 180%
     degrees removed from what most of the "common sysops" I have
     spoken to want from Fidonet.  If you are familiar with the
     names in the above list, you probably know what I'm talking
     about.  With a couple of exceptions, most of these folks have a
     vision of Fidonet that is controlled from the top down, with
     the individual sysops having almost no say in how the net is
     FidoNews 6-52                Page 19                  25 Dec 1989


     operated.  I'm sure that in their own minds, they are convinced
     that this is the best way to "run a railroad", but others might
     disagree (by the way, for what it's worth, you will notice that
     Tom Jennings, the founder of Fidonet, is not on the above
     committee.  I've noted that he generally seems to not approve
     of these efforts to exert additional political controls over
     those using Fidonet technology).

     Now rather than simply take snipes at the people involved in
     this proposal, I'd like to point out some problems with the
     proposal itself.  Some of these problems also exist in Policy4,
     by the way.

     The first is that any time we get into domain gating (which is
     what's really being proposed here), we are talking some major
     software changes in the network.  Or else we are talking about
     having users add addressing information to messages manually,
     or both.  In this proposal it appears that we are talking both,
     since not only will software be required to change addressing
     information at the domain gates, but users will be expected to
     add certain addressing information within the text of the
     message itself.  Folks, we're adding a lot of additional
     complexity to the network here.  Many sysops are of the opinion
     that we should "Keep It Simple, Stupid" but there are a few
     wannabe Usenet administrators in our net who would like to turn
     Fidonet into a very technically complex network.  If we gain
     some real benefits from increased complexity, then the benefits
     may outweigh the problems.  But where are the benefits to the
     average sysop here?

     The power players in Fidonet have continuously and deliberately
     ignored the simplest solution to the perceived problems...
     assign each "FidoNet Technology Network" (FTN) a block of net
     numbers for their use.  Thus, within Zone 1, you know that any
     net with a number between 100 and 399 (or in the 3xxx range) is
     in Fidonet, while numbers from 400 to 799 are in Alternet, and
     so on.  It would be much easier to formalize an addressing
     agreement between the other networks than to go through the
     hassle of setting up domain gates, and that would not break
     existing software, and would allow sysops to send mail to other
     networks with a minimum of hassle.

     The one thing we all agree on is that Zonegating (to alternate
     networks) doesn't work... but if we go to "domain gates", we
     will have many of the same problems we have with Zonegates.  "A
     rose by any other name"...  However, instead of going for a
     less complex, more easily implemented solution, the proposal
     introduces even greater complexity.  Why?  Well, I submit that
     it's because the great complexity, while doing little or
     nothing to advance communications, does allow a certain few to
     exert greater amounts of control over the network.  Control
     over what?  Well, consider the following paragraphs from the
     proposal:

     FidoNews 6-52                Page 20                  25 Dec 1989


          "FidoNet is now gated into Internet via UUCP.  It has
     agreed to the terms and conditions necessary for membership in
     and connectivity to the Internet multi-network "umbrella".  One
     obvious method for achieving connectivity to FidoNet (and a
     whole host of other wide area networks) is for the Other
     Network to apply to Internet for a gateway.  Under this
     scenario, the Other Network is bound by the terms and
     conditions of Internet just as FidoNet is.  In this peer
     relationship, the terms and conditions stated in this document
     are used by FidoNet to determine if Other Network message
     traffic arriving at a FidoNet/Internet gateway will be accepted
     into FidoNet."

     Now please note that in the above paragraph, it seems to be a
     given that Fidonet cannot dictate the terms and conditions
     under which it will accept messages from the Internet.  That
     makes sense... Internet has been around a lot longer and is a
     lot larger, and quite frankly, many of the folks in Internet
     couldn't care less whether Fidonet is tied in or not.  But if
     you read the above carefully, something else is being stated
     here.  That is that if another network obtains connections to
     the Internet quite independent of Fidonet, and follows all the
     rules, regulations, terms and conditions of Internet, Fidonet
     may still elect to refuse message traffic based solely on the
     originating network.  Who wants to bet that this provision
     would first be used to exclude traffic that originated on
     another FTN network?

     Actually, this whole document hold forth different standards
     for interconnection between a "FidoNet Technology Network"
     (FTN) and "All Other Networks" (see sections 3.6 and 3.7).

     Section 3.7 states:

     "3.7 - Other Criteria (FTN Other Networks)
     -----------------------------------------
     Software allowing nodes in FTN Other Networks to simultaneously
     participate directly in FidoNet as valid FidoNet nodes,
     isolating the Other Network's addresses from FidoNet message
     traffic (i.e., using only valid FidoNet addresses in FidoNet
     message traffic) presently exists.  This 'dual identity'
     approach is the method FidoNet expects nodes in the FTN Other
     Network will employ....."

     In other words, if you are running FTN software you are
     expected to have a Fidonet net/node number and to use it,
     rather than the address of your primary network.  No mention is
     made of what you are supposed to do if you can't get a Fidonet
     node number (for example, if you want to be a private, unlisted
     node, since many of these have recently been excluded from the
     Fidonet nodelist).

     FidoNews 6-52                Page 21                  25 Dec 1989


     More from section 3.7:

     ".....the FTN Other Network must provide evidence of overriding
     technical or social considerations, must show cause why these
     considerations justify the establishment of a Gateway instead
     of merely allowing its individual nodes to use the 'dual
     identity' approach, and must satisfy FidoNet that such an
     arrangement will be mutually beneficial."

     And add in section 5.1:

     "5.1 - Interpretation
     --------------------
     FidoNet retains the exclusive right to interpret the terms and
     conditions stated herein based upon its representatives' best
     understanding of those terms and conditions and upon its
     knowledge of the original intent of the authors."

     What we have here is Fidonet saying, in effect, that if you
     choose to use FTN software, you had better join Fidonet and use
     your Fidonet net/node number (and if for some reason you can't
     get one, you can always take up stamp collecting, I guess).
     Curiously, this only applies if you are using FTN software.
     This could actually encourage software authors to make their
     software slightly NON-FTSC compliant, so that users of that
     software could rightly claim that they are not in an "FTN Other
     Network" and obtain Gateway status on more favorable terms.

     Then there's section 3.4:

     "3.4 - Application of FidoNet Administrative Policy
     --------------------------------------------------
          For the purposes of applying FidoNet policy, FidoNet will
     view the entire Other Network as a single FidoNet 'node' under
     the control of the individual named as the 'Administrative
     Contact / Responsible Party' (or an authorized agent thereof)
     in the administrative agreement outlined in paragraph 3.3
     above.  All other systems and their users will be viewed by
     FidoNet as users on the 'responsible party's' node for the
     purposes of FidoNet official policy application.

          FidoNet holds the operator of a FidoNet node responsible
     (from an administrative policy standpoint) for the actions of
     that node's users, subordinate 'point' systems, and the 'point'
     system's users.  FidoNet views single or multiple Other Network
     Gateways as a single 'boss' node under the control of the
     'responsible party' and will apply FidoNet official policy
     accordingly.  FidoNet reserves the right to sever links to one
     or more of the Other Network's Gateways as its final remedy for
     violations of administrative policy....."

     FidoNews 6-52                Page 22                  25 Dec 1989


     I think the bottom line here is that we have a classic case of
     what is termed "Imperialism" when nations are involved.
     Basically, we have a large entity (Fidonet) saying that it will
     not participate as an "equal" in the "global community" (except
     in relationships with entities of larger size and status) but
     that rather feels that it should be able to set policies for
     smaller entities on a "take it or or leave it" basis... and the
     "take it" option in this case looks more like a takeover!

     It is my opinion that some (NOT all) of the folks on the
     "Gateway Policy Development Committee" still view the alternate
     networks as some sort of a "cancer" that should be cut out of
     electronic networking.  But, as I pointed out in a recent
     message in the SYSOP echo, "We need more than one viable
     network that uses Fidonet technology.  What do you suppose
     would happen if the Democrats and the Republicans (or the
     Liberals, PC's, and NDP's for those of you in the Great White
     North) were all merged into one political party?  There would
     be so much infighting that nothing would ever be accomplished.
     Even our churches have found the need to divide into groups of
     like-minded people rather than constantly bicker over minor
     points of doctrine. So why do we, in a hobbyist communications
     network, think that we can force sysops who hold widely
     divergent views on how a network should be operated into one
     mold?

     "Rather than look upon alternate networks as an enemy of
     Fidonet, as something to be harassed and suppressed, you should
     realize that this is a place where those who don't agree with
     you can go and leave you (and those who agree with you) alone
     to get on with life.  It never ceases to amaze me that folks
     who in one breath say that the Fidonet nodelist is getting too
     large and who are all for cutting out certain classes of nodes
     (private nodes, etc.) will nevertheless turn around and
     participate in the harassment, or the attempts to 'shun' those
     in other nets.  They don't realize that these nets COULD be the
     SOLUTION to the problem, rather than the problem itself."

     There is one other section of the proposed policy that deserves
     some attention:

     "3.5 - Supported Message Types
     -----------------------------
          FidoNet will grant Gateway interconnection for the
     purposes of exchanging messages of the type defined above as
     'Netmail' and optionally for the purposes of exchanging
     messages of the type defined above as 'Echomail'.  FidoNet will
     not grant Gateway interconnection for the purposes of
     exchanging 'Echomail' only.  The ability to generate a private
     and personal 'Netmail' reply to an 'Echomail' message is one of
     the basic facets of FidoNet and cannot be compromised."

     FidoNews 6-52                Page 23                  25 Dec 1989


     If you believe this, I've got a nice bridge to sell you...

     Maybe this is how things should be in Fidonet, but that is not
     how they work now, at least not in Zone 1.  I'll have more to
     say on this subject in an upcoming article, but for the
     purposes of this discussion, let me ask a couple of questions:

     1) If I'm in an alternative network that has a "Gateway" with
     Fidonet, will I be able to just dump all my Netmail on the
     Fidonet Gateway and let the Gateway operator worry about
     sending it anywhere in Fidonet?  Will anyone in Fidonet really
     want to become a Gateway if they have to send Netmail their own
     expense?  Why should those in alternate networks have access to
     such a "one stop" delivery point for Fidonet Netmail when those
     who are in Fidonet enjoy no such privilege (except those
     fortunate enough to be on one of the few nets that have
     OGATEs)?

     2) If Fidonet does NOT expect its "Gateway" systems to deliver
     Netmail anywhere in Fidonet, then why do they expect the
     smaller alternative networks to provide this capability?  The
     smaller the net is, the more of a burden this could become.
     Also, this requirement could subject an alternate network
     Gateway to what would amount to "terrorist tactics" by someone
     in Fidonet, who could send large amounts of Netmail traffic to
     the Gateway and require the gateway node to either deliver or
     return it at his expense.

     It is a well known fact to just about every sysop in Fidonet
     that most sysops are in Fidonet to receive echomail, and could
     care less if Netmail service disappeared tomorrow.  But the
     select few who do use Netmail regularly have made something of
     an idol out of it, and refuse to recognize that most of the
     sysops that have joined Fidonet in the last 2-3 years just
     don't care about Netmail.  Fine, but if they are so concerned
     about Netmail, let them come up with a Netmail distribution
     scheme that WORKS, instead of trying to convince everyone that
     Netmail is so all-fired important by mere words.  In the
     meantime, I feel that this particular section is totally
     inappropriate in this document.

     There's a lot more that I find objectionable in this document,
     but I fear I'm probably already pushing the limits for length
     of a Fidonews article.  I hope it's never adopted, or failing
     that, that it undergoes some pretty serious revision first,
     preferably by some folks who do not believe that Fidonet is at
     the center of the universe.

     Since I am probably spitting into the wind anyway, I will just
     offer a few suggestion to those in the alternate networks:
     Begin linking conferences with each other!  Stop depending on
     the Fidonet backbone for all your echomail traffic.  Start
     listing your nodes in the OPCN nodelist so you can communicate
     with each other if you find yourself locked out of Fidonet
     (contact 1:234/1 or 1:236/7 for information).  Develop your own
     independent links into networks such as Internet and Usenet.  I
     FidoNews 6-52                Page 24                  25 Dec 1989


     will be truly amazed if anyone actually heeds these warnings,
     but at least I tried...

     -----------------------------------------------------------------
     FidoNews 6-52                Page 25                  25 Dec 1989


     =================================================================
                              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       2.0    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
                                                   UFGATE        1.03
                                                   XRS            3.0
                                                   ZmailQ        1.09

                                 Macintosh
                                 ---------

     Bulletin Board Software   Network Mailers     Other Utilities

     Name            Version   Name      Version   Name       Version

     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
     FidoNews 6-52                Page 26                  25 Dec 1989


                                                   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

     Name            Version   Name      Version   Name       Version

     FIDOdoor/ST        1.4f*  BinkleyTerm 1.03g3  ConfMail      1.00
     Pandora BBS       2.41c*  The BOX     1.20*   ParseList     1.30
     QuickBBS/ST        0.40                       ARC          5.21c*
     GS Point           0.61                       TurboArc       1.1
     FidoNews 6-52                Page 27                  25 Dec 1989


                                                   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 6-52                Page 28                  25 Dec 1989


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

                          The Interrupt Stack


     30 Dec 1989
        Telephone area codes (5, 3 and 0) are abolished in Hong Kong

      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 6-52                Page 29                  25 Dec 1989


             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

     -----------------------------------------------------------------
     FidoNews 6-52                Page 30                  25 Dec 1989


                                      __
                 The World's First   /  \
                    BBS Network     /|oo \
                    * FidoNet *    (_|  /_)
                                    _`@/_ \    _
                                   |     | \   \\
                                   | (*) |  \   ))
                      ______       |__U__| /  \//
                     / Fido \       _//|| _\   /
                    (________)     (_/(_|(____/ (tm)

            Membership for the International FidoNet Association

     Membership in IFNA is open to any individual or organization that
     pays  a  specified  annual   membership  fee.   IFNA  serves  the
     international  FidoNet-compatible  electronic  mail  community to
     increase worldwide communications.

     Member Name _______________________________  Date _______________
     Address _________________________________________________________
     City ____________________________________________________________
     State ________________________________  Zip _____________________
     Country _________________________________________________________
     Home Phone (Voice) ______________________________________________
     Work Phone (Voice) ______________________________________________

     Zone:Net/Node Number ____________________________________________
     BBS Name ________________________________________________________
     BBS Phone Number ________________________________________________
     Baud Rates Supported ____________________________________________
     Board Restrictions ______________________________________________

     Your Special Interests __________________________________________
     _________________________________________________________________
     _________________________________________________________________
     In what areas would you be willing to help in FidoNet? __________
     _________________________________________________________________
     _________________________________________________________________
     Send this membership form and a check or money order for $25 in
     US Funds to:
                   International FidoNet Association
                   PO Box 41143
                   St Louis, Missouri 63141
                   USA

     Thank you for your membership!  Your participation will help to
     insure the future of FidoNet.

     Please NOTE that IFNA is a general not-for-profit organization
     and Articles of Association and By-Laws were adopted by the
     membership in January 1987.  The second elected Board of Directors
     was filled in August 1988.  The IFNA Echomail Conference has been
     established on FidoNet to assist the Board.  We welcome your
     input to this Conference.

     FidoNews 6-52                Page 31                  25 Dec 1989


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