F I D O N E W S --       Volume 14, Number 25          23 June 1997
    +----------------------------+-----------------------------------------+
    |  The newsletter of the     |   ISSN 1198-4589 Published by:          |
    |    FidoNet community       |   "FidoNews"                            |
    |          _                 |        1-904-409-7040    [1:1/23]       |
    |         /  \               |                                         |
    |        /|oo \              |                                         |
    |       (_|  /_)             |                                         |
    |        _`@/_ \    _        |                                         |
    |       |     | \   \\       |   Editor:                               |
    |       | (*) |  \   ))      |        Christopher Baker  1:18/14       |
    |       |__U__| /  \//       |                                         |
    |        _//|| _\   /        |                                         |
    |       (_/(_|(____/         |                                         |
    |             (jm)           |     Newspapers should have no friends.  |
    |                            |                    -- JOSEPH PULITZER   |
    +----------------------------+-----------------------------------------+
    |               Submission address: FidoNews Editor 1:1/23             |
    +----------------------------------------------------------------------+
    |  MORE addresses:                                                     |
    |                                                                      |
    |    submissions=> [email protected]                                |
    +----------------------------------------------------------------------+
    |    For  information,   copyrights,   article   submissions,          |
    |    obtaining copies of FidoNews or the internet gateway FAQ          |
    |    please refer to the end of this file.                             |
    +----------------------------------------------------------------------+


                   HELP STAMP OUT OSMOSIS!


                       Table of Contents
    1. EDITORIAL  ................................................  1
       Are we getting out?  ......................................  1
    2. LETTERS TO THE EDITOR  ....................................  2
       Take the First Amendment Pledge  ..........................  2
       Internet Regulations ruled Unconstitutional  ..............  6
       BWE - Blue Wave mail reader for Windows95/NT4  ............ 10
    3. ARTICLES  ................................................. 11
       CRC and the Nodelist  ..................................... 11
    4. COLUMNS  .................................................. 15
       Lock and Load: Guerilla Marketing for BBSes  .............. 15
    5. GETTING TECHNICAL  ........................................ 17
       FSC-0085 - NOZIP and ERX flags  ........................... 17
       FSC-0086 - Standard Request Information File proposal  .... 18
       FSC-0087 - File Forwarding in FTNs  ....................... 21
       FSC-0088 - Compatibility for EMSI Sessions  ............... 27
    6. ADVERTISE YOUR FREE SERVICE/EVENT  ........................ 33
       Announcing the WRESTLING_CHAT Echo  ....................... 33
    7. NOTICES  .................................................. 34
       New Area Codes in North FLorida are coming  ............... 34
       Future History  ........................................... 35
    8. FIDONEWS PUBLIC-KEY  ...................................... 36
       FidoNews PGP public-key listing  .......................... 36
    9. FIDONET BY INTERNET  ...................................... 37
    10. FIDONEWS INFORMATION  .................................... 39
    FIDONEWS 14-25               Page 1                   23 Jun 1997


    =================================================================
                                EDITORIAL
    =================================================================


    Yet another email from Zone 2 telling me they've either:

     1. never heard of FidoNews;

    or

     2. don't get FidoNews in their Net/Region.

    Isolated incidents? Probably, since the reports are not at flood level
    so far. But, of course, if FidoNews is unknown out there, who is going
    to know to comment or complain? The last reporter only found FidoNews
    during an Infoseek search on the Internet.

    I know it gets to ZC2 but what about you Zone 2 RCs? Are you moving
    FidoNews out there? Zone 2 NCs? YooHoo.

    P4 sez FidoNews is part of the glue that holds us together but glue
    doesn't work unless you spread it on all the parts you want to stick.

    ZCs, RCs, and NCs can send Netmail to me at 1:18/14 or 1:1/23 or email
    to [email protected] and let me know how many times they send out
    FidoNews to their constituents, if they'd like to help sort out the
    black holes of FidoNews distribution.

    Otherwise, the news continues. [grin]

    C.B.

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

    FIDONEWS 14-25               Page 2                   23 Jun 1997


    =================================================================
                          LETTERS TO THE EDITOR
    =================================================================


    --- Following message extracted from FIDONEWS @ 1:18/14 ---
        By Christopher Baker on Sun Jun 22 14:43:12 1997

    From: Mike Bilow
    To: Christopher Baker
    Date: 20 Jun 97  16:55:06
    Subj: ACLU Cyber-Liberties Update, June 19, 1997

    * Forwarded (from: Netmail) by Mike Bilow using BilowMail0.2.
    * Original dated: Jun 19 '97, 21:33

    From: "ACLU Cyber-Liberties Update Owner"@newmedium.com
    To:   [email protected]

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                            ACLU Cyber-Liberties Update
                            Thursday, June 19, 1997

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                   http://www.firstamendment.org/
                     A new ACLU/EPIC website

                   Take the First Amendment Pledge


    As we all await a Supreme Court decision on the future of free speech
    on the Internet, the American Civil Liberties Union and the Electronic
    Privacy Information Center launched www.firstamendment.org, a website
    dedicated to upholding the First Amendment in cyberspace.

    The groups called on President Clinton and members of Congress to be
    among the first to "Take the First Amendment Pledge" and cease any
    further attempts to draft legislation to censor the Internet in the
    event the Supreme Court upholds a lower court decision striking down
    government regulation of the Internet as unconstitutional.

    The launch of the website comes as Clinton Administration officials
    have begun publicly discussing a shift in policy on Internet
    regulation, saying that "industry self-regulation" -- not laws
    criminalizing certain Internet communications -- is the solution to
    shielding minors from online "indecency."

    "Attempts to censor the Net will not end with the Supreme Court
    decision," said David Sobel, legal counsel for EPIC and co-counsel in
    Reno v. ACLU.  "Proponents of Internet content regulation have already
    indicated their desire to take a 'second bite of the apple' if the
    Communications Decency Act is struck down."

    In anticipation of such new attempts at online censorship, visitors to
    FIDONEWS 14-25               Page 3                   23 Jun 1997


    www.firstamendment.org are invited to "Take the First Amendment
    Pledge," which reads: "I pledge to support free speech and free
    expression for all Americans and to urge Congress to uphold the First
    Amendment to the United States Constitution and pass no law abridging
    our  freedom of speech."

    People taking the pledge are encouraged to place the "First Amendment
    Pledge" GIF their own websites.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Day of Decision Events

    As the countdown continues to a Supreme Court ruling in Reno v. ACLU,
    the first-ever case to look at how free speech principles are applied
    to the Internet, the American Civil Liberties Union is preparing to go
    live on the World Wide Web with a cybercast news  conference on the
    day a decision is reached.

    Day of Decision Schedule

    1:00 p.m.(E.D.T.) Press Conference and Cybercast

    At the ACLU's new national offices at 125 Broad Street in lower
    Manhattan.  Reno v. ACLU attorneys, co-counsel and plaintiffs will
    participate. The live cybercast can be accessed through the ACLU's
    website, http://www.aclu.org, and directly through Pathfinder's Netly
    News at http://www.pathfinder.com/news/netdecency.

    7:00 p.m. (E.D.T.) Live Chat with ACLU Attorneys

    A one-hour chat with ACLU attorneys is planned on ECHO.

    Instructions:
    ECHO chats are open to anyone with Internet access.
    Telnet to echonyc.com, or  dial 212-292-0910 with your modem.
    Login as echolive, and communicate directly with the Attorneys.

    Reno v. ACLU challenges censorship provisions of the Communications
    Decency Act aimed at protecting minors by criminalizing so-called
    "indecency" on the Internet. The government appealed the case to the
    Supreme Court after a federal three-judge panel ruled unanimously last
    June that the law unconstitutionally restricts free speech. The ACLU
    filed a challenge to the law the day it was enacted.

    Show your support for the ACLU's challenge to the Communications
    Decency in any -- or all --  of the following ways:

    1) To be notified of a decision in the case by a change in a graphic
    placed on your web site, join our GIF notification Campaign --
    instructions can be found at:
    http://www.aclu.org/issues/cyber/trial/instructions.html

    The image will change when the decision is handed down - notifying
    you, and everyone who visits your site.

    2) Take the 1st Amendment Pledge at www.firstamendment.org, a joint
    FIDONEWS 14-25               Page 4                   23 Jun 1997


    campaign of the ACLU and the Electronic Privacy Information Center
    (EPIC).

    3) Subscribe to the Cyber-Liberties Update. Those of you who already
    receive the update directly will be notified. Those of you who read
    forwarded copies are encouraged to subscribe directly using the
    information in the footer of this document.

    4) And the most important way you can show your support is to Join the
    ACLU.  Information is available on our website http://www.aclu.org


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Setback in Efforts to Secure Online Privacy

         FOR IMMEDIATE RELEASE
         Thursday, June 19, 1997

    WASHINGTON -- A Senate committee today setback legislative efforts to
    secure online privacy, approving legislation that would restrict the
    right of businesses and individuals both to use encryption
    domestically and to export it.

         On a voice vote, the Senate Commerce Committee adopted
    legislation that essentially reflects the Clinton Administration's
    anti-encryption policies.

         The legislation approved today on a voice vote by the Senate
    Commerce Committee was introduced this week by Senate Commerce
    Committee Chairman John McCain, Republican of Arizona, and co-
    sponsored by Democrats Fritz Hollings of South Carolina; Robert Kerry
    of Nebraska and John Kerry of Massachusetts.

         Encryption programs scramble information so that it can only be
    read with a "key" -- a code the recipient uses to unlock the scrambled
    electronic data.  Programs that use more than 40 bits of data to
    encode information are considered "strong" encryption. Currently,
    unless these keys are made available to the government, the Clinton
    Administration bans export of hardware or software containing strong
    encryption, treating these products as "munitions."

         Privacy advocates continue to criticize the Administration's
    stance, saying that the anti-cryptography ban has considerably
    weakened U.S. participation in the global marketplace, in addition
    to curtailing freedom of speech by denying users the right to "speak"
    using encryption. The ban also violates the right to privacy by
    limiting the ability to protect sensitive information in the new
    computerized world.

         Today's committee action knocked out of consideration the so-
    called "Pro-CODE" legislation, a pro-encryption bill introduced by
    Senator Conrad Burns, Republican of Montana. Although the Burns
    legislation raised some civil liberties concerns, it would have lifted
    export controls on encryption programs and generally protected
    individual privacy.
    FIDONEWS 14-25               Page 5                   23 Jun 1997


         "Privacy, anonymity and security in the digital world depend on
    encryption," said Donald Haines, legislative counsel on privacy and
    cyberspace issues for the ACLU's Washington National Office. "The aim
    of the Pro-CODE bill was to allow U.S. companies to compete with
    industries abroad and lift restrictions on the fundamental right to
    free speech, the hallmark of American democracy."

         "Sadly, no one on the Commerce Committee, not even Senator Burns,
    stood up and defended the pro-privacy, pro-encryption effort," Haines
    added.

         In the House, however, strong encryption legislation that would
    add new privacy protections for millions of Internet users in this
    country and around the world has been approved by two subcommittees.

         The legislation -- H.R. 695, the "Security and Freedom Through
    Encryption Act" or SAFE -- would make stronger encryption products
    available to American citizens and users of the Internet around the
    world. It was introduced by Representative Robert W. Goodlatte,
    Republican of Virginia.

         "We continue to work toward the goal of protecting the privacy of
    all Internet users by overturning the Clinton Administration's
    unreasonable encryption policy," Haines concluded

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    ACLU Cyber-Liberties Update Editor:
    Lisa Kamm ([email protected])
    American Civil Liberties Union National Office
    125 Broad Street
    New York, New York 10004

    To subscribe to the ACLU Cyber-Liberties Update, send a message
    to [email protected] with "subscribe Cyber-Liberties" in the
    body of your message. To terminate your subscription, send a
    message to [email protected] with "unsubscribe Cyber-Liberties"
    in the body.

    The Cyber-Liberties Update is archived at
    http://www.aclu.org/issues/cyber/updates.html

    For general information about the ACLU, write to [email protected].
    PGP keys can be found at http://www.aclu.org/about/pgpkeys.html

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Lisa Kamm           |To receive the biweekly
    [email protected]      |ACLU Cyber-Liberties Update
    http://www.aclu.org |email: [email protected]
    http://www.gilc.org |body of message: subscribe cyber-liberties

    take the pledge: http://www.firstamendment.org

    [email protected]
    Online Programs Coordinator
    American Civil Liberties Union
    FIDONEWS 14-25               Page 6                   23 Jun 1997


    125 Broad Street
    New York, NY 10004-2400

                        Visit the ACLU Freedom Network --
                        http://www.aclu.org ACLU Constitution Hall on
                        America Online -- keyword ACLU ACLU Supports the
                        Global Internet Liberty Campaign (GILC)
                        http://www.gilc.org/gilc

    This Message was sent to cyber-liberties

    Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8(1:323/107)

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


    --- Following message extracted from FIDONEWS @ 1:18/14 ---
        By Christopher Baker on Sun Jun 22 14:43:29 1997

    From: Mike Bilow
    To: Christopher Baker
    Date: 21 Jun 97  08:35:50
    Subj: ACLU Cyber-Liberties Update, Special: June 20, 1997

    * Forwarded (from: Netmail) by Mike Bilow using BilowMail0.2.
    * Original dated: Jun 21 '97, 00:16

    From: "ACLU Cyber-Liberties Update Owner"@newmedium.com
    To:   [email protected]

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                            ACLU Cyber-Liberties Update
                            Friday, June 20, 1997

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         Georgia, New York Internet Regulations Ruled Unconstitutional

    Georgia Ruling available online now, New York summary available now
    and Ruling on the way at
    http://www.aclu.org/issues/cyber/censor/censor.html

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              ACLU Wins First-Ever Challenge to a State
                 Internet Censorship Law in Georgia

         FOR IMMEDIATE RELEASE
         Friday, June 20, 1997

    ATLANTA -- As the nation awaits a Supreme Court decision on Internet
    censorship, a federal district judge here today struck down a state
    law criminalizing online anonymous speech and the use of trademarked
    logos as links on the World Wide Web.

    Ruling simultaneously in ALA v. Pataki, another ACLU challenge to
    FIDONEWS 14-25               Page 7                   23 Jun 1997


    state Internet regulation, a Federal District Judge in New York today
    blocked the state from enforcing its version of the federal
    Communications Decency Act (CDA).

    In ACLU v. Miller, Federal District Court Judge Marvin Shoob today
    granted the ACLU's request to enjoin Georgia's statute restricting
    free speech in cyberspace and denied the State's request to dismiss
    the suit.

         The Court agreed with the ACLU, Electronic Frontiers Georgia and
    others that the statute is unconstitutionally vague and overbroad
    because it bars online users from using pseudonyms or communicating
    anonymously over the Internet. The Act also unconstitutionally
    restricts the use of links on the World Wide Web which allows users to
    connect to other sites.

    In the Court's decision, Judge Shoob noted that Georgia's law, "sweeps
    innocent, protected speech within its scope." He went on to say that
    it, "affords prosecutors and police officers with substantial room for
    selective prosecution of persons who express minority viewpoints. . .
    .  [Moreover,] Georgia already has in place many less restrictive
    means to address fraud and misrepresentation."

    "The Court's order goes straight to the First Amendment flaws with the
    statute." said Scott McClain of Bondurant, Mixson & Elmore,
    cooperating attorneys for the ACLU. "Judge Shoob viewed the statute
    exactly as the Plaintiffs did: as a vague, overbroad, unconstitutional
    restriction on free speech and privacy on the Internet."

    "The Court recognized that anonymity is the passport for entry into
    cyberspace for many persons," said Gerald Weber, Legal Director of
    the ACLU of Georgia. "Without anonymity, victims of domestic violence,
    persons in Alcoholics Anonymous, people with AIDS and so many others
    would fear using the Internet to seek information and support."

    "We are very pleased with the Judge's decision," said Robert Costner,
    Executive Director of Electronic Frontiers Georgia. "This injunction
    clears the way for Electronics Frontier Georgia to release our
    anonymous remailer services on the Internet."

    Georgia's lawsuit was the first challenge to state cyberspace laws and
    statutes restricting privacy on the Internet.

         Today's ruling came as the nation awaits word from the U.S.
    Supreme Court in Reno v. ACLU, the ACLU's challenge to Internet
    censorship provisions of the federal Communications Decency Act (CDA).

    "Today's decisions in New York and Georgia say that, whatever limits
    the Supreme Court sets on Congress's power to regulate the Internet,
    states are prohibited from acting to censor online expression," said
    Ann Beeson, an ACLU national staff attorney and member of the legal
    teams in the New York, Georgia and federal cases.

    "Taken together, these decisions send a very important and powerful
    message to legislators in the other 48 states that they should keep
    their hands off the Internet," Beeson added.
    FIDONEWS 14-25               Page 8                   23 Jun 1997


    The Georgia lawsuit was filed on September 24, 1996, by the ACLU on
    behalf of 14 plaintiffs. The 14 individual plaintiffs and
    organizations named in the ACLU v. Miller are: American Civil
    Liberties Union of Georgia; The AIDS Survival Project; the Atlanta
    Freethought Society; Atlanta Veterans Alliance; Community ConneXion;
    Electronic Frontier Foundation; Electronic Frontiers Georgia; Rep.
    Mitchell Kaye; Ken Leebow; Bruce Mirken; Bonnie L.  Nadri; Josh Riley;
    John Troyer; and Jonathan Wallace.


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            New York Judge Prohibits State Regulation of Internet

         FOR IMMEDIATE RELEASE
         Friday, June 20, 1997

    NEW YORK -- As the nation awaits a Supreme Court decision on Internet
    censorship, a federal district judge here today blocked New York State
    from enforcing its version of the federal Communications Decency Act
    (CDA).

    Ruling simultaneously in ACLU v. Miller, another ACLU challenge to
    state Internet regulation, a Federal District Judge in Georgia today
    struck down a law criminalizing online anonymous speech and the use of
    trademarked logos as links on the World Wide Web.

    In ALA v. Pataki, Federal District Judge Loretta A. Preska issued a
    preliminary injunction against the New York law, calling the Internet
    an area of commerce that should be marked off as a "national preserve"
    to protect online speakers from inconsistent laws that could "paralyze
    development of the Internet altogether."

    Judge Preska, acknowledging that the New York act was "clearly modeled
    on the CDA," did not address the First Amendment issues raised by the
    ACLU's federal challenge, saying that the Commerce Clause provides
    "fully adequate support" for the injunction and that the Supreme Court
    would address the other issues in its widely anticipated decision in
    Reno v. ACLU. (The Court's next scheduled decision days are June 23,
    25 and 26.)

    "Today's decisions in New York and Georgia say that, whatever limits
    the Supreme Court sets on Congress's power to regulate the Internet,
    states are prohibited from acting to censor online expression," said
    Ann Beeson, an ACLU national staff attorney who argued the case before
    Judge Preska and is a member of the ACLU v. Miller and Reno v. ACLU
    legal teams.

    "Taken together, these decisions send a very important and powerful
    message to legislators in the other 48 states that they should keep
    their hands off the Internet," Beeson added.

    In a carefully reasoned, 62-page opinion, Judge Preska warned of the
    extreme danger that state regulation would pose to the Internet,
    rejecting the state's argument that the statute would even be
    effective in preventing so-called "indecency" from reaching minors.
    FIDONEWS 14-25               Page 9                   23 Jun 1997


    Further, Judge Preska observed, the state can already protect children
    through the vigorous enforcement of existing criminal laws.

    "In many ways, this decision is more important for the business
    community than for the civil liberties community," said Chris Hansen,
    a senior ACLU attorney on the ALA v. Pataki legal team and lead
    counsel in Reno v. ACLU.  "Legislatures are just about done with their
    efforts to regulate the business of Internet 'sin,' and have begun
    turning to the business of the Internet itself. Today's decision ought
    to stop that trend in its tracks."

    Saying that the law would reduce all speech on the Internet to a level
    suitable for a six-year-old, the American Civil Liberties Union, the
    New York Civil Liberties Union, the American Library Association and
    others filed the challenge in January of this year.

    The law, which was passed by the New York legislature late last year,
    provides criminal sanctions of up to four years in jail for
    communicating so-called "indecent" words or images to a minor.

    In a courtroom hearing before Judge Preska in April, the ACLU
    presented a live Internet demonstration and testimony from plaintiffs
    who said that their speech had already been "chilled" by the threat of
    criminal prosecution.

    "This is a big win for the people of the state of New York," said
    Norman Siegel, Executive Director of the New York Civil Liberties
    Union. "Today's ruling vindicates what we have been saying all along
    to Governor Pataki and legislators, that they cannot legally prevent
    New Yorkers from engaging in uninhibited, open and robust freedom of
    expression on the Internet."

    The ALA v. Pataki plaintiffs are: the American Library Association,
    the Freedom to Read Foundation, the New York Library Association, the
    American Booksellers Foundation for Free Expression, Westchester
    Library System, BiblioBytes, Association of American Publishers,
    Interactive Digital Software Association, Magazine Publishers of
    America, Public Access Networks Corp. (PANIX), ECHO, NYC Net, Art on
    the Net, Peacefire and the American Civil Liberties Union.

    Michael Hertz and others of the New York firm Latham & Watkins
    provided pro-bono assistance to the ACLU and NYCLU; Michael Bamberger
    of Sonnenschein Nath & Rosenthal in New York is also co-counsel in the
    case.  Lawyers from the ACLU are Christopher Hansen, Ann Beeson and
    Art Eisenberg, legal director of the NYCLU.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ACLU Cyber-Liberties Update Editor:
    Lisa Kamm ([email protected])
    American Civil Liberties Union National Office
    125 Broad Street
    New York, New York 10004

    To subscribe to the ACLU Cyber-Liberties Update, send a message
    to [email protected] with "subscribe Cyber-Liberties" in the
    body of your message. To terminate your subscription, send a
    FIDONEWS 14-25               Page 10                  23 Jun 1997


    message to [email protected] with "unsubscribe Cyber-Liberties"
    in the body.

    The Cyber-Liberties Update is archived at
    http://www.aclu.org/issues/cyber/updates.html

    For general information about the ACLU, write to [email protected].
    PGP keys can be found at http://www.aclu.org/about/pgpkeys.html

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Lisa Kamm           |To receive the biweekly
    [email protected]      |ACLU Cyber-Liberties Update
    http://www.aclu.org |email: [email protected]
    http://www.gilc.org |body of message: subscribe cyber-liberties

    take the pledge: http://www.firstamendment.org

    This Message was sent to cyber-liberties

    Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8(1:323/107)

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


    X-Sender: [email protected]
    Date: Thu, 19 Jun 1997 07:05:22 +0200
    To: [email protected]
    From: Michele Di Maria <[email protected]>
    Subject: BWExplorer

    HI!,
    I'd like inform you that BWExplorer: the FIRST Blue Wave (tm) mail
    reader especially designed for Windows95/NT4) has been released.
    You can download it at Michele's HomePage at:
    http://www.geocities.com/siliconvalley/7409

    (This is not a mailing list, I found you address at your site and I
    hope you will find interesting this new)

    Thank you,
            Michele
    Michele's
    Shareware
    Site:           http://www.geocities.com/SiliconValley/7409

     -30-

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

    FIDONEWS 14-25               Page 11                  23 Jun 1997


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

    CRC and The Nodelist

    Has anybody else had problems keeping current?  If it's not a missing
    DIFF now and then, it's CRC trouble... What is this CRC thing anyway?
    I've been trying to find out for over a year now, it's been one of
    those things that just keeps coming up now and then.  Right now my
    NODELIST.164 has an improper CRC.  The utility I use to merge the
    diffs told me so, and actually added a line at the bottom:

    ;S This Nodelist file has an improper CRC!

    The nodelist seems to be working correctly, but it bugs me to know
    something is improper about it.  I have all those FSC- and FTS- files
    that tell about fido junk, maybe they can help?  Maybe someone in the
    net knows what's going on?  Isn't anybody gonna do something? My
    Nodelist has an improper CRC!  Help!

    I like fido, and it's a good excuse to try writing small programs in
    c/c++ that can help me out.  I've been sort of working on a small
    utility that will take our local netseg and make a BBS list for the
    systems not marked HUB, HOST or with a MO flag.  Our netseg has that
    CRC number on the top line, shouldn't my program insure that the
    contents are valid before it tries to use them?

    This source will check an input file for a number at the end of the
    top line, and use that number if found to compare CRC value with the
    rest of the file. There may already be code out there to do this, if
    there is, I sure wish I'd had access to it!!  I'm very interested in
    c/c++, but don't have access to any echos dealing with fido or BBS
    programming.  There may be plenty of source code out there.

    Seems like most good software comes from Zone:2 anyway.  If anybody
    knows where there is some source code dealing specifically with
    fidonet, how about dropping me a line?

    If you need a compiled (.EXE) version, F'Req NLCRC.ZIP (35k).
    L8r,
    bw

    /*******************************************: 55734
    ** NLCRC.C  Test a nodelist segment for correct CRC
    ** 6/97 Brian Wood 1:362/903
    **            ([email protected])
    ** thanks to:
    ** Ross N. Williams, Author:
    ** A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS
    ** and:
    ** The SNIPPETS guy, I think it's Bob Juge or Stout?
    ** and for FTS-0005:
    ** The Distribution Nodelist
    ** Original by Ben Baker Amended by Rick Moore
    */
    FIDONEWS 14-25               Page 12                  23 Jun 1997


    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    unsigned AddCRC(unsigned, char *, unsigned);

    main(int argc, char **argv)
    {
        unsigned crc=0;
        unsigned lines=0;
        unsigned compare=0;
        char szCrc[10];
        char topline[200];  /* assuming a nodelist entry */
        char oneline[200];  /* will be <= 200 characters */
        FILE *f;

        if( argc > 1 ) {
              if( (f = fopen( argv[1], "rb" ) ) == NULL ) {
                printf("\nCan't open %s", argv[1]);
                exit(-1);
              }
        }
        else {
              printf("\nUsage: NLCRC <nodelist.ext>");
              exit(-1);
        }

        /* Take the CRC from the top line of nodelist */
        fgets( topline, sizeof(topline), f);
        strcpy(szCrc, &topline[strlen(topline)-8]);
        compare = (unsigned)atof(szCrc);
        if(compare==0) {
              printf("\n%s doesn't seem to be a nodelist!", argv[1]);
              exit(-1);
        }

        /* FTS-0005 says calculate beginning with
        ** 1st character of second line, and ignore
        ** EOF(ASCII 26) if present, so.... */
        printf("\nReading File...");
        while( fgets(oneline, sizeof(oneline), f) != NULL
                                         && oneline[0] != 26) {
              crc = AddCRC( crc, oneline, strlen(oneline) );
              lines++;
        }

        /* Show the results */
        printf("\n%s %ld bytes", argv[1], ftell(f));
        fclose(f);
        printf("\nLinesread = %u", lines);
        if(oneline[0] == 26)
              printf(" -minus top line and EOF-");
        else
              printf(" -minus top line- EOF Missing!");
        printf("\n%u = compare crc", compare);
        printf("\n%u = actual  crc", crc);
    FIDONEWS 14-25               Page 13                  23 Jun 1997


        printf("\n");
        if(compare==crc)
              printf("\nCRC appears OK!");
        else
              printf("\nCRC Values Do Not Match!");

        return 0;
    }
    /*
    ** END MAIN */

    /************************
    ** Function:  AddCRC(...)
    */
    unsigned AddCRC(unsigned crc, char *sz, unsigned len)
    {

    unsigned CRC16table[] = {   /* Polynomial 0x1021 (CITT) */
        0x0000,  0x1021,  0x2042,  0x3063,  0x4084,  0x50a5,  0x60c6,
        0x70e7,  0x8108,  0x9129,  0xa14a,  0xb16b,  0xc18c,  0xd1ad,
        0xe1ce,  0xf1ef,  0x1231,  0x0210,  0x3273,  0x2252,  0x52b5,
        0x4294,  0x72f7,  0x62d6,  0x9339,  0x8318,  0xb37b,  0xa35a,
        0xd3bd,  0xc39c,  0xf3ff,  0xe3de,  0x2462,  0x3443,  0x0420,
        0x1401,  0x64e6,  0x74c7,  0x44a4,  0x5485,  0xa56a,  0xb54b,
        0x8528,  0x9509,  0xe5ee,  0xf5cf,  0xc5ac,  0xd58d,  0x3653,
        0x2672,  0x1611,  0x0630,  0x76d7,  0x66f6,  0x5695,  0x46b4,
        0xb75b,  0xa77a,  0x9719,  0x8738,  0xf7df,  0xe7fe,  0xd79d,
        0xc7bc,  0x48c4,  0x58e5,  0x6886,  0x78a7,  0x0840,  0x1861,
        0x2802,  0x3823,  0xc9cc,  0xd9ed,  0xe98e,  0xf9af,  0x8948,
        0x9969,  0xa90a,  0xb92b,  0x5af5,  0x4ad4,  0x7ab7,  0x6a96,
        0x1a71,  0x0a50,  0x3a33,  0x2a12,  0xdbfd,  0xcbdc,  0xfbbf,
        0xeb9e,  0x9b79,  0x8b58,  0xbb3b,  0xab1a,  0x6ca6,  0x7c87,
        0x4ce4,  0x5cc5,  0x2c22,  0x3c03,  0x0c60,  0x1c41,  0xedae,
        0xfd8f,  0xcdec,  0xddcd,  0xad2a,  0xbd0b,  0x8d68,  0x9d49,
        0x7e97,  0x6eb6,  0x5ed5,  0x4ef4,  0x3e13,  0x2e32,  0x1e51,
        0x0e70,  0xff9f,  0xefbe,  0xdfdd,  0xcffc,  0xbf1b,  0xaf3a,
        0x9f59,  0x8f78,  0x9188,  0x81a9,  0xb1ca,  0xa1eb,  0xd10c,
        0xc12d,  0xf14e,  0xe16f,  0x1080,  0x00a1,  0x30c2,  0x20e3,
        0x5004,  0x4025,  0x7046,  0x6067,  0x83b9,  0x9398,  0xa3fb,
        0xb3da,  0xc33d,  0xd31c,  0xe37f,  0xf35e,  0x02b1,  0x1290,
        0x22f3,  0x32d2,  0x4235,  0x5214,  0x6277,  0x7256,  0xb5ea,
        0xa5cb,  0x95a8,  0x8589,  0xf56e,  0xe54f,  0xd52c,  0xc50d,
        0x34e2,  0x24c3,  0x14a0,  0x0481,  0x7466,  0x6447,  0x5424,
        0x4405,  0xa7db,  0xb7fa,  0x8799,  0x97b8,  0xe75f,  0xf77e,
        0xc71d,  0xd73c,  0x26d3,  0x36f2,  0x0691,  0x16b0,  0x6657,
        0x7676,  0x4615,  0x5634,  0xd94c,  0xc96d,  0xf90e,  0xe92f,
        0x99c8,  0x89e9,  0xb98a,  0xa9ab,  0x5844,  0x4865,  0x7806,
        0x6827,  0x18c0,  0x08e1,  0x3882,  0x28a3,  0xcb7d,  0xdb5c,
        0xeb3f,  0xfb1e,  0x8bf9,  0x9bd8,  0xabbb,  0xbb9a,  0x4a75,
        0x5a54,  0x6a37,  0x7a16,  0x0af1,  0x1ad0,  0x2ab3,  0x3a92,
        0xfd2e,  0xed0f,  0xdd6c,  0xcd4d,  0xbdaa,  0xad8b,  0x9de8,
        0x8dc9,  0x7c26,  0x6c07,  0x5c64,  0x4c45,  0x3ca2,  0x2c83,
        0x1ce0,  0x0cc1,  0xef1f,  0xff3e,  0xcf5d,  0xdf7c,  0xaf9b,
        0xbfba,  0x8fd9,  0x9ff8,  0x6e17,  0x7e36,  0x4e55,  0x5e74,
        0x2e93,  0x3eb2,  0x0ed1,  0x1ef0   };

    FIDONEWS 14-25               Page 14                  23 Jun 1997


        while(len--)
              crc=(crc<<8)^CRC16table[(crc>>8)^*sz++];

        return( crc );
    }
    /*
    ** END NLCRC.C */

    --- ISR sn 000 at river.chattanooga.net vsn 1.0a unreg
    --
    |Fidonet:  Brainwave 1:362/903
    |Internet: [email protected]
    |
    | Standard disclaimer: The views of this user are strictly his own.
    | River Canyon Rd. BBS <=> Chattanooga OnLine!  Gateway to the World.

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

    FIDONEWS 14-25               Page 15                  23 Jun 1997


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


    Lock and Load: Guerilla Marketing for BBSes
    Robert Parson (1:3822/1)

    Y'know.  One of the things I've always found rather bothersome about
    the Internet is its lack of a local identity.  Sure, it's got lots of
    really spiffy stuff on it.  But it still seems rather cold and
    distant.  Even the sites that are highly personalized are somewhat
    remote.

    When was the last time you were really able to discuss local issues
    with someone on the Internet?  Can you vent your indignation about a
    city sales tax increase with someone across the country?  You could,
    but he or she won't have the same empathy as someone across the town
    would have.

    This is the great power BBSes have.  They are the Friendly
    Neighborhood Electronic Townhalls.  But the users can't come if they
    don't know you are there.

    When I was just a tad, about 8 or 9 years old, my grandfather and two
    uncles opened up a window glass store.  Most of their business came
    from contractors who called up and said "We've built a house, now we
    need windows."  But a good chunk of their business was repairing
    windows broken in storms, vandals, or the neighborhood baseball games.

    One Saturday morning, they armed my brother and me with hundreds of
    flyers.  We were to go slipping through the neighborhood, tucking
    these flyers into doors.  The flyers talked about how great the work
    of Lawrence Glass Company (In Lawrence IN) was and how inexpensive the
    rates were.  We earned a whopping 25 cents each (it's amazing how I
    can remember things like that, but can't remember how old my wife is).

    I'm sure you can see where this is going.  How many of your neighbors
    know you have a BBS?

    Crack open the Desktop Publisher and create a flyer.  It doesn't have
    to be very elaborate.  Make sure it has the name of your BBS and the
    data number (you might want to include your voice phone in case
    someone wants to ask a question before they dial in), and invite the
    neighborhood to call.  Print up a jillion of these things.

    Then put those preteens to work.  If they're like mine, they're aching
    to get outside anyway ("But there's a blizzard!"  "I don't care!  I
    wanna go out!").  And don't forget to give them a quarter for their
    efforts.

    Now, it's quite likely not every house in your neighborhood is going
    to have a computer equipped with a modem.  I think in my neighborhood
    there's an average of one computer per block.  But that's unimportant.
    What IS important is that you're getting the word out to people that
    are likely to be intrigued at the very least.
    FIDONEWS 14-25               Page 16                  23 Jun 1997


    1. They're going to be interested because it's someone they know that
    lives near them.
    2. They're going to be interested because it's so close to them, there
    may be something on the BBS that offers them some sort of local
    information.
    3.  They're going to be interested because it's something
    different.
    4.  They're going to be interested because they want to make sure you
    aren't peddling pornography. (or maybe because you are)
    5.  They're going to be interested because you had the audacity to put
    that doggone flyer in their door.

    I'm constant amazed at the numbers of small-town weeklies that exist.
    They're poorly written, sloppily edited, have messy layouts, and low
    page counts.  Thy thrive because they publish the little details of
    small-town life.  Your Friendly Neighborhood BBS can thrive in much
    the same way.


    Robert Parson

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

    FIDONEWS 14-25               Page 17                  23 Jun 1997


    =================================================================
                            GETTING TECHNICAL
    =================================================================


    [This is part of the continuing FidoNet History series publishing the
     FidoNet Technical Standards and Proposals. FSC-0084 was skipped due
     to size. These have been reformatted to 70 columns where required and
     tables may be askew as a result. Node numbers and phone numbers may
     be out of date. High ASCII characters have been converted or
     removed as necessary.] Ed.


      | Document: FSC-0085
      | Version:  001
      | Date:     03 September 1995
      |
      | Denis Bider, FidoNet#2:380/129.0

    /*

    Date: 25-Jul-1995
    Document: Descriptions of the "NOZIP" and "ERX<n>" nodelist flags
    Purpose: To give a system that is about to send some mail to a system
       not already defined by its operator in its configuration some idea
       about what kind of mail the mentioned destination system accepts
    Author: denis bider, ofs->FidoNet#2:380/129.0


    The NOZIP nodelist flag and its affects on the MN nodelist flag
    ======================================================================
    Generally, most FTN systems are able to receive compressed mail from
    any other FTN system. Up to now, the official compression format
    between systems has been ARC. This document, however, puts the ZIP
    format to that position.
       *  A system whose nodelist entry contains neither an "MN" and
          neither a "NOZIP" flag is assumed to support both ARC and ZIP.
       *  A system whose nodelist entry contains an "MN" flag is assumed
          not to support any compression at all.
       *  A system whose nodelist entry contains a "NOZIP" flag is assumed
          to support ARC compression, while not supporting ZIP
          compression.
       *  Both "NOZIP" and "MN" flags cannot appear in the same nodelist
          entry.  If they, by some accident, do, the system should be
          assumed not to support any mail compression.

    Since the majority of systems support ZIP compression, a flag
    indicating that this type of compression is NOT supported has is
    proposed instead of a flag indicating that this type of compression IS
    supported, the reason being to minimize the amount of changes required
    to the nodelist.

    The format of the NOZIP flag is, simply, "NOZIP".
    The format of the MN flag stays the same.

    The ERX<n> nodelist flag
    FIDONEWS 14-25               Page 18                  23 Jun 1997


    ======================================================================
    The presence of this flag in a system's nodelist entry indicates that
    the system is able to process ERX mail packets of level <n>. The
    current minimum and maximum values of <n> are both "1", indicating
    that the system is able to process ERX packets of level 1, meaning
    that the packets can only contain EDX message items. Please refer to
    EDX1.TXT for the EDX and ERX specifications.

    The format of the "ERX<n>" nodelist flag is
       "ERX" <n>
    as in "the three letters 'E', 'R' and 'X', immediately followed with
    the token <n>", where <n> is a number in decimal notation, with
    currently all values but '1' being reserved.

    If your system does not support ZIP and you do not yet have a NOZIP
    flag in your nodelist entry, or if your system is able to process ERX
    packets and you do not yet have an ERX<n> flag, please urge your NC or
    RC, whichever appropriate, to update your nodelist entry as soon as
    possible.

    // EOF */

     -30-

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


      | Document: FSC-0086
      | Version:  001
      | Date:     03 September 1995
      |
      | Mirko Mucko, 2:2433/920

                    Information / Description of a new standard

                                    S  tandard
                                    R  equest
                                    I  nformation
                                    F  ile

               Copyright (c) 1994,95 by Gordian Schuermann & Mirko Mucko

    I  Overview
                    Introduction                            0
                    Description in general                  1
                      Required statements                   1.1
                      Optional statements                   1.2
                      Undefined options                     1.3
                    Implementation                          2.0

    0. Introduction
     In common, more and more mailer are about to implement the ability to
     call external request processors. But very soon, we discovered a
     command line cannot handle all the information the mailer has and the
     ERP needs.

    FIDONEWS 14-25               Page 19                  23 Jun 1997


     To transfer the information in a proper and fast way, we designed and
     implemented the S R I F option in the mean it will be a standard
     soon.

     The structure and idea is protected by copyright law, except these
     circumstances:

            +  you may distrubute, use and implement this structure for
               free
            +  you have not to pay any value for usage of these methodes
            +  you should note in your documentation the origin of SRIF

    1. Description
     The SRIF name is the only parameter given from the Mailer to the
     External Request Processor. The file is designated as a so called
     "plain vanilla ASCII" file, filled with pre-defined, optional and
     not-yet defined statemets.

     We discussed the possibility of binary files, and of EMSI-like files,
     but a plain ASCII control file is more flexible and can be read
     faster by various program languages (C, Pascal, Basic, Cobol ect).

     In the SRIF, one command plus parameter is allowed per line, the file
     is unlimited in length, comments are not allowed.

     The SRIF is generated by the Mailer and after the ERP finished its
     work, the Mailer is responsible for erasing the SRIF.

    1.1 Required statements
     The following statements are required for the ERP:

           Sysop            <Sysop_Name>
                            This is the name of the remote sysop

           AKA              <Zone:Net/Node[.Point][@Domain]>
                            This is the main aka of the remote system in
                            4D or 5D notation. A zero as point number may
                            be ommited, the domain with "@" is optional

           Baud             <Current LINE rate>
                            This is the effective baud rate, not the fixed
                            DTE rate

           Time             <Time in minutes>
                            This is the time till next event which does
                            not allow file requests. Use -1 if no limits

           RequestList      <File of request list>
                            This is the filename of the list containing
                            requested files.
           ResponseList     <File of response list>
                            This is the filename of the response list.
                            It must not be equal to RequestList. One file
                            per line, including drives/pathes to the file.
                            The first character defines the way the mailer
                            should act after sending that file:
    FIDONEWS 14-25               Page 20                  23 Jun 1997


                             =   erase file if sent successfully
                             +   do not erase the file after sent
                             -   erase the file in any case after session

           RemoteStatus     <PROTECTED or UNPROTECTED>
                            Defines whether the session is protected by
                            password or not

           SystemStatus     <LISTED or UNLISTED>
                            Defines whether the remote system is listed in
                            any current nodelist of system.

    1.2 Optional statements
     These parameters are already known and defined, but a ERP should run
     also without them:

           SessionProtocoll <e.g. ZAP,ZMO,XMA

           AKA              <Zone:Net/Node[.Point][@Domain]>
                            Additional AKAs. One AKA is required (see
                            REQUIRED section)

           Site             <Site Info>
                            The site info as given e.g. in EMSI handshake

           Location         <Location and/or ZIP>
                            The location info as given e.g. in EMSI
                            handshake

           Phone            <Phone Number>
                            The phone number info as given e.g. in EMSI
                            handshake

           Password         <Session password>
                            On protected sessions, the session password.
                            If no protected session, this parameter must
                            be ommited!

           DTE              <Current DTE rate>
                            The PC<->Modem speed (so call DTE rate)

           PORT             <COM Port from 1 to 8>
                            The FOSSIL Communication Port. The Mailer
                            should leave the fossil "hot" for the Request
                            Processor

           Mailer           <Remote's mailer if EMSI>
                            The Mailer name as defined by FTC

           MailerCode       <Remote's FTSC code>
                            The hex code of the remote mailer as defined
                            by FTC

           SerialNumber     <Remote's serial number if passed>
                            The remote mailer's serial number if
                            transfered
    FIDONEWS 14-25               Page 21                  23 Jun 1997


           Version          <Remote's version number if EMSI>
                            The remote mailer's version number if
                            transfered

           Revision         <remote's revision number if EMSI>
                            The remote mailer's revision number if
                            transfered

           SessionType      <may be EMSI, FTSC0001, WAZOO, JANUS, HYDRA or
                            OTHER>
                            The session-type, this may be one of the known
                            session types or "OTHER" if not (yet) defined

           OurAKA           <AKA which has been called for proper
                            response>
                            If the mailer does AKA matching, the AKA of
                            the mailer being called

           TRANX            <Tranx Line as 8 digit hex string>
                            The unix-style time stamp (hexadecimal
                            notation of seconds since 1.1.1980)

    1.3 Undefined options
     There may be the need to add new commands / parameters to the SRI
     file. If so, they may be added, but inform us to keep the
     documentation "up to date" and to share your good ideas with other
     autors of software for FIDONet.

    2.0 Implementation
     SRIF is implemented in these fine products already :

                    Mailer                  Request Processor
                    ------------------------------------------------------
                    McMail                  xOR
                                            EasyERP

     Other products will follow soon !

     -30-


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


      | Document: FSC-0087
      | Version:  001
      | Date:     31 October, 1995
      |
      | Robert Williamson FidoNet#1:167/104.0

        File Forwarding in Fidonet Technology Networks
        Robert Williamson FidoNet#1:167/104.0  [email protected]

        Purpose:
            To  document  current practices in File Forwarding and the
    minimum requirements and known extensions of the TIC file format.
    FIDONEWS 14-25               Page 22                  23 Jun 1997


        Acknowledgements:
            The  TIC  file  format  was introduced by Barry Geller, in the
    MSDOS File Forwarder, Tick.  Useful extensions to this format were
    introduced by Harald Helms, in the MSDOS FileForwarder, AllFix.

        Terminology:
        FTN - Fidonet Technolgy Network, such as FIDONET, AMIGANET or
        IBMNET.  Sometimes used interchangably with the term DOMAIN.

        FNC - FileName Conversion, process of converting filenames to
    msdos 8.3 format for transmission.

        FQFA - Fully Qualified FTN Address, the format is
                  FTN#Zone:Net/Node.Point

        CRC - Cyclic Redundancy Check, method to determine whether some
    data has been altered. CRC-32 is used in File Forwarding.

        TIC - a file that contains control information for the File
    Forwarding system.   These  files  are  named  xxSTAMP.TIC,  where  xx
    is  an abbreviation  representing  the  File  Forwarding  program
    name and stamp  is  a  unixdate  stamp  truncated  to 6 characters.

        UTC  -  Universal  Time  Coordinated,  the  time  at  the  0o
    meridian (Greenwich); previously called GMT forwarding  -  the
    process  of  creating and sending tic files and the associated  file
    to one's downlinks.

        ticking - the processing of reading and verifying a tic file and
    it's associated file.

        hatching - the process of introducing a new file into a fileecho

        cross-hatching - the process of forwarding a file from one
    fileecho (ususally restricted) to another

        Associated File - The file listed in the FILE field of the TIC
    file.

            Note that use of UPPERCASE on tic file keywords in this
    document in for display purposes only.

      Format of a TIC file:

        Addressing:
            In  a  tic  file  any form of FTN address representation from
    3d to FQFA  may  be  used.   All  File  Forwarders  must  understand
    the following formats:

              zone:net/node                 - 3D
              zone:net/node.point           - 4D
              zone:net/node@ftn             - 5D - point 0 assumed
              zone:net/node.point@ftn       - 5D
              ftn#zone:net/node.point       - fqfa

            File Forwarders should have configurable options per site as
    FIDONEWS 14-25               Page 23                  23 Jun 1997


    to the type of addressing each of it's downlinks can understand.

        Dates:
            All dates are expressed in UTC.

        TimeDateStamps:
            All  TimeDateStamps are unix TimeDateStamps (# of seconds
    since Jan 1, 1960) in UTC and expressed in hexadecimal notation.

        Case Insensitivity:
            the  format is completely case-insensitive.  It is general
    practice that  the  first  letter  of a keyword is uppercase.  This is
    not a requirement.

        Order Dependancy:
            keywords are not order dependant.
            Order  dependancy  is required in some groupings of a keyword,
            such as PATH, VIA, DESC and APP.

        Modification of address fields on PassThrough:
            The  forwarding  site may modify the addresses in any keyword
    field to  make  them  compliant  with  the addressing limitations of
    each downlink.

        Stripping of SeenBys:
            The  forwarding site may strip seenbys to current FTN, ZONE or
    NET, when not forwarding outside of current FTN, ZONE or NET.  This
    does not imply nor permit the stripping of of a direct downlink
    which is outside the current strip filter.

        Keywords:
          There are no colons on keywords.

          Each keyword line is terminated with CR LF pair.

          The maximum length of a keyword line is 256 characters,
    including the CRLF termination. Some keyword lines may have a shorter
    limit.

          Keywords  are  separated from their data by a single space.
    There is no space if there is no data associated with the keyword.
            eg:  ReturnReceipt

          Keywords are case-insensitive and order independant.

          Keywords not understood are to be passed-though.

          Known Keywords that are blank should not be passed though.
            For  example,  an  empty  AREADESC,  could be either dropped
    or the blank  replaced with the proper description.

          Most Keywords are passed through when processing.
            There  are  exceptions.  In some cases, a site-specific
    replacement may be created.
            Keywords marked with a ^ should not be passed-through.

    FIDONEWS 14-25               Page 24                  23 Jun 1997


          Keywords marked with a * are REQUIRED when processing a TIC
    file.  If  any  of these are missing, the tic file should be
    considered as BAD and the associated file not forwarded to downlinks.

          Keywords marked with a # are CREATED when hatching or
    forwarding.

        *#  AREA [AreaName]
              the TagName of the file area.

            AREADESC [description of area]                    OPTIONAL
              a  short  (80 chars) description of the file area.  This
    could be the description found in FileBone.NA

        *#  FILE [File being sent]
              the name of the file being sent, no path
              the filename must conform to msdos 8.3 format, unless it is
              known that the receiving site can handle longer filenames.

        ^#  FULLNAME [original filename before FNC]           OPTIONAL FNC
    only the original filename (no path) before FileName Conversion

        *#  CRC [CRC-32 in hex]
              crc of the file being sent, 8 hexadecimal characters

        ^   MAGIC [MagicName]               OPTIONAL
              Name  under  which the file can be FREQed from the site
    listed in FROM.   This  is  NOT  passed  though when forwarding,
    unless the MAGIC  name  is  the  same  on  the  forwarding  site.  It
    can be replaced by the appropriate name.

            REPLACES [FileName]               OPTIONAL
              Filename  (no  path)  of  a  file  hatched  in  the AREA
    that the associated file replaces.  If the site expects FNC files,
    and the filename  does  not confrom to msdos 8.3 convention, the
    REPLACES name should also be FNC.

         #  DESC [Description]
              Description of the file, limited to 80 characters per line,
              including CRLF termination.
              If  multiple LDESC lines are used, the DESC line must
              provide the maximum information.  No File Forwadrer is
              required to passthough or make use of any extra DESC line
              after the first.

         # LDESC [multiple lines]
              A  long description of the file.  LDESC does NOT replace
    DESC, it is  used IN ADDITION to the short description.  No File
    Forwarder is required make use of LESC lines.

         #  SIZE [Bytes]              OPTIONAL, SHOULD be required
              Length of the file in bytes

            DATE [TimeDateStamp]
              TimeDateStamp of the file. Can be date of creation of
    archive.
    FIDONEWS 14-25               Page 25                  23 Jun 1997


           RELEASE [TimeDateStamp]
              Date  when file is TO BE released.  Usually used by SDS, but
    can be used by ADS as well.

           AUTHOR [name]
              Name of the author of the software package being hatched.
    This field is obviously not applicable to Newsletters, Nodelists and
    Diffs and the like.

           SOURCE [authors_address]
              FTN  address of the Author of the software package being
    hatched.  Not  necessary  the same as the ORIGIN hatch site.  Does not
    have
              to be an FTN address.

         ^ APP [program] [Application Specific Information]
              The  APP  keyword  is  a  keyword  known  to programs of the
    name indicated.  APP'S are order dependent and must be passed
    though.

        *#  ORIGIN [Address]
              Site where file entered the fileecho

        *^# FROM [Address] [Pwd]
              Site  that  is  forwarding  the  file  to  the next site.
    Pwd is optional and rarely used, IF AT ALL.  Pwd is NEVER passed
    through.

        ^   TO [Address]                        OPTIONAL
              Site  to  which  this TIC and the assocaited file are being
    sent.  This keyword is included in the .TIC file when:
                a)  the file is being routed via another system which
                    permits such routing.
                b)  the  platform  in  use  does  not  have  any  FTN
                    software independant   method   of   associating   a
                    file  and it's destination.   eg.   platforms  that
                    do not have filenotes that   could  contain  this
                    information  as  part  of the filesystem.

              If  the address in the TO line is that of the receiving
    site, the field  is  not passed through when forwarding.  If the
    address in the  TO  lines  IS  NOT  that of the receiving site, it
    should be forwarded to the TO site, if a routing agreement is in place
    with the sending site.

        *^# CREATED [by] [Program Banner]
              File  Forwarder which created the TIC file.  This is
    generally in the form:
                Created [by] program_name version [copyright_info]

            VIA [FROM CREATED]                  OPTIONAL (tracking)
              Copy  of  CREATED  line of FROM, with 'Created [by]'
    stripped and FROM  prepended.   Always passed though.  The VIA is only
    created by the receiving site when forwarding. It is never created
    by the hatching  site.  Therefore, in any TIC file, the addresses
    in the FROM and VIA should never be the same.
    FIDONEWS 14-25               Page 26                  23 Jun 1997


              examples:
              Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald
              Harms (2:281/910)
              Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert
              Williamson FIDONET#1:167/104.0

        *#  PATH [Address] [TimeDateStamp] [date and time]
              Address  of  Site  which  has forwarded the file.
    TimeDateStamp, date and time is that of when the Site received and
    Processed the file.

        * # SEENBY [Address]
              Site  which  has  received the file.  There are multiple
    lines of Seenby and they are unordered.

        *   PW [password]
              Site or Area password.  This is case-insensitive and should
    be at least 5 characters in length.

            PGP [signature]
              PrettyGoodPrivacy signature. To be discussed.

        ^    ReceiptRequest -no data-               OPTIONAL
              A  request  to the receiving system to generate a
    IsReturnReceipt (attribute  word bit 13) messsage, in the same manner
    it would if it  had  received  a message with the FileAttach an
    ReturnReceipt attributes and a subject of the filename.
              There  is  NO  requirement  to recognize this keyword.  It
              should never be passed through.

      Transmission of Files:

        The  associated file, that is, the file Listed in the FILE field
    of the TIC  file, should always be sent FIRST.  In the case of a
    failed session, sending  the  FILE  first  prevents  the  orphaning
    of  the file that is normally caused by the deletion or movement of
    the TIC file to BAD.

        File  Forwarders should not move or delete orphaned TIC files, but
    this can neither be relied upon nor mandated.

        File  Forwaders  should  be  transparent  to  the  renaming  of
    file by mailers.   This  means  that  if  the  mailer renames a
    duplicate file by renaming  or  bumpinmg  a numeric extension, the
    File Forwarder should be able  to  use  the  size  and  crc fields of
    the TIC to find and properly rename the associated file referred to in
    the TIC.

      File  Forwaders  should  always  delete and dequeue unsent TIC files
    when re-hatching  the  same  or  updated  version  of an associated
    file.  The implementor  may  wish  to  allow  exceptions  for
    periodicals such  as nodediffs and newsletters.

     -to be continued-

     -30-
    FIDONEWS 14-25               Page 27                  23 Jun 1997


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


      | Document: FSC-0088
      | Version:  001
      | Date:     31 October, 1995
      |
      | Robert Williamson FidoNet#1:167/104.0

        Compatibility and Link Qualifier Extensions for EMSI Sessions
        Robert Williamson FidoNet#1:167/104.0  [email protected]

        Purpose:

        The  basic  purpose of this document is to start discussions which
        will hopefully result in an improved handshake negotiation
        protocol.

        Scope:

        Relation of flags to Types of files transferred:

        The  FSC-0056  EMSI  specification  (hereafter  referred  to as
        EMSI-I) makes  little  distinction  between  ARCmail/packets and
        other types of files,  such  as  files attached and TIC'ed files.
        In EMSI-I, the term 'Mail'  when  not  used  in  conjunction with
        the term 'compressed', is interpreted to mean ANY file.

        This  extension  (hereafter  referred to as EMSI-II) makes
        reference to and  allows control of types of files in addition to
        'compressed mail'.  References  to  'Mail'  are  changed to 'File'
        where common practice so indicates.   The  additional qualifier
        flags described provide for more control as to the types of files
        a system is prepared to receive.


        Relation of flags to presented addresses:

        The  EMSI-I  specification does not allow qualification for any
        address other than the PRIMARY address.  This means that Link
        flags are limited in  application  to  either  all  presented
        addresses or to the primary presented address only.

        This  extension  also  allows  application  of  Link  flags to
        specific addresses other than the primary.

        Distinctions between Calling and Answering System:

        In  the EMSI-I spec, the type of flags that may be presented is
        limited by  the  status  of the site.  Certain flags may only be
        presented when the  site  is the caller and other flags may only
        be presented when the site is the answerer.  This proposed
        extension removes this distinction.

        In the EMSI-I spec, certain Link and Capability (a.k.a:
        Compatibility) flags  are  caller-driven, while others are
    FIDONEWS 14-25               Page 28                  23 Jun 1997


        controlled by the answering system.  This specification attempts
        to harmonize these discrepancies.

        A  attempt  is made to remain somewhat backwards compatible and to
        have new  flags  follow the original flag naming convention.
        However, IMHO, it  would  be preferable to harmonize the flags;
        reducing the number of them  while retaining the fine type
        control, so that the same codes are used in all sessions.

        Under  both  EMSI-I and EMSI-II, any flags that are not
        understood, are to  be  ignored.   Therfore,  if  a site presents
        it's flags in EMSI-II format  and  the  other site does not do
        EMSI-II, it is permissable for that site to interpret all flags
        according to EMSI-I specifications.

        Specifics:

        Compatibility flags:

        Compatibility  flags  consist of a string of codes that specify
        the PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.

        ARC, XMA
        These  EMSI-I  compatibility  flags  have  no  meaning  relavant
        to the transfer  of  files  and  are  not  to  be presented under
        EMSI-II.  If received, they are to be ignored.

        FNC
        The FNC EMSI-I compatibility flag has been identified as a
        'mistake' by the  author  of EMSI-I.  This is agreeable as that
        specification called for   the   creation   of   a   filename
        that  was  ALWAYS  8.3, not up-to-8.up-to-3.  It   is   not  to
        be  presented  under  EMSI-II.   If  received as  a compatibility
        flag, it is to be ignored.

        Protocol Selection:

        In  the EMSI-I spec, a requirement is placed upon the calling
        system to present  it's  available  protocols  in  order  of
        preference.  A quote follows:

            The calling system must list supported protocols first and
            descending order of preference (the most desirable protocol
            should be listed first).
            The answering system should only present one protocol and it
            should be the first item in the compatibility_codes field.

        Some mailer authors have interpreted 'the compatibility_codes
        field' in the  second  sentence  to  mean  that  of the answering
        system, thereby making  protocol  selection RECEIVER-PREFS driven.
        This interpretation makes  unnecessary  the  'decending  order'
        requirement placed upon the calling   system,   so  shall  be
        considered  in  conflict  with that requirement.

         Most   mailer  authors  have  interpreted  that  phrase  to  mean
        the 'compatibility_codes  field'  OF  THE  CALLER,  thereby making
    FIDONEWS 14-25               Page 29                  23 Jun 1997


        protocol selection  CALLER-PREFS  driven.   Since  EMSI-I  was
        intended to be "a clear  protocol  definition  for  state-of-the-
        art  E-Mail systems  to follow",  they  cannot  be  faulted  for
        interpretation.  Caller-prefs driven  selection  is state-of-the-
        art, receiver-prefs driven selection is older technolgy, such as
        Wazoo.

        This   specification   requires   that   the   second
        interpretation, CALLER-PREFS driven, be mandatory.

        New Compatibilty Flags:
        ----------------------

        EII
        Indicates   that   the   system   will   interpret   flags  under
        this specification, if other end also presents this flag.  IF
        either or both systems  do  not  present  this  flag,  all
        interpretations  are  done according to EMSI-I.

        DFB
        Indicates  that  the  system  presenting  is  capabable of fall-
        back to FTS1/WAZOO  negotiation  in the case of failure of EMSI
        handshake or no common  protocol.   Since  ZMO  is  the  minimum
        required protocol, NCP should  only  occur  if  the  answering
        system presents more than one protocol..  (ie. it's broken)

        FRQ
        Indicates  that  the  system  will  accept  and  process  file
        requests received  during  outbound  calls.   In other words, the
        calling system will  do a second turnaround for uni-directional
        protocols, to send the files requested, at his cost.

        NRQ
        NRQ should be presented ONLY IF the mailer does not have a file
        request server, task or function and cannot accept requests..  It
        should NOT be used to indicate that the  function  is  temporarly
        disabled.

        When  examined,  No  requests will be sent.  It would be advisable
        that the  mailer  alert  the  system  operator  of this occurance
        to prevent continued polling of the remote site.

        Protocol Capabilities:

        Protocol   capability   flags  are  presented  in  decending
        order  of preference  by  the  caller.  The answering system
        selects and presents the  FIRST  protocol  from  the  callers
        list  that  it supports.  The answering system must present only
        ONE protocol.

        HYD  Hydra bi-directional    (link flags define parameters)
        JAN  Janus bi-directional
        TZA  DirectZap               (TrapDoor DirectZap varient)
        DZA  DirectZap               (Zmodem variant, reduced escape set)
        ZAP  ZedZap                  (Zmodem variant, upe 8K blocks)
        ZMO  Zmodem w/1,024 packets  (Wazoo ZedZip)
    FIDONEWS 14-25               Page 30                  23 Jun 1997


        SLK  SeaLink                 (no TYSNC, No MDM7, No TeLink)
                                (8-32k window/ReSync/OverDrive/LongNames)
        NCP
        This  is  presented  if  no compatible protocol can be negotiated
        under EMSI.   Since  in  most  FTN  networks,  a  common protocol
        DOES exist, fallback   to  WaZoo  and  FTS1  negotiation  is
        expected.   If these negotiation methods are not available, the
        session is terminated.

        This  condition  should  never  occur  under  normal
        circumstances.  It should  be  considered as a problem with the
        design or configuration of one of the mailers involved.

        Link flags:
        ----------

        Link  flags  consist  of a string of codes that specify DESIRED
        CONNECT CONDITIONS.   They  apply  to  the CURRENT SESSION ONLY.
        Under EMSI-I, there are four TYPES of link flags:  communications
        parameters, session parameters, pickup options and hold options.
        Under EMSI-II, only three types  are  used,  the communications
        parameters type is REMOVED, as it serves no purpose whatsoever in
        FTN operations.

        Link Session options:

        FNC
        If  either  system  presents  this  flag,  it is an indication
        that the presenting   system   requires   filename   conversion
        to  cp/m-msdos conventions.  The other system will convert
        filenames to cp/m cpm/msdos 8.3 conventions before sending.
        The   convention   is   defined   as   a  filename  consisting  of
        two parts,  the  filepart  and  extension.   The filepart and
        extension are separated  by a period ".".  The filepart may be
        from 1 to 8 characters in  length  and  the  extension  may  be
        from  0 to 3 characters.  The character set shall be any uppercase
        character in the range A-Z and any numeric  character  in  the
        range  0-9.   If  the extension is of zero length, the period may
        or may not be present.

        RMA
        Indicates that the presenting site is able to send and process
        multiple file  requests.   If both sites present this flag, the
        caller will send any REQ files found for each AKA presented by the
        answering system.  The answering system will process each received
        REQ.

        RH1
        Indicates  that  under  the  Hydra  protocol,  batch  one contains
        file requests only, while batch 2 is reserved for all other files.

        (others to be defined)

        Pickup and Hold Flags:

        Under  the  EMSI-I  specification, Link Pickup flags are only
    FIDONEWS 14-25               Page 31                  23 Jun 1997


        presented when  calling (an Outbound Session) and are examined and
        processed only when  answering  (an  Inbound  Session)  and  Link
        Hold flags are only presented  when  answering  (an  Inbound
        Session) and are examined and processed only when calling (an
        Outbound Session).

        With  EMSI-II,  BOTH  Pickup and Hold flags are presented by both
        sites during  a  session.   This  allows  more control for those
        systems, for example,  which  cannot  modify  addresses  presented
        or rotate akas to change  the  primary  address  presented  on  a
        per-session or per-site basis.

        Link Pickup and Hold:

        Each  system can present one of three (or more) Link options
        related to application of addresses.  If neither of these flags
        are presented, PUA is to be assumed.

        Neither  PUA  nor  PUP  is  to  be  presented  if  only one
        address was presented.

                 PUP     Pickup FILES for primary address only
              /  PUA     Pickup FILES for all presented addresses
             /   PUn     Pickup FILES for address number n in AKA list
     one of |
             \
              \  NPU     No FILE pickup desired. (calling system)
                 HAT     Hold all FILES          (answering system)
                 HAn     Hold all FILES for address number n in AKA list

        Qualifiers:

        Qualifiers  are  processed  in  the  order presented, with any
        conflict being  resolved  by  subsequent  qualifiers overridding
        any conflicting previous qualifier in the list.

        Qualifiers may be not be presented with either NPU or HAT and
        should be ignored if received with NPU or HAT.

        PickUp:

            PMO     PickUp Mail (ARCmail and Packets) ONLY
            PMn     PickUp Mail ONLY for address number n in AKA list

            NFE     No TIC'S, associated files or files
                    attachs desired
            NFn     No TIC'S, associated files or file attaches,
                    for address number n in AKA list

            NXP     No compressed mail pickup desired
            NXn     No compressed mail pickup desired,
                    for address number n in AKA list

            NRQ     File requests not accepted by caller
                    This  flag is presented if file request processing
                    is disabled TEMPORARILY for any reason
    FIDONEWS 14-25               Page 32                  23 Jun 1997


            NRn     File requests not accepted by caller
                    for address number n in AKA list

         Note that NFE,NPX,NRQ != NPU

        Hold:

            HNM     Hold all traffic EXCEPT Mail (ARCmail and Packets)
            HNn     Hold all traffic EXCEPT Mail (ARCmail and Packets)
                    for address number n in AKA list

            HXT     Hold compressed mail traffic.
            HXn     Hold compressed mail traffic.
                    for address number n in AKA list

            HFE     Hold tic's and associated files
                    and file attaches other than mail
            HFn     Hold tic's and associated files
                    and file attaches other than mail
                    for address number n in AKA list

            HRQ     Hold file requests (not processed at this time)
                    This  flag is presented if file request processing
                    is disabled TEMPORARILY for any reason
            HRn     Hold file requests (not processed at this time)
                    for address number n in AKA list

         Note that HXT,HRQ,HFE == HAT

        -eot-

     -30-

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

    FIDONEWS 14-25               Page 33                  23 Jun 1997


    =================================================================
                    ADVERTISE YOUR FREE SERVICE/EVENT
    =================================================================


    Emanuel Edwards
    1:348/963
    [email protected]

    Hello all Wrestling Fans:

    Where else can you find:

    All the Latest News, great wrestling scoops and great wrestling
    advertisement?  You can get it all on the WRESTLING_CHAT.  The echo
    tag is called WRESTLING_CHAT.

    Wrestling Fans in North American and around the world if you want to
    hear about all the latest wrestling news and upcoming events this is
    the echo to be on.  All you sysops request the WRESTLING_CHAT on you
    BBS.  The Wrestling_chat offer a freedom of speech atmosphere and
    there are great wrestling fans on that echo that echo.

    Regards

    Emanuel   Moderator
    Barry Laws Jr   Co_Moderator

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

    FIDONEWS 14-25               Page 34                  23 Jun 1997


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


    --- Following message extracted from NETMAIL @ 1:18/14 ---
        By Christopher Baker on Fri Jun 20 00:18:09 1997

    From: Mark Storm @ 1:366/2
    To: Christopher Baker @ 1:18/14
    Date: 15 Jun 97  12:15:25
    Subj: area code changes

    * Copied (from: netmail) by Mark Storm using timEd/2 1.10+.

    Hello Ken!

    effective June 23, 1997 until March 23, 1998 the area codes for the
    northwest Florida counties will be in a change mode ... all counties
    west of and including Madison and Taylor will change to 850 ... I
    getting ready for this change I will be submitting my nets changes
    effective 28 June 1997 ...

    a listing of the counties effected area as follows:

     Escambia
     Santa Rosa
     Okaloosa
     Walton
     Holmes
     Washington
     Bay
     Jackson
     Calhoun
     Gulf
     Gadsden
     Liberty
     Franklin
     Wakulla
     Leon
     Jefferson
     Madison
     Taylor

    A copy of this has been sent to Chris Baker in an improper format for
    submission to FidoNews if he feels it is appropriate ... also if you
    wish to place it at the bottom of the nodelist feel free ... Mark..
    ([email protected])

     later...


    M<ark  [email protected]

     -30-

    FIDONEWS 14-25               Page 35                  23 Jun 1997


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

                               Future History

     1 Jul 1997
       Canada Day - Happy Birthday Canada.

     9 Jul 1997
       Independence Day, Argentina.

     1 Aug 1997
       International FidoNet PENPAL [Echo] meeting in Dijon, France

    13 Oct 1997
       Thanksgiving Day, Canada.

     1 Dec 1997
       World AIDS Day.

    10 Dec 1997
       Nobel Day, Sweden.

    12 Jan 1998
       HAL 9000 is one year old today.

    30 Apr 1998
       Queens Day, Holland.

    22 May 1998
       Expo '98 World Exposition in Lisbon (Portugal) opens.

     1 Dec 1998
       Fifteenth Anniversary of release of Fido version 1 by
       Tom Jennings.

    31 Dec 1999
       Hogmanay, Scotland. The New Year that can't be missed.

     1 Jan 2000
       The 20th Century, C.E., is still taking place thru 31 Dec.

    15 Sep 2000
       Sydney (Australia) Summer Olympiad opens.

     1 Jan 2001
       This is the actual start of the new millennium, C.E.

    -- If YOU have something which you would like to see in this
       Future History, please send a note to the FidoNews Editor.

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

    FIDONEWS 14-25               Page 36                  23 Jun 1997


    =================================================================
                           FIDONEWS PUBLIC-KEY
    =================================================================


    [this must be copied out to a file starting at column 1 or
     it won't process under PGP as a valid public-key]


    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: 2.6.2
    Comment: Clear-signing is Electronic Digital Authenticity!

    mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
    eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
    Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
    tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
    JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
    FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
    c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
    FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
    1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
    O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
    UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
    8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
    ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
    q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
    3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
    raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
    FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
    vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
    X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
    Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
    toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
    D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
    SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
    AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
    v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
    FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
    WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
    DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
    EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
    +Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
    Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
    aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
    ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
    =61OQ
    -----END PGP PUBLIC KEY BLOCK-----


    File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
    Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
    1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on
    the FidoNews homepage listed in the Masthead information.

    -----------------------------------------------------------------
    FIDONEWS 14-25               Page 37                  23 Jun 1997


    =================================================================
                           FIDONET BY INTERNET
    =================================================================

    This is a list of all FidoNet-related sites reported to the Editor as
    of this appearance.

    ============

    FidoNet:

      Homepage     http://www.fidonet.org
      FidoNews     http://ddi.digital.net/~cbaker84/fidonews.html
      HTML FNews   http://www.geocities.com/Athens/6894/
      WWW sources  http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
      FTSC page    http://www2.blaze.net.au/ftsc.html
      Echomail     http://www.portal.ca/~awalker/index.html
      WebRing      http://ddi.digital.net/~cbaker84/fnetring.html

    ============

    Zone 1:       http://www.z1.fidonet.org

      Region 10:  http://www.psnw.com/~net205/region10.html

      Region 11:  http://oeonline.com/~garyg/region11/

      Region 13:  http://www.smalltalkband.com/st01000.htm

      Region 14:  http://www.netins.net/showcase/fidonet/

      Region 15:  http://www.smrtsys.com/region15/ [disappeared?]

      Region 16:  http://www.tiac.net/users/satins/region16.htm

      Region 17:  http://www.portal.ca/~awalker/region17.htm
          REC17:  http://www.westsound.com/ptmudge/

      Region 18:  http://www.citicom.com/fido.html

      Region 19:  http://www.compconn.net

    ============

    Zone 2:       http://www.z2.fidonet.org

    ZEC2:         http://fidoftp.paralex.co.uk/zec.htm [shut down?]
    Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm

      Region 20:  http://www.fidonet.pp.se (in Swedish)

      Region 24:  http://www.swb.de/personal/flop/gatebau.html (in German)

      Region 25:
                  http://members.aol.com/Net254/

    FIDONEWS 14-25               Page 38                  23 Jun 1997


      Region 27:  http://telematique.org/ft/r27.htm

      Region 29:  http://www.rtfm.be/fidonet/  (in French)

      Region 30:  http://www.fidonet.ch  (in Swiss)

      Region 34:  http://www.pobox.com/cnb/r34.htm  (in Spanish)
          REC34:  http://pobox.com/~chr

      Region 36:  http://www.geocities.com/SiliconValley/7207/

      Region 41:  http://www.fidonet.gr (in Greek and English)

      Region 48:  http://www.fidonet.org.pl

    ============

    Zone 3:       http://www.z3.fidonet.org

    ============

    Zone 4:       (not yet listed)

      Region 90:
        Net 904:  http://members.tripod.com/~net904 (in Spanish)

    ============

    Zone 5:       (not yet listed)

    ============

    Zone 6:       http://www.z6.fidonet.org

    ============

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

    FIDONEWS 14-25               Page 39                  23 Jun 1997


    =================================================================
                          FIDONEWS INFORMATION
    =================================================================

    ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------

    Editor: Christopher Baker

    Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell,
                      Vince Perriello, Tim Pozar, Sylvia Maxwell,
                      Donald Tees

    "FidoNews Editor"
        FidoNet  1:1/23
        BBS  1-904-409-7040,  300/1200/2400/14400/V.32bis/HST(ds)

     more addresses:
        Christopher Baker -- 1:18/14, [email protected]
                                      [email protected]
                                      [email protected]

    (Postal Service mailing address)
        FidoNews Editor
        P.O. Box 471
        Edgewater, FL 32132-0471
        U.S.A.


    voice:  1-904-409-3040 [1400-2100 ET only, please]
                           [1800-0100 UTC/GMT]

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

    FidoNews is published weekly by and for the members of the FIDONET
    INTERNATIONAL AMATEUR ELECTRONIC MAIL system.  It is a compilation
    of individual articles contributed by their authors or their
    authorized agents.  The contribution of articles to this compilation
    does not diminish the rights of the authors.  OPINIONS EXPRESSED in
    these articles ARE THOSE OF THE AUTHORS and not necessarily those of
    FidoNews.

    Authors retain copyright on individual works; otherwise FidoNews is
    Copyright 1997 Christopher Baker.  All rights reserved.  Duplication
    and/or distribution permitted for noncommercial purposes only.  For
    use in other circumstances, please contact the original authors, or
    the Editor.

                           =*=*=*=*=*=*=*=*=

    OBTAINING COPIES: The most recent issue of FidoNews in electronic
    form may be obtained from the FidoNews Editor via manual download or
    file-request, or from various sites in the FidoNet and Internet.
    PRINTED COPIES may be obtained by sending SASE to the above postal
    address.  File-request FIDONEWS for the current Issue.  File-request
    FNEWS for the current month in one archive.  Or file-request specific
    back Issue filenames in distribution format [FNEWSEnn.ZIP] for a
    FIDONEWS 14-25               Page 40                  23 Jun 1997


    particular Issue.  Monthly Volumes are available as FNWSmmmy.ZIP
    where mmm = three letter month [JAN - DEC] and y = last digit of the
    current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97.

    Annual volumes are available as FNEWSn.ZIP where n = the Volume number
    1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in
    size from 48K to 1.4M.


    INTERNET USERS: FidoNews is available via:

                         http://www.fidonet.org/fidonews.htm
                         ftp://ftp.fidonet.org/pub/fidonet/fidonews/
                         ftp://ftp.aminet.org/pub/aminet/comm/fido/

                                     *=*=*

    You may obtain an email subscription to FidoNews by sending email to:

                         [email protected]

    with a Subject line of: subscribe fnews-edist

    and no message in the message body. To remove your name from the email
    distribution use a Subject line of: unsubscribe fnews-edist with no
    message to the same address above.

                                     *=*=*

    You can read the current FidoNews Issue in HTML format at:

                         http://www.geocities.com/Athens/6894/

    STAR SOURCE for ALL Past Issues via FTP and file-request -
    Available for FReq from 1:396/1 or by anonymous FTP from:

                         ftp://ftp.sstar.com/fidonet/fnews/

    Each yearly archive also contains a listing of the Table-of-Contents
    for that year's issues.  The total set is currently about 11 Megs.

                                =*=*=*=

    The current week's FidoNews and the FidoNews public-key are now also
    available almost immediately after publication on the Editor's new
    homepage on the World Wide Web at:

                 http://ddi.digital.net/~cbaker84/fidonews.html

    There are also links there to jim barchuk's HTML FidoNews source and
    to John Souvestre's FTP site for the archives. There is also an email
    link for sending in an article as message text. Drop on over.

                           =*=*=*=*=*=*=*=*=

    A PGP generated public-key is available for the FidoNews Editor from
    FIDONEWS 14-25               Page 41                  23 Jun 1997


    1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
    Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18.  It
    is also posted twice a month into the PKEY_DROP Echo available on the
    Zone 1 Echomail Backbone.

                               *=*=*=*=*

    SUBMISSIONS: You are encouraged to submit articles for publication in
    FidoNews. Article submission requirements are contained in the file
    ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
    from 1:1/23 [1:18/14] as file "ARTSPEC.DOC".  ALL Zone Coordinators
    also have copies of ARTSPEC.DOC. Please read it.

    "Fido", "FidoNet" and the dog-with-diskette are U.S. registered
    trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
    and are used with permission.

            "Disagreement is actually necessary,
             or we'd all have to get in fights
             or something to amuse ourselves
             and create the requisite chaos."
                               -Tom Jennings

     -30-

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